ramey@csc.ti.com writes:
>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
>when we get to the file descriptor limit, though I have no hard proof
The code is supposed to accomodate file descriptor shortages, but
I haven't personally stress-tested it.
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.
Duane W.
Received on Wed Oct 23 1996 - 21:21:49 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:20 MST