All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell Leighton <russ@elegant-software.com>
To: Brian Tinsley <btinsley@emageon.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: long stalls
Date: Tue, 07 Jan 2003 23:07:33 -0500	[thread overview]
Message-ID: <3E1BA405.4010104@elegant-software.com> (raw)
In-Reply-To: 3E1B8A19.6070602@emageon.com


I am pretty sure we are at 2.4.19.

Brian Tinsley wrote:

> Out of curiosity, which RH kernel are you using? I moved on to 2.4.19 
> and 2.4.20 primarily because the RH 2.4.18 series of kernels 
> apparently has a scheduler bug (at least one) that causes the 
> heartbeat software from Linux-HA to loose heartbeat signals and 
> failover. Not a good scenario when you are trying to provide HA 
> systems to hospitals!
>
>
> Russell Leighton wrote:
>
>>
>> I can't help, but I can echo a "me too".
>>
>> We only see it when I have 2 file I/O intensive processes...they both 
>> will just stop for some few seconds, system seems idle...then
>> they just start again. RH7.3 SMP, Dual PIII, 4GB RAM, 3com RAID 
>> Controller .
>>
>> Brian Tinsley wrote:
>>
>>> We have been having terrible problems with long stalls, meaning from 
>>> a couple of minutes to an hour, happening when filesystem I/O load 
>>> gets high. The system time as reported by vmstat or sar will 
>>> increase up to 99% and as it spreads to each procesor, the system 
>>> becomes completely unresponsive (except that it responds to pings 
>>> just fine - interesting!). When the system finally returns to the 
>>> world of the living, the only evidence that something bad has 
>>> happened is the runtime for kswapd is abnormally high. I have seen 
>>> this happen with the stock 2.4.17, 2.4.19, and 2.4.20 kernels on SMP 
>>> PIII and PIV machines (either 4GB or 8GB RAM, all SCSI disks, dual 
>>> GigE NICs). I've searched the lkml archives and google and have 
>>> found several similar postings, but there is never an explanation or 
>>> resolution. Any help would be *very* much appreciated! If any info 
>>> from the system in question is desired, I will be glad to provide it.
>>>
>>>
>>>
>>
>



  reply	other threads:[~2003-01-08  4:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08  0:42 long stalls Brian Tinsley
2003-01-08  1:51 ` Russell Leighton
2003-01-08  2:16   ` Brian Tinsley
2003-01-08  4:07     ` Russell Leighton [this message]
2003-01-08  4:00   ` Russell Leighton
2003-01-08 15:17   ` Juergen Sawinski
2003-01-08  2:44 ` Brian Gerst
2003-01-08  2:48   ` Brian Tinsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E1BA405.4010104@elegant-software.com \
    --to=russ@elegant-software.com \
    --cc=btinsley@emageon.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.