https://bugs.openldap.org/show_bug.cgi?id=10465
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- Considering our options, let's keep to Linux because in some ways that's where this is most pronounced and start with the least intrusive upwards: 1. changing nice() levels increases the chances of being rescheduled but in practice we just woke up after being suspended for I/O (SYNC for lmdb TXN commit), so we don't get rescheduled or the stuck thread is not likely be parked on our CPU? At least that's my assessment from the tests I've ran.
2. lowering thread priority is not a thing on Linux, SCHED_OTHER is the default and lowest apart from SCHED_IDLE which makes no difference in practice
3. We could bump the priority of all other threads by default, switching the purge task to SCHED_OTHER and back on completion
4. We let the purge task sleep for a little every so often, sacrificing throughput for (guaranteed) responsiveness.
5. We could make changes to back-mdb to detect contention of the write txn mutex and enforce fairness on that level. This might be invasive and costly.
1, 2 and 3 have a massive drawback, changing the scheduler policy (SCHED_RR/FIFO or even SCHED_IDLE) seems to be a privileged operation so is bumping nice() levels back to original.
None of them are very appealing. Of them just pausing for a little might just be the least bad? Take this scheme for an idea:
If every N deletes we measure how long it took to process them and wait (sleep) for 1/N of that afterwards, we lose a fraction (1/(N+1)) of purge throughput while bounding the latency impact to a factor of N at most.