Brion Vibber wrote:
On Wed, 17 Sep 2003, Luc Van Oostenryck wrote:
Thanks, it will not help you a lot but I don't
like the numbers for 'cached'
(70% of total RAM available / 50% of non swapcached), same for 'inactive'.
but anyway I never have liked the VM of Linux 2.4 and theese numbers are probably OK.
The server seems to respond a little better now than a few hours ago.
The huge iddle time is really a problem with new hardware it will be exactly the same.
The primary target of new hardware is larousse, which doesn't have much
idle time at all.
Just to be sure, Larousse is the Web server and Pliny the machine running the DB?
Such a memory
leak which reappear after 30 secs is also .. annoying.
Well, it hasn't come back yet, so cross them fingers...
How is the loadavg relatively to the
'normal' ? Huge is suppose?
Larousse:
18:58:11 up 8 days, 11:14, 1 user, load average: 17.64, 20.19, 20.15
Sadly, this is typical for the middle of the day. :( It's much higher than
the machine can comfortably handle.
Which explain the latency.
Pliny:
6:58pm up 38 days, 19:02, 1 user, load average: 4.63, 4.26, 3.75
This is typical and should be a comfortable level. Slowness on the wikis
from pliny right now is probably due to either Apache problems or database
locking issues. I'm open to suggestions.
Yes, this seems OK.
-- brion vibber (brion @
pobox.com)
Alas I'm a system/kernel programmer and I don't know apache or MySQL at all,
but database locking seems in effect to fit well with the problem.
Have something changed recently that can influence this?
Have you an idea about the excessive context switch in the previous 'vmstat 5'
output?
I can even hardly believe that 173000 cs is even possible and what can cause this?
This mean that a task can never use its timeslot and thus do any usefull work.
1200 - 2000 must probably be the right values?
-- Looxix