The box has 4GB of memory. Pound is using about 100MB. It has 2 Xeon
3.GHz processors. CPU utilization is between 3-10 percent for pound--
same as normal conditions, so CPU is not being used too much. The
machine doesn't do anything else, so the rest of CPU is idle.
The machine has 1Gbt card, but is set to 100 Mbt Full-Duplex. I'm not
sure how to check the packets/sec.
Anyway, I just looked at the archive, and found an email thread talking
about this problem exactly "blocked requests with increased concurrency"
on 4/29/07 from Khaled Hassounah. I don't think I have any other choice
but to upgrade Linux version. We'll try RedHat Linux ES 5, which is
running kernel 2.6.18, and hope it fixes the thread management problem.
Dave Steinberg wrote:
<snip>
taking 8-10 seconds. I understand that our network might be
saturated, but I don't understand why pound is being bottlenecked
within code where no network operations are being performed. This
sounds like a thread-management problem in the kernel. Has anybody
heard of this type of problem?
Under normal conditions (with 100 concurrent requests), the same
"for" loop takes under 0.100 milliseconds -- 30,000 times faster. Is
there anything I should check?
<snip>
I'd tend to agree with your gut feel. Something outside of pound is
changing the time it takes for pound to do the same job! What does
'top' report when you're at peak usage? I'm mostly curious if your
CPU is spending all its time processing interrupts instead of user code.
Any idea how many packets/second you're moving? Also - what are the
CPU / NIC / bus specs on this machine?
--
To unsubscribe send an email with subject unsubscribe to [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.
