[squid-users] Squid 2.4.STABLE2 slowdown?

From: Peter Smith <peter.smith@dont-contact.us>
Date: Thu, 06 Dec 2001 10:58:07 -0600

I'm experiencing a general slowdown (and sometimes segfaulting) of Squid
2.4.STABLE2 on my 2 Squid proxies. Let me describe my situation.

I have 2 proxies.

proxy # 1
ix86 Redhat 7.1
2 x 1.0gz Pentium 3
1.0G RAM
1 16G mirrored /
3 16G /cache drives (1,2,3)
3 NIC's (1 inet, 1 intranet, 1 ICP)
Squid 2.4.STABLE2 (Redhat SRPM)
3 cache_dir's 15g 64x64 directories DISKD

proxy # 2
ix86 Redhat 7.1
2 x 1.0gz Pentium 3
1.0G RAM
1 16G mirrored /
3 16G /cache drives (1,2,3)
3 NIC's (1 inet, 1 intranet, 1 ICP)
Squid 2.4.STABLE2 (Redhat SRPM)
3 cache_dir's 15g 256x256 directories AUFS

Each cache regularly gets >100 req/sec for about 6 hours straight in a day.
Each cache regularly sends out 500-900k/sec data to clients for about 6
hours straight in a day.
proxy # 1 gets rebooted daily while proxy # 2 does not.

In addition to a general slowdown, I've been seeing random segfaulting
on proxy # 1's Squid. I've seen it restart itself in the following manner.

2001/12/05 15:59:34| comm_accept: FD 16: (104) Connection reset by peer
2001/12/05 15:59:34| httpAccept: FD 16: accept failure: (104) Connection
reset by peer
2001/12/05 15:59:34| comm_accept: FD 16: (104) Connection reset by peer
2001/12/05 15:59:34| httpAccept: FD 16: accept failure: (104) Connection
reset by peer
2001/12/05 15:59:34| comm_accept: FD 16: (104) Connection reset by peer
2001/12/05 15:59:34| httpAccept: FD 16: accept failure: (104) Connection
reset by peer
2001/12/05 15:59:34| comm_accept: FD 16: (104) Connection reset by peer
2001/12/05 15:59:34| httpAccept: FD 16: accept failure: (104) Connection
reset by peer
2001/12/05 15:59:34| comm_accept: FD 16: (104) Connection reset by peer
2001/12/05 15:59:34| httpAccept: FD 16: accept failure: (104) Connection
reset by peer
2001/12/05 15:59:53| sslReadServer: FD 254: read failure: (104)
Connection reset by peer
2001/12/05 15:59:59| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 15:59:59| Select loop Error. Retry 1
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 2
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 3
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 4
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 5
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 6
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 7
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 8
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 9
2001/12/05 16:00:11| comm_poll: poll failure: (12) Cannot allocate memory
2001/12/05 16:00:11| Select loop Error. Retry 10
FATAL: Select Loop failed!
Squid Cache (Version 2.4.STABLE2): Terminated abnormally.
CPU Usage: 24731.920 seconds = 8163.900 user + 16568.020 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 31150
Memory usage for squid via mallinfo():
        total space in arena: 379074 KB
        Ordinary blocks: 369782 KB 7870 blks
        Small blocks: 0 KB 0 blks
        Holding blocks: 3140 KB 7 blks
        Free Small blocks: 0 KB
        Free Ordinary blocks: 9291 KB
        Total in use: 372922 KB 98%
        Total free: 9291 KB 2%

Please let me know if there is something odd that I have configured or
if I need to provide some more data. I'm open to any suggestions. Also
I'm looking to perhaps setup a third proxy machine to even out some of
this load as I feel it is unusually high. Thanks in advance to all!!

Peter Smith
Received on Thu Dec 06 2001 - 09:58:10 MST

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