This is with 2.0.30 with the filehandle patch from
www.linux.org.za/filehandle.patch.linux (or
ftp://ftp.is.co.za/linux/local/filehandle.patch.linux)
squid has been re-compiled to handle 3000 fd's per process
and we are running libc 5.4.17
I would appreciate it if someone with a brain (as apposed to me) has a
look at the filehandle patch and sees if this is because of it.
The machine has been up 19 days with the average time between
select calls being around 49 milliseconds... It's heavily loaded
TCP wise too, doing a 100 000 http requests or so a day.
May 19 23:18:55 cache1 kernel: general protection: 0000
May 19 23:18:55 cache1 kernel: CPU: 0
May 19 23:18:55 cache1 kernel: EIP: 0010:[tcp_v4_unhash+24/72]
May 19 23:18:55 cache1 kernel: EFLAGS: 00010282
May 19 23:18:55 cache1 kernel: eax: e2a8ab9b ebx: 0205d810 ecx: 0205d810 e
dx: 25e46d78
May 19 23:18:55 cache1 kernel: esi: 0205d8cc edi: 00000000 ebp: 00000002 e
sp: 012f5f30
May 19 23:18:55 cache1 kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0
018
May 19 23:18:55 cache1 kernel: Process squid (pid: 27821, process nr: 14, stackp
age=012f5000)
May 19 23:18:55 cache1 kernel: Stack: 001435c6 0205d810 0205d810 021e108c 021e10
8c 0014d023 0205d810 00000000
May 19 23:18:55 cache1 kernel: 021e1000 00000000 00133e20 021e108c 000000
00 021e1000 021e1000 021e1000
May 19 23:18:55 cache1 kernel: bffff820 00134059 021e108c 01f4a0c0 001220
b8 021e1000 01f4a0c0 00000000
May 19 23:18:55 cache1 kernel: Call Trace: [tcp_close+518/528] [inet_release+103
/112] [sock_release+92/156] [sock_close+37/44] [__fput+28/64] [close_fp+76/92] [
sys_close+68/80]
May 19 23:18:55 cache1 kernel: [system_call+85/128]
May 19 23:18:55 cache1 kernel: Code: 89 50 64 8b 51 64 8b 41 60 89 02 c7 41 64 00 00 00 00 8b 51
May 19 23:18:55 cache1 kernel: Aiee, killing interrupt handler
I doubt it's a memory problem because it's been working properly
for the last 6 months (with a 1024fd filehandle patch) in a well ventilated
room etc,etc,etc.
Oskar