Red Hat Bugzilla – Bug 219498
sealert uses to much memory
Last modified: 2008-09-09 14:24:17 EDT
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.
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.
Created attachment 143928 [details]
memory usage just after start up, but before an alert has fired and been displayed
Created attachment 143929 [details]
memory usage after an alert has fired and been displayed
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
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
[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