the bad news first . This is the error we are getting on the server that has been causing the slowdown (finally found the cause)
Unable to handle kernel NULL pointer dereference at virtual address
00000080
printing eip:
c012c897
*pde = 00000000
Oops: 0000
autofs e100 ipt_REJECT iptable_filter ip_tables keybdev mousedev hid
input
usb-uhci usbcore ext3 jbd aic7xxx sd_mod scsi_mod
CPU: 1
EIP: 0060:[] Not tainted
EFLAGS: 00010202
EIP is at access_process_vm [kernel] 0x27 (2.4.20-8smp)
eax: 00000000 ebx: d443e980 ecx: e88e8000 edx: 00001000
esi: 00000000 edi: e2b2f000 ebp: e2b2f000 esp: c73b7f00
ds: 0068 es: 0068 ss: 0068
Process ps (pid: 924, stackpage=c73b7000)
Stack: c36af740 00000080 d443e980 00000000 e2b2f000 000007ff c010e568
d443e980
e88e8000 bffffefe 00000000 e2b2f000 00000000 e2b2f000 c87a0068
d443e980
00000000 e2b2f000 000007ff c017a22d e88e8000 bffffefe e2b2f000
000000f5
Call Trace: [] call_do_IRQ [kernel] 0x5 (0xc73b7f18))
[] proc_pid_environ [kernel] 0x6d (0xc73b7f4c))
[] proc_info_read [kernel] 0x77 (0xc73b7f6c))
[] sys_read [kernel] 0x97 (0xc73b7f94))
[] sys_open [kernel] 0xa2 (0xc73b7fa8))
[] system_call [kernel] 0x33 (0xc73b7fc0))
aka, something is wrong with the ram. This usually doesnt fix without a reboot but we've had so many problems with the box im afraid if we reboot it may not come back up.
the good news is at least we figured out the problem and we are now setting up daily backups to the new server box.
I may try a reboot after another backup if I can find some available time in case I need to drive down to the server. Also looking at other possible fixes. So hopefully we can get this solved and the server will be running ok until the new one is setup.
ps, I hate computers sometimes 