Hi Garth, I’m guessing this is not properly documented. We should fix that. There are two configuration properties that govern the IO workload management behavior; here they are with their defaults:
``` [ioq] ; number of concurrent IO requests that will be submitted to the disk subsystem concurrency = 10 ; when the concurrency slots are occupied, this is the probability of selecting a compaction IO request next ratio = 0.01 ``` So, if you just wanted to open up the throttle and let compaction run with whatever priority you could set ``` [ioq] concurrency = 1000 ; or some other large number ``` Alternatively, if you wanted to actively prioritize compaction *ahead* of other interactive IO you could do ``` [ioq] ratio = 0.8 ; or some other number up to 1.0 ``` Note that if you really want to put a node in maintenance mode and have it ignore interactive requests you can also set the “maintenance mode” flag: ``` [couchdb] maintenance_mode = true ``` Cheers, Adam > On Dec 2, 2016, at 10:35 AM, Garth Gutenberg <garth.gutenb...@gmail.com> > wrote: > > Hello again. In https://blog.couchdb.org/2016/09/20/2-0/ it says > "Compaction can now be run at any time, even continuously". However I > can't find any documentation on how to configure this - either recommended > configuration parameters or best practices. Is there a document somewhere > that outlines how to enable continuous compaction and what the pros/cons > are? > > Ideally I'd like to dedicate one node of a cluster to serving data, and the > other node to running maintenance (compaction). Is this viable? Is there > a better way to do it? Any input would be appreciated.
