[Fwd: [Fwd: [squid-users] Update: #redirectors decays over time]]

From: Mike Kiernan <mkiernan@dont-contact.us>
Date: Wed, 22 Aug 2001 09:14:49 +0200

Still no feedback on this squirm problem - I'd
really appreciate any ideas on how to take this further...

Attached is a graph of ps -C squirm | wc -l
stats in rrdtool which shows the number of
squirms decreasing, squid crashes, and squirms
increase to 90, and start decaying again etc.
(data from 3 squid servers on the same graph).
I don't believe increasing the number of redirectors
is going to help, and isn't very efficient since it's
only peak burst traffic that breaks it...(it's already
up to 90, dnsservers up to 30)

The entry on crash in the log is:

2001/08/21 22:49:09| helperHandleRead: FD 103 read: (11) Resource
temporarily unavailable
2001/08/21 22:49:09| WARNING: redirector #47 (FD 103) exited
2001/08/21 22:49:09| storeDirWriteCleanLogs: Starting...
2001/08/21 22:49:09| WARNING: Closing open FD 6
2001/08/21 22:49:09| Finished. Wrote 1102 entries.
2001/08/21 22:49:09| Took 0.0 seconds (103193.2 entries/sec).
FATAL: Too few redirector processes are running
Squid Cache (Version 2.4.STABLE1): Terminated abnormally.
CPU Usage: 24699.830 seconds = 9356.610 user + 15343.220 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 11333
Memory usage for squid via mallinfo():
        total space in arena: 104958 KB
        Ordinary blocks: 101531 KB 125120 blks
        Small blocks: 0 KB 0 blks
        Holding blocks: 3000 KB 6 blks
        Free Small blocks: 0 KB
        Free Ordinary blocks: 3426 KB
        Total in use: 104531 KB 100%
        Total free: 3426 KB 3%
2001/08/21 22:49:13| Starting Squid Cache version 2.4.STABLE1 for
i686-pc-linux-gnu...
2001/08/21 22:49:13| Process ID 7299
2001/08/21 22:49:13| With 8192 file descriptors available
2001/08/21 22:49:13| helperOpenServers: Starting 30 'dnsserver'
processes
2001/08/21 22:49:13| helperOpenServers: Starting 90 'squirm' processes
2001/08/21 22:49:14| Unlinkd pipe opened on FD 129

strace of one squirm child at the time shows:

read(0, "http://republika.pl/kastom/image"..., 4096) = 71
write(1, "http://republika.pl/kastom/image"..., 71) = 71
open("/var/log/squirm/match", O_WRONLY|O_APPEND|O_CREAT, 0666) = -1
ENOENT (No such file or directory)
read(0, 0x40014000, 4096) = -1 ECONNRESET (Connection
reset by peer)
munmap(0x40015000, 4096) = 0
_exit(0) = ?

thanks,
Mike

-------- Original Message --------
Subject: [Fwd: [squid-users] Update: #redirectors decays over time]
Date: Tue, 21 Aug 2001 17:45:54 +0200
From: Mike Kiernan <mkiernan@onet.pl>
Organization: Onet.pl S.A.
To: squid user group <squid-users@squid-cache.org>

After patiently stracing some of my squirms it appears
they are exiting with ECONNRESET (connection reset by
peer) on a read(0) call. Presumably the peer is the
squid process sitting at the other end of the pipe.

How to avoid this? [this is a serious problem for us
as when the number of redirectors falls too low squid
decides instead of forking more, it'll just give up
and kill itself (which is poor!)]. This is happening
on all of our caches once every couple of hours. I need
to fix this...!!

thanks again,
Mike

-------- Original Message --------
Subject: [squid-users] #redirectors decays over time
Date: Tue, 21 Aug 2001 13:59:20 +0200
From: Mike Kiernan <mkiernan@onet.pl>
Organization: Onet.pl S.A.
To: squid user group <squid-users@squid-cache.org>

I have increased the max number of directors to 256 of which I am
currently using 90 [btw. why is it hardcoded so low - 32 ??]

I've noticed that over time the number of available redirectors
decays from 90. I get the following messages in my cache log:

2001/08/21 13:18:51| helperHandleRead: FD 58 read: (11) Resource
temporarily unavailable
2001/08/21 13:18:51| WARNING: redirector #22 (FD 58) exited

Can anyone explain what is happening here ? [my redirector is squirm,
and this is squid 2.4stable1 on linux]

Thanks for your help,
Mike

nsquirm.png
Received on Wed Aug 22 2001 - 01:15:08 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:01:53 MST