On Mon, 7 Jan 2002, Henrik Nordstrom wrote:
> Hmm.. are you sure? From what I can tell Q1 = 64, Q2 = 72. Looking at HEAD
> and 2.4.
True. And this is wrong.
> The comments in squid.conf and the FAQ has been backwards some time, but
> this should have been corrected long ago..
>
> To re-summary the limits:
>
> Really bad things happens if you reach the upper SHM limit.
>
> To avoid this, there MUST be a reasonable margin where you start block
> new I/O requests.
>
> To avoid too much blocking, there SHOULD to be a limit where you starts to
> reject new I/O requests.
>
> Q1 controls the rejection limit (magic1)
In the implementation, Q1/magic1 is where Squid takes more desperate
measures. For example, intentionally failing on open. We want to
avoid Q1/magic1 if possible.
/*
* Fail on open() if there are too many requests queued.
*/
if (diskdinfo->away > diskdinfo->magic1) {
debug(81, 3) ("storeDiskdOpen: FAILING, too many requests away\n");
diskd_stats.open_fail_queue_len++;
return NULL;
}
> Q2 controls the blocking limit (magic2).
In the implementation, Q2/magic2 is where Squid takes less desperate
measures. For example, sleeping/blocking in the callback loop
until more messages are acked. Its okay to get to Q2/magic2 because
the sleeping/blocking provides a little negative feedback to the
client side, without doing anything too drastic.
int
storeDiskdDirCallback(SwapDir * SD)
{
diomsg M;
int x;
diskdinfo_t *diskdinfo = SD->fsdata;
int retval = 0;
if (diskdinfo->away >= diskdinfo->magic2) {
diskd_stats.block_queue_len++;
retval = 1; /* We might not have anything to do, but our queue
* is full.. */
}
> The C code is written such that Q1(64) < Q2(72) < SHM limit(96), and is
> also how it is documented in squid.conf.default as far as I can tell.
No, its was stupid on my part I guess, but it should be Q2 < Q1 < SHM limit.
I've been doing some benchmarks and banging my head on this for a couple of
days. With Q1 < Q2 (as in the comments and defaults) really bad things
happen. Squid hits the Q1 limit and hit ratio goes down, response time
goes WAY up and doesn't come back down for a long time.
Received on Mon Jan 07 2002 - 14:36:16 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:45 MST