Hello,
The new option introduced by this patch limits Squid I/O rate to
smooth out OS disk commit activity and to avoid blocking Rock diskers
(or even other processes!) on I/O. It should be used when swap demand
exceeds disk performance limits but the underlying file system does not
slow down incoming I/Os, allowing the situation to get out of control.
Lab and limited deployment tests show that without this option, Squid
may write to the OS buffers much faster than the OS is able to write to
disk. This disbalance eventually (and quite suddenly!) blocks any
process trying to do I/O for a second or two, which results in very poor
overall performance. Tuning file system parameters may help, but
sometimes is not enough.
The new max-swap-rate option is meant to be used together with the
existing swap-timeout option. Otherwise, the problem simply shifts one
layer up, with unrestricted workers overflowing restricted Rock I/O
queues. The swap-timeout option allows a worker to skip Store operations
when there are "too many" I/O pending already.
The code seems to work well, but can be further optimized to minimize
read (hit) delays and to better enforce configured swap timeouts.
HTH,
Alex.
This archive was generated by hypermail 2.2.0 : Thu Oct 06 2011 - 12:00:04 MDT