| commit | c1ba0db845dd6e6c679558acb2bbe42ce64a26f4 | [log] [tgz] |
|---|---|---|
| author | Paul J. Davis <davispa@us.ibm.com> | Mon Jun 29 14:53:38 2020 -0500 |
| committer | Paul J. Davis <davispa@us.ibm.com> | Mon Jun 29 14:53:38 2020 -0500 |
| tree | a152b931f0288f95f8e821e7f20168bc52e8102e | |
| parent | 4039fe6d721ea6b444c9550550ca29f8d4ec72dd [diff] |
Add backpressure to ioq_server For interactive IOQ requests, the first time a process calls ioq_server we use a 5s timeout. If we don't have a response within that timeout we return a signal that IO has been saturated on this node. If the first request succeeds we remove the timeout so that we don't start failing IO once a request has started processing.
The following are the list of IOQ classes:
One can configure an ioq bypass, which removes an IO class from prioritization, as below:
config:set("ioq.bypass", "view_update", "true")
Note that setting an IOQ bypass can effectively trump all other classes, especially in the case of an interactive bypass v. compaction. This can lead to high disk usage.
The priority for a class can also be set ala:
config:set("ioq", "compaction", "0.3")
Or globally, using snippet/rpc:
s:set_config("ioq", "compaction", "0.314", global)
rpc:multicall(config, set, ["ioq", "compaction", "0.217"])
As the interactive class is ‘everything else’ its priority cannot be directly set.