Bug 135147

Summary: Excessive swap and cpu usage when system-logviewer loads
Product: [Fedora] Fedora Reporter: Andrew Farris <lordmorgul>
Component: system-logviewerAssignee: Chris Lumens <clumens>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-21 20:42:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace of python running system-logviewer none

Description Andrew Farris 2004-10-09 01:44:59 UTC 
Description of problem:
When system-logviewer loads (and subsequently when using the program)
an excessive amount of swap activity occurs with high cpu usage
(maxed).  Before the logviewer window is displayed over 400Mb of swap
space has been claimed by python.  After using the viewer for a short
period another block of swapping activity locks up the system so X
does not even refresh.  Occassionally the logviewer cpu usage will
cease and it will function normally for a short period before cpu
usage again maxes out.

Attaching to python from a vt and killing the process allowed X to
refresh again, system running fine.

Version-Release number of selected component (if applicable):
system-logviewer-0.9.11-1
gtk2-devel-2.4.10-7

How reproducible:
Consistent.  Repeated but only 3 times so far.

Actual results:
System becomes unusable while attempting to view logs.

Expected results:
Logviewer should display all logfile entries without consuming large
amounts of swap space.

Additional info:
system-logviewer was started from a root (su -) logged in terminal in
a normal user X session.

backtrace of python during this issue is attached
It appears to be stuck in a library call from gtk2-devel.

/usr/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.400.10
Comment 1 Andrew Farris 2004-10-09 01:45:55 UTC 
Created attachment 104967 [details]
backtrace of python running system-logviewer
Comment 2 Andrew Farris 2004-10-09 01:49:03 UTC 
This backtrace is not taken while the system is fully hung, I cannot
bring it to a complete hang state, but the backtrace does change at
different times while continuing under gdb.  It has been deeper, into
xft calls but this so if this is not very helpful I'd appreciate hints
how to recover something that will help more.  I am new to fairly new
to gdb.
Comment 3 Paul Nasrat 2004-10-11 09:21:42 UTC 
What is your refresh time set too in Preferences?

Which log are you viewing when this occurs.  What is the actuall log
file size:

ls -al /var/log/

Please could you show the memory usage via vmstat or top for
system-logviewer.

For more detailed X resource usage can you do (yum install xrestop):

xrestop -b | grep -A 14 system-logviewer

Whilst memory use is high.
Comment 4 Andrew Farris 2004-10-19 08:49:42 UTC 
I apologize for the delay in getting back to this one.  I had the requested
output but cannot find it.. and cannot reproduce the behavior anymore.  I will
make another attempt to push the program and see what happens, but (see below) I
think this may have been a problem "between chair and keyboard".  It is a shame
Bugzilla doesn't have a resolution to fit that.

What I did find out was that I had one messages logfile (I think it was rotated
and gzip'd but not positive now) that was 90+ Mb of runaway selinux spam.  The
refresh being used was default, which appears to be 30secs.  That might create
an unreasonable load on parsing the logs.

Perhaps logs of 'larger' size should not refresh, although the initial load
would still take a long time.  If this was simply a problem of my one large
logfile it made the system unusable while the process was still running, and
that should be avoided if possible.
Comment 5 Chris Lumens 2005-04-21 20:42:24 UTC 
system-logviewer has been removed from core.