) v6u7, NIS.
Periodically some of the systems exibit high load average while idling
for no obvious reason. Rebooting solves the problem, but after some
time the symptom returns. Typically the load average reaches 3 and
wouldn't go beyond that. How would you approach such a problem?
One such system
identical Sun Fire X4100 systems here all configured
identically:
4-way Opteron, 4G RAM, 70G SAS HDD, RHEL AS 4U3, Sun Grid Engine
agents (SGE) v6u7, NIS.
Periodically some of the systems exibit high load average while idling
for no obvious reason. Rebooting solves the problem, but after some
time
I have 18 identical Sun Fire X4100 systems here all configured identically:
4-way Opteron, 4G RAM, 70G SAS HDD, RHEL AS 4U3, Sun Grid Engine
agents (SGE) v6u7, NIS.
Periodically some of the systems exibit high load average while idling
for no obvious reason. Rebooting solves the problem
I have 18 identical Sun Fire X4100 systems here all configured identically:
4-way Opteron, 4G RAM, 70G SAS HDD, RHEL AS 4U3, Sun Grid Engine
agents (SGE) v6u7, NIS.
Periodically some of the systems exibit high load average while idling
for no obvious reason. Rebooting solves the problem
HDD, RHEL AS 4U3, Sun Grid Engine
agents (SGE) v6u7, NIS.
Periodically some of the systems exibit high load average while idling
for no obvious reason. Rebooting solves the problem, but after some
time the symptom returns. Typically the load average reaches 3 and
wouldn't go beyond that. How would
Oren Held wrote:
Try to look for processes which are in zombie (defunct) state.
If I'm not mistaken, for some reason they tend to be counted when
kernel calculates the load average.
No, the list of zombie processes is available at the list Michael gave,
and it's empty. Besides, they are not
On 10/07/06, Michael Green [EMAIL PROTECTED] wrote:
time the symptom returns. Typically the load average reaches 3 and
wouldn't go beyond that. How would you approach such a problem?
Have you checked the system logs?
--Amos
=
To
So I had to reboot my (330 day uptime...) machine. I couldn't even
cleanly shut it down, because the NFS unmount never finished.
RH Magazine suggests some trick with rpciod, but I haven't tried it yet.
http://www.redhat.com/magazine/005mar05/departments/tips_tricks/
On Wed, Mar 30, 2005, Nadav Har'El wrote about Re: high load ?:
Unfortunately, crappy NFS implementations and the like are notorious for
leaving processes in the D state for very long times. This has much worse
It's funny - I was just bit today by this problem :(
Today, my work machine stopped
On Tue, Apr 05, 2005, Tzafrir Cohen wrote about Re: high load ?:
So I had to reboot my (330 day uptime...) machine. I couldn't even cleanly
shut it down, because the NFS unmount never finished.
umount -f? umount -l
Umount -f didn't help (it simply hanged). I didn't think of trying umount
On Fri, Apr 01, 2005 at 03:35:36AM +0300, guy keren wrote:
to hold a semaphore, or because we're already holding some other
semaphore?
good point, sorry for not being clear. To sleep on a semaphore while
waiting to acquire it. Specifically - see
arch/i386/kernel/semaphore.c, __down(), which
On Wed, 30 Mar 2005, shimi wrote:
Generally, updating a big table all the time is a BAD IDEA, and should
_never_ be done. The main question is: is it requirable that the table
be up-to-date according to the last INSERT/UPDATE you just did, or that
you just want it to be updated some when, as long
On Wed, 30 Mar 2005, Muli Ben-Yehuda wrote:
On Wed, Mar 30, 2005 at 05:19:23PM +0200, guy keren wrote:
since when does 'D' state means a process is holding a lock? there are
many situations in the kernel that processes are put to sleep while not
holding any lock (at least as far as i saw
On Wed, Mar 30, 2005 at 09:25:29AM +0200, Shachar Shemesh wrote:
Processes should never spend too much time in the D state. The very
fact that certain activities mean you are almost guaranteed to see
processes in the D state means there are bugs in the kernel.
Why do you think so? D means
On Wed, Mar 30, 2005 at 09:25:29AM +0200, Shachar Shemesh wrote:
guy keren wrote:
[snip]
Processes should never spend too much time in the D state. The very
fact that certain activities mean you are almost guaranteed to see
processes in the D state means there are bugs in the kernel.
Muli Ben-Yehuda wrote:
On Wed, Mar 30, 2005 at 09:25:29AM +0200, Shachar Shemesh wrote:
Processes should never spend too much time in the D state. The very
fact that certain activities mean you are almost guaranteed to see
processes in the D state means there are bugs in the kernel.
Why
Yedidyah Bar-David wrote:
You may have to tweak the numbers a bit, but it seems about right. A
different question is whether, under this scenario, the load average is
still the right metric to look at? I think it is. If the load average is
2, my shell still have quite a queue to wait for being
Firs of all, thanks for the responses.
To get you more details to chew on.
We found the problem and solved it but I would be glad to see how other
would attack the problem with this extra information:
Basically on every hit the database write a row in a table in MySQL.
The server gets about 5
On Wed, Mar 30, 2005 at 10:36:07AM +0200, Shachar Shemesh wrote:
Yedidyah Bar-David wrote:
You may have to tweak the numbers a bit, but it seems about right. A
different question is whether, under this scenario, the load average is
still the right metric to look at? I think it is. If the
Gabor Szabo wrote:
Firs of all, thanks for the responses.
To get you more details to chew on.
We found the problem and solved it but I would be glad to see how other
would attack the problem with this extra information:
Basically on every hit the database write a row in a table in MySQL.
The
On Wednesday 30 March 2005 10:18, Muli Ben-Yehuda wrote:
Why do you think so? D means that a process is holding a lock. Do you
mean bugs in the sense of long lock holding times?
Even worse, I have seen too many occasions when long actually
was unbounded. When kernel code does uninterruptible
On Wed, Mar 30, 2005, Yedidyah Bar-David wrote about Re: high load ?:
This is so only if you have load only on the CPU. If, for example, you
only have one process running, but which does a lot of paging, your
load average will be =1, but the responsiveness will be quite bad,
as your shell
On Wed, 30 Mar 2005, Muli Ben-Yehuda wrote:
On Wed, Mar 30, 2005 at 09:25:29AM +0200, Shachar Shemesh wrote:
Processes should never spend too much time in the D state. The very
fact that certain activities mean you are almost guaranteed to see
processes in the D state means there are
--=-WHb7yYBfPjIjPgE5Ple/
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Wed, 2005-03-30 at 10:42 +0200, Gabor Szabo wrote:
Firs of all, thanks for the responses.
To get you more details to chew on.
We found the problem and solved it but I would be glad to see how other
would
On Mon, 28 Mar 2005, Oron Peled wrote:
The load average is not in percentage. The load average numbers are the
average number of processes waiting/using for CPU in the last 1, 5
and 15 minutes [remark: on Linux processes in the 'D' (uninterruptible
sleep) are weirdly in this count also].
guy keren wrote:
On Mon, 28 Mar 2005, Oron Peled wrote:
The load average is not in percentage. The load average numbers are the
average number of processes waiting/using for CPU in the last 1, 5
and 15 minutes [remark: on Linux processes in the 'D' (uninterruptible
sleep) are weirdly in this
I am dealing with a server that should handle traffic from a few
hundred automatic
agents accessing it on more or less regular basis.
While we were at around 200 agaents the system worked fine.
Now that we are at nearly 400 agents.
The load average that used to be at 0.6 now is 1.2-1.9 most of
On Monday 28 March 2005 11:03, Gabor Szabo wrote:
One of the things which is not clear to me is that it seems there is a
total lack of connection between the average load and the CPU states.
Could someone explain why that would be ?
The load average is not in percentage. The load average
On Mon, Oct 20, 2003 at 08:58:19PM +0200, WildLove - Elad Almadoi wrote:
Hey!
[snip]
Here's my 'top' command:
8:56pm up 3 days, 23:41, 1 user, load average: 27.03, 19.53, 15.26
426 processes: 395 sleeping, 3 running, 28 zombie, 0 stopped
CPU0 states: 8.8% user, 11.2% system, 0.0% nice,
Hey!
I'm runing IBM xSeries 335 (aka IBM x335) with:
IBM x335 rackmount (xSeries)
CPU: Dual Intel Xeon 2.6GHz (533MHz)
Hardrives: IBM 36.4GB 10K-rpm Ultra160 SCSI Hot-Swap x 2 (1 is connected as
a mirror (raid-1) for constant backup
Operating System: RedHat 7.3 + Ensim Pro 3.5.19
RAM: 1.5 GB DDR
Hi,
AFAIK:
The load average is the number of tasks in your CPU's input queue. Since
you have more than 1 CPU, the system tries to break each job it has to as
many task it can, so each will be processed in a different CPU.
Meaning: you should have a hieghier load average. I think the results are
: Monday, October 20, 2003 10:15 PM
Subject: Re: High load average on IBM xSeries 335
Hi,
AFAIK:
The load average is the number of tasks in your CPU's input queue. Since
you have more than 1 CPU, the system tries to break each job it has to as
many task it can, so each will be processed
]
Sent: Monday, October 20, 2003 8:58 PM
Subject: High load average on IBM xSeries 335
Hey!
I'm runing IBM xSeries 335 (aka IBM x335) with:
IBM x335 rackmount (xSeries)
CPU: Dual Intel Xeon 2.6GHz (533MHz)
Hardrives: IBM 36.4GB 10K-rpm Ultra160 SCSI Hot-Swap x 2 (1 is connected
as
a mirror (raid
On Mon, Oct 20, 2003 at 08:58:19PM +0200, WildLove - Elad Almadoi wrote:
Hey!
I'm runing IBM xSeries 335 (aka IBM x335) with:
IBM x335 rackmount (xSeries)
CPU: Dual Intel Xeon 2.6GHz (533MHz)
Hardrives: IBM 36.4GB 10K-rpm Ultra160 SCSI Hot-Swap x 2 (1 is connected as
a mirror (raid-1) for
1. The load average is 1,5,15 minutes.
2. You're right. the memory is almost all used. I think a restart for the
services (Apache+MySQL), might do some good at freeing some memory.
3. Swapping can also explain about busy I/O are slow response to disk
commands (like ls and friends). I think this
On Tue, Oct 21, 2003 at 12:14:51AM +0200, Lior Kaplan wrote:
1. The load average is 1,5,15 minutes.
2. You're right. the memory is almost all used. I think a restart for the
services (Apache+MySQL), might do some good at freeing some memory.
Unless this is some runaway process which won't be
, when there's almost none usage of the apache and
the SQL, it's also dropped down to 0.*
It there any kind of config in the apache may cause it?
- Original Message -
From: Tzafrir Cohen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 4:33 AM
Subject: Re: High load
Hi,
I just setuped a new server. It is only running postfix at this time,
relaying mail from another server.
The distribution is RedHat 7.3 with all of the updates.
There is a large amount of mail in the queue (about 17k mails).
The load average goes upto 8.x. If I kill postfix, it goes back
On Thu, 14 Nov 2002, Sagi Bashari wrote:
Hi,
I just setuped a new server. It is only running postfix at this time,
relaying mail from another server.
The distribution is RedHat 7.3 with all of the updates.
There is a large amount of mail in the queue (about 17k mails).
The load average
I/O bound?
Being killed by the journalling overhead of ext3?
Insufficient RAM to cache the files being accessed in the disk
(improbable)?
My first guess is that this has to do with interaction of postfix with
ext3 journalling.
Things to check/try:
- Is the system actually I/O bound?
- What
Hello Sagi,
Maybe limit the number of postfix processes (of some kind?)
No, it's not that:
[sagi@black sagi]$ ps auxww|grep -ic postfix
77
[sagi@black sagi]$
Command w or uptime shows number of processes that are waiting for CPU
AND number of processes that stuck for one or other reason
Take a look here:
http://www.stahl.bau.tu-bs.de/~hildeb/postfix/ext3.shtml
Cheers,
Henry
Sagi Bashari wrote:
On 14/11/2002 13:51, Tzafrir Cohen wrote:
On Thu, 14 Nov 2002, Sagi Bashari wrote:
Hi,
I just setuped a new server. It is only running postfix at this time,
relaying mail from
That's where I took the original command from.
I can't change the partition settings or repartition the harddisk
because /var is a very big partition that is also used for data
(database,web).
However i have empty 6GB partition on the harddisk. I don't need that
much for spool directory, is
Quoting Sagi Bashari, from the post of Thu, 14 Nov:
I can't change the partition settings or repartition the harddisk
because /var is a very big partition that is also used for data
(database,web).
time to split it up. worth a few minutes of downtime to improve
relyability and performance.
On 14/11/2002 16:50, Ira Abramov wrote:
Quoting Sagi Bashari, from the post of Thu, 14 Nov:
I can't change the partition settings or repartition the harddisk
because /var is a very big partition that is also used for data
(database,web).
time to split it up. worth a few minutes of
Quoting Sagi Bashari, from the post of Thu, 14 Nov:
time to split it up. worth a few minutes of downtime to improve
relyability and performance.
I only have remote access to the server (it is colocated).
I asked here few weeks ago if there is a reason to put /var/www
somewhere else
On 14/11/2002 17:30, Ira Abramov wrote:
Quoting Sagi Bashari, from the post of Thu, 14 Nov:
I can move /var to / and repartition /var. But I have software RAID
running on this drive. Is it safe to do, remotely, when software RAID is
activated on / and /home?
probably OK, but you won't
: [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 5:56 PM
Subject: Re: postfix causing very high load average
On 14/11/2002 17:30, Ira Abramov wrote:
Quoting Sagi Bashari, from the post of Thu, 14 Nov:
I can move /var to / and repartition /var. But I have software RAID
running
problem caused by nfs mount hangs,
especially it happens when using nfs over tcp and with eepro100 card.
If you have one of above the odds are this is it.
Hope it helps
Elya
Schlomo Schapiro wrote:
Hi,
I am suddenly getting a very high load (10) but the actual number
similar problem caused by nfs mount hangs,
especially it happens when using nfs over tcp and with eepro100 card.
If you have one of above the odds are this is it.
Hope it helps
Elya
Schlomo Schapiro wrote:
Hi,
I am suddenly getting a very high load (10) but the actual number
On Thu, 17 Aug 2000, Schlomo Schapiro wrote:
How can I find out what program is causing this high load (as I understand
the load reflects the number of processes spawned per second.
the 'load' reflects the average number of processes in the 'ready' state
in the last 1, 5 and 15 minutes. you
and with eepro100 card.
If you have one of above the odds are this is it.
Hope it helps
Elya
Schlomo Schapiro wrote:
Hi,
I am suddenly getting a very high load (10) but the actual number of
processes stays more or less constant. Also the CPU utilisation is low
(10
it helps
Elya
Schlomo Schapiro wrote:
Hi,
I am suddenly getting a very high load (10) but the actual number of
processes stays more or less constant. Also the CPU utilisation is low
(10%). This is a PIII 500MHz with 256 MB RAM (which was not detected
automatically
Hi,
I am suddenly getting a very high load (10) but the actual number of
processes stays more or less constant. Also the CPU utilisation is low
(10%). This is a PIII 500MHz with 256 MB RAM (which was not detected
automatically, btw). The problem is that this high load is blocking all
kind
Try "top"
From: Schlomo Schapiro [EMAIL PROTECTED]
To: Linu-IL Mailing List [EMAIL PROTECTED]
Subject: Strange very high load
Date: Thu, 17 Aug 2000 18:15:31 +0300 (IDDT)
Hi,
I am suddenly getting a very high load (10) but the actual number of
processes stays more or less cons
55 matches
Mail list logo
