Re: diskd Q1/Q2 parameters backwards

From: Duane Wessels <wessels@dont-contact.us>
Date: Mon, 7 Jan 2002 14:36:16 -0700 (MST)

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