Bug 31617 - [VM balance] top/ps/procinfo lock up under high load.
[VM balance] top/ps/procinfo lock up under high load.
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-03-12 22:05 EST by Ed McKenzie
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-09 14:58:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
spawn.py (682 bytes, text/plain)
2001-06-11 22:51 EDT, Ed McKenzie
no flags Details

  None (edit)
Description Ed McKenzie 2001-03-12 22:05:06 EST
Under high load, top/ps/procinfo stop updating, while other applications
seem to keep running (slowly, of course.) top can lock up and stop updating
for two to three minutes at a time!  I would hope that psutils would be no
less responsive under load, as that's basically the only way to rescue a
box that is thrashing to death.
Comment 1 Glen Foster 2001-03-19 10:26:29 EST
We (Red Hat) should really try to fix this before next release.
Comment 2 Arjan van de Ven 2001-03-27 11:16:30 EST
A fix for this is in Linus kernel 2.4.3-pre8
Unfortionatly, this fix has caused major instabilities.
We're hoping to get a stable fix as soon as possible
Comment 3 Ed McKenzie 2001-06-11 22:42:52 EDT
I don't think 2.4.3 fixed it, as 2.4.5-0.2.9 is no better than the 7.1-release

I've attached a python script to help demonstrate the problem.  Run this script
in one terminal and wait for it to stop spawning threads; after it's done, run a
ps aux in another terminal.  Alternately, if you have *alot* of patience, try
starting top in another terminal.

It's not nearly so bad under normal circumstances, but in any case ps and top
aren't very useful under high load.  FreeBSD does quite well on this test
compared to Linux 2.4.
Comment 4 Ed McKenzie 2001-06-11 22:51:18 EDT
Created attachment 20803 [details]
Comment 5 Ed McKenzie 2001-08-09 14:58:08 EDT
It turns out this problem is caused by VMA fragmentation in heavily threaded 
processes.  Watching ps output, there's a marked slowdown as it prints stats 
for threads.  glibc issue?  Kernel issue?  Who knows.  For now, don't run lots 
of threads on Linux ...

Note You need to log in before you can comment on or make changes to this bug.