comm_poll_incoming NULL write handler

From: Darren Steven <[email protected]>
Date: Thu, 26 Aug 1999 14:34:08 +1000

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