Bug 219498 - sealert uses to much memory
sealert uses to much memory
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setroubleshoot (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-13 11:13 EST by Alexander Larsson
Modified: 2008-09-09 14:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-09 14:24:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
memory usage just after start up, but before an alert has fired and been displayed (45.69 KB, text/plain)
2006-12-18 14:23 EST, John Dennis
no flags Details
memory usage after an alert has fired and been displayed (47.63 KB, text/plain)
2006-12-18 14:24 EST, John Dennis
no flags Details

  None (edit)
Description Alexander Larsson 2006-12-13 11:13:08 EST
I noticed this process called sealert on my box using 22 meg RSS, 9 of which was
unshared. This ranks among the largest processes after login.

I notice its a python application that uses all sorts of stuff. Why does this
thing have to run all the time? Can't we have a very small c daemon that listens
to whatever it has to and spawns the gui part when it needs it.
Comment 1 John Dennis 2006-12-18 14:20:34 EST
I'm attaching two memory usage reports, one just after start-up and one after an
alert has fired and the gui displayed. Note virtually all the memory is the code
for shared python libraries, the greatest offender being GTK. Note also these
libraries should be shared with any other python application.

Since most of the memory is externally loaded code there are really only two
viable solutions for reducing memory usage, evicerate functionality or
rearchitect the application (in a manner similiar to the suggestion). We
considered the option of two session processes, one to listen for alerts and one
to display the alert information. For better or worse that option was rejected
because it introduced an extra process which needed to be managed and extra
communication logic. It was strongly suggested it was better to have everything
in one process. And hence this is where we are today.

The sealert process could be rearchitected to postpone loading shared libraries
until first use. But is it worth it? It's likely this would introduce bugs and
complexity, and for what gain? All you're doing is postponing the library loads,
 code memory which might be shared with other processes and which will proably
be swapped out in short order.

I agree with your observation the memory usage is high and it would be nice to
lower it. But I'm not convinced it is a problem in practice nor the engineering
effort to achieve a reduction in memory footprint is worthwhile. This is a
relatively new application and time will tell if this is real issue or a
cosmetic one. I'm going to leave the bug open but reduce its priority.
Comment 2 John Dennis 2006-12-18 14:23:17 EST
Created attachment 143928 [details]
memory usage just after start up, but before an alert has fired and been displayed
Comment 3 John Dennis 2006-12-18 14:24:38 EST
Created attachment 143929 [details]
memory usage after an alert has fired and been displayed
Comment 4 Alexander Larsson 2006-12-19 04:46:56 EST
How can this be such a low priority? We've spend a *lot* of time in this release
trying to get our memory use down as that is one of the major issues our desktop
had.

I don't see how it can be that hard to display the dialog in a separate process.
When showing a dialog, just spawn a child process and pass in the dialog text as
a commandline argument (or via an env var).

"Note virtually all the memory is the code for shared python libraries, the
greatest offender being GTK." - This is not true. Even in the "before" case you
have this:
  [anon]   :    8.73 MB         0 bytes    0 bytes    0 bytes    7.86 MB
Thats 7.86 megabyte of dirty private data. I.E. almost all the dirty data is on
the heap. Shared memory doesn't really matter, but private dirty memory most
definately does.

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