Bug 176031 - gnome-terminal must be reniced if monitoring logs
gnome-terminal must be reniced if monitoring logs
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-17 17:29 EST by Paul Dickson
Modified: 2015-01-04 17:23 EST (History)
2 users (show)

See Also:
Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-19 19:28:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Dickson 2005-12-17 17:29:37 EST
Description of problem:
If I leave a gnome-terminal window monitoring a log (messages or maillog) for a
long duration (I'n sure of the lower bounds, but a day or more), gnome-terminal
becomes extremely sluggish.  Like 5 to 10 seconds for redraw or responding to
mouse clicks (text and tab selecting).

No disk I/O is taking place (no swapping) during these 5 or more seconds delay.

The only solution is to do a "renice -5" to the gnome-terminal parent process.

Is there a way to automate the renicing of gnome-terminal?


Version-Release number of selected component (if applicable):
kernel-2.6.14-1.1765_FC and everyone since release of FC3

How reproducible:
Always after several hours.

Steps to Reproduce:
1. ssh to a remote host
2. tail a semi-active log file
3.
  
Actual results:
After nearly a day, all gnome-terminal windows become sluggish with user input.

Expected results:
Remain reponsive, like it does with renice -5

Additional info:
I usually have 13 subprocesses under gnome-terminal monitoring the logs on other
machines (via ssh).  This is a 300MHz Pentium II notebook.  Not especially fast,
but once I do the renice, it's very adequate.
Comment 1 Dave Jones 2006-03-05 00:33:47 EST
Sounds like a memory leak.  Does it still happen with the latest updates ?
Comment 2 Paul Dickson 2006-03-05 22:04:37 EST
Leaving the system up for 16 days and gnome-terminal reniced, the only lag is
from swapping.  The problem I've reported happens with no hard disk activity.

My opinion is that the Linux scheduler moves gnome-terminal further from
interactive towards a background process when logs are monitored.

I've rebooted the system with kernel-2.6.15-1.2009.4.2_FC5 and I'll report
tomorrow about happens.
Comment 3 Paul Dickson 2006-03-05 22:05:11 EST
Leaving the system up for 16 days and gnome-terminal reniced, the only lag is
from swapping.  The problem I've reported happens with no hard disk activity.

My opinion is that the Linux scheduler moves gnome-terminal further from
interactive towards a background process when logs are monitored.

I'll rebooted the system with kernel-2.6.15-1.2009.4.2_FC5 and I'll report
tomorrow about happens.
Comment 4 Paul Dickson 2006-03-18 00:35:00 EST
Sorry for the delay.

Overall, I'd say the situation is both better and worse.

I no longer see the long delays when the system is idle.  The gnome-terminal
windows refresh in a second or less.

But when the system becomes busy, say yum stops disk I/O to do some computing,
the  delay can become very long.  Upwards of 15 seconds before gnome-terminal
will redisplay.  I pretty sure that swapping isn't being done as there are
periods of upto one second between harddisk LED flashes.

But this latter case is hard to characterize and also difficult to duplicate.
This machine is max'd out with 256 MB of RAM, making yum a difficult a program
to co-exist with.

Since the idle case no longer happens, you can close this.

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