Re: Server response time discrepancy.

On Tue, Jul 01, 2008 at 12:57:23PM -0400, James wrote:
> Willy Tarreau wrote:
> >Good results have been shown on 2.6.22 and 2.6.25. But under low to
> >moderate
> >performance, many people report success with 2.6.18 shipped in RHEL5 or
> >CentOS 5.
> >
> >Willy
>
> Why do you say specifically low to moderate performance for 2.6.18 shipped
> in RHEL5 or CentOS 5? What issues do you see with using 2.6.18? I'm
> currently running HAProxy on that Linux version, and I'm wondering if thats
> a big cause of issues that I'm seeing (another thread open about this).

Well, in my experience, there are two situations where you can see a problem happen :

• exactly 50% cpu usage on all CPUs with a high context-switch rate can prevent the scheduler from giving a little bit of CPU to other tasks. That results in the CPU users to keep the CPU for themselves while other programs (eg: ssh) litteraly starve. This translates into long pauses in remote access and sometimes even vmstat. If I understood correctly, this was caused by the interactivity code which thought that the task sleeping 50% of the time and very often needed to pass in front of all others.
• 100% cpu usage with a high load with at least 2 processes per CPU, though you might need far more than that on 2.6.18+. You can have some tasks which never go to the CPU in this case (or rarely) though I don't remember the workload pattern which caused this.

Theorically, you could be in situation #1 with haproxy if you have only one CPU (or if you have nbproc equal to the number of CPUs). But this should not be permanent, it should only happen under certain loads. This is how I first noticed the problem, as haproxy may sleep and wakeup very often, depending on the traffic. Check if ssh to that machine seems responsive.

However you should not be in situation #2 due to the low number of processes started on a machine running haproxy, but this could happen on the servers themselves. And that could also impact the server's response time, of course. Once again, check with ssh.

Regards,
Willy Received on 2008/07/01 19:38