Hi List

I have a somewhat of a problem but I don't know how serious it is or how
to handle it:

I manage several servers - quite a nice beasts, HP ML360G5 with 2 x dual
Xeons and 4GB ram each. Now one of the production servers is not
behaving all that well - it doesn't handle the load as well as I would
like it to and its responses are slower then what I would expect
according to previous benchmarks (on identical hardware, not on the
specific machine).

After doing some application testing and optimization, I still do not
rule out sub-optimal application behavior, but I noticed something
disturbing and I would appreciate some input on that - 

I use htop to monitor the server's load, and the load average is quite
low when the servers suffers under load, and the "cpu time" bars rarely
reach over 50%. Splitting the "cpu time" display in htop according to
system/IO-wait/hard-IRQ/soft-IRQ I can see that a lot of time is spent
in the "hard-IRQ" region - sometimes more then all other regions
together.

Running some static benchmarks that should mimic the behavior on real
load, on identical hardware at the office, I see very little "hard-IRQ"
time if at all. The main difference between the static benchmark and
real usage is that the static benchmark only tests the application logic
and IO, while real usage also fetches some files served by Apache over
HTTP with each request - maybe ~50Kbytes worth of responses are served
by Apache for each request to the application. I was thinking that the
high IRQ usage is due to high network traffic - could that be the case
and could that be affecting the server's performance ?

I'd appreciate any references that you can provide - searching the web
for "irq bnx2" (the NIC module used by the machine) yields nothing that
I could decipher.

Thanks in advance

--
Oded


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to