hellbound wrote:
he keeps saying your system have hardware problem which I don't believe is the case.
Without seeing the evidence provided by a hardware diagnostic tool, I too find this to be a dubious conclusion. Which aspect of the hardware does he suspect and what tools/configurations has he used to test his theory? I have experienced problems with Dell hardware previously, but these were very infrequent kernel panics under heavy I/O on a PERC5 RAID controller. I use Linux's md RAID these days on 'standard' controllers on PowerEdge 1950 and 2950 (I think, although I've never seen them) with no problems. I don't think I've ever run a kernel older than 2.6.15 on these servers though; they'll probably work, but I can't vouch for them.
For what it's worth I'm using 64-bit Gentoo. As you have 4GB of memory you really should be using a 64-bit OS too. This applies to both
Windows and
Linux.
Quote:
I think must be something to do with asterisk's build for i686 or something that is not well adjusted in compiling.
If you were seeing bursts of 100% CPU usage during the delays then that might be a valid thing to check. However I thought you said your system looks idle?
Quote:
so I'm kinda blank where to search for the source of this problem. besides I would like to learn what is the issue so I can track similar error later as well.
This is not a Linux support forum, so we are veering very much off-topic. With this is mind I shall just give you a brief list of things I would check or tools I might use: kernel boot flags (especially APIC and ACPI)
tail -F /var/log/messages /var/log/mysql.log /tmp/a2billing_agi.log etc etc (try to see what it's doing when the delay occurs)
wireshark or tcpdump (the delays may not be introduced by your machine, eg DNS resolution)
bonnie++ (or some other IO throughput measurement tool)
htop
iotop
latencytop
strace -fF asterisk