Hi all,
We are having a problem (maybe two)on one of our boxes (RH6intel
2.2.10.ac11: 2048 handles, squid 2.2stable3 - --enable-poll
--enable-snmp --enable-async-io)
From time to time, we get a large number of messages like:
13:50:02| comm_poll_incoming: NULL write handler 68 - (the 68 is my hack
to ID FD, which is ICP socket - number changes, but is always the ICP).
Usually there will be 10 to 12 of these over the next minute or so. This
in itself may not be a problem, but the folowing seems to happen at
around the same time:
The system becomes slow to accept incoming connections to the squid port
(other ports OK, can telnet in, and system is running smoothly - except
no connect on port 8080). At the same time, the CPU utilisation drops
very low, and stays that way for a few (5-10) minutes - ie squid is
quiet. The access.log continues to scroll past while this is occuring -
serving current requests. Then everything takes off again.
I'm not sure that the two problems are related - the correlation may be
only in my head, which is not always the sanest place to be lately.
Also, this box has 2 LAN cards, with a second IP bound to one of the
cards that squid listens on usinf tcp_incoming_address. It may be
related.
Could squid be not seeing the incoming connects - i'll wait for the next
event, and record the socket states over time.
I have also reduced some of the default config file timeout vaules to
help free FD's in the last couple of days - could that have an effect on
this? as the problem is only new (as far as I know).
Any hints as to where to start looking? We have a number of nearly
identically setup boxes that behave fine.
PS - here's a hint, don't use software raid5 with squid on busy large
caches. The number of disk IO transactions can get so high that the
thing grinds to a halt, with all aysnc threads busy, , even thuough the
disk bytes/sec was lower than the potential thruput. Turning off raid
and using the disks individually made life much easier on the disks.
Have a look at the systat package - it implements iostat and sar, to
give a different view of system io performance than vmstat.
Thanks for any advice
-
Darren Steven
Applications Specialist
Networking Tasmania
Telstra Australia
Ph.1800 813 302
Received on Wed Aug 25 1999 - 22:34:42 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:48:06 MST