Hi,
Jacob - thanks for your response .... I've tried the following things:
Routing - checked the routing used for the packets. The packets
don't seem to go through any firewall
Hardware - moved to the backup pound server and noticed the same
behaviour
Other processes conflicting for CPU priority - pound is the only
thing running on the box apart from the OS. Looking at the top dumps I
could not find a point where the load ever exceeded 1
In addition, I created a test page. I then got Nagios (a network
monitoring tool) to hit the page every minute once going through pound
and once going direct to the back end. I was then able to reproduce the
problem.
Nagios said that the page took 1 second to respond coming from pound.
The pound log said that the page took 4 seconds to be served. This
leaves a difference of 3 seconds that cannot be accounted for.
Is it possible that the pound times the entire time it took for the
page to be served to the client, i.e. it doesn't stop timing until the
client has received the entire page?
Can someone please clarify for me how pound does it's timing? I'm using
LogLevel 2 here.
Thanks,
Kaye.
Jacob Anderson wrote:
First step: Check your routing. Even though you can get to your pound
server, sometimes if your routing is bad, the return packet gets lost.
This
happens when you have a drop-in firewall that ARPs a route that is
inconsistent with the pound front end. I've done that myself and saw what
you are seeing.
Second step: tail -f /var/log/messages --> this will show you the pound
activity. Watch this for a day and wait to see if there are any weird
pauses
in the pound return.
Third step: Check your DNS routing. If the pound server is using named
resolution of the BE and that name resolution is flakey, then you will
see
intermittent delays in response.
Fourth step: Check your disk. If you have a bad disk, then you will
occasionally have an intermittent delay. Listen for clicks on the disk
while
it is in use.
Fifth step: Check other processes that may conflict for CPU priority.
Do you
have a PCI intense operation going on while inbound connections are
processing? Maybe you are using an SSL accelerator that is bad? If
pound is
waiting for a kernel resource before connecting to the BE then you
would get
a delay. Run "top" to see if something is taking you CPU or I/O
bandwidth.
Hope that helps.
-- Jake
-----Original Message-----
From: Kaye Ng [mailto:[email protected]]
Sent: Thursday, May 14, 2009 9:36 PM
To: [email protected]
Subject: [Pound Mailing List] Intermittent slow down problems
Hi,
I'm running pound version 2.3.1 in production. Each day I seem to be
getting intermittent slowdowns. For example I have a page which
normally
takes 4-5 seconds to load, but on occasion (around 1% of the time) the
page may take up to 250 seconds to load. This slowdown effect is not
restricted to this page, it seems to happen on many different pages
with
varying amounts of data returned. I have checked the apache log and
have
found no evidence that it's apache causing the problem. I also haven't
been able to reproduce this problem - so I'm kinda stuck.
My setup is as follows:
Pound server:
- Pound Version: 2.3.1
- Root Jail: No root jail
- OS: Centos 5.0
- DNS Version and Type: bind 9.2.4-3.2
Back end:
- OS: Centos 4.4
- Web Server: Apache 2.0.52.28
Has anyone else encountered this problem before? I can't seem to
reproduce the slowdown problem, so any ideas and suggestions would be
welcome.
Thanks for your help.
Cheers,
Kaye.
--
To unsubscribe send an email with subject unsubscribe to
[email protected].
Please contact [email protected] for questions.
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
