Re: sometimes squid proxy enters state where very little work is doneu

From: Mario Sergio Fujikawa Ferreira <lioux@dont-contact.us>
Date: Thu, 24 Oct 1996 23:32:16 -0200 (EDT)

Greetings,

        Proxy: Squid 1.1beta9
        Os: FreeBSD 2.1R
        Machine: PPRO 200 mhz.

> >minute. However, every day or two it gets into a state where the
> >number of transactions per minute drop to nearly zero, and connection
> >attempts to the proxy usually timeout. I'm guessing that this happens

        Same over here. However, the problem is much more frequent: once an hour.

> The code is supposed to accomodate file descriptor shortages, but
> I haven't personally stress-tested it.

        Well, I guess that for a 100 MB test spool about 2088 descriptors per process should be enough. If it is not, please let me know: I'll increase it accordinly.

> In general, I can think of only three reasons why the squid process would
> slow down or pause:
>
> 1) a system call blocks
> 2) it enters an "infinite" loop
> 3) the OS doesn't/can't run the process enough (e.g. swapping)
>
> The first should be fairly easy to detect. If the process seems to
> have stopped on a blocked system call, there should be zero CPU usage.
> If you send it a USR2 signal you might expect the process to remain
> blocked and therefore see NO cache.log output.
>
> The second reason should be noticable by a high CPU usage for the
> process. Sending a USR2 signal may or may not produce additional
> debugging output.
>
> The third is probably more elusive. If you send a SIGUSR2 signal and
> see:
>
> 96/10/21 22:59:11| comm_select: 0 sockets ready at 845960351
> 96/10/21 22:59:12| comm_select: 0 sockets ready at 845960352
> 96/10/21 22:59:13| comm_select: 0 sockets ready at 845960353
> 96/10/21 22:59:14| comm_select: 0 sockets ready at 845960354
> 96/10/21 22:59:15| comm_select: 0 sockets ready at 845960355
> 96/10/21 22:59:16| comm_select: 0 sockets ready at 845960356
>
> Then you know the cache process is idle and running normally.
>

        I had none of the above situations over here.
        The squid process stop answering requests. I did a kill -SIGUSR2 on the squid -s process.
        Nothing happened. No console output, nor any modification on the log files. However, the squid process keeps requesting about 0.78% of wcpu (top output).
        I tried another approach. I did a kill -HUP on the process. What happens: the number of dnsservers doubles (it happened more than an once).
        Then, I did a kill -9 on the squid -s process. The number of dnsservers returned to the normal value instead of all squid processes going to the floor. I had to issue a second kill -9 to kill all the processes.
        This only happens with squid release 1.1. I have a working squid 1.0 that goes just smooth. However, I would like to use the squid 1.1, for it seemed much more prompt to user requests.

        Any ideas,
                Mario Ferreira.
        (lioux@gns.com.br)
Received on Thu Oct 24 1996 - 18:32:31 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:21 MST