[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#682426: gs using excessive memory, triggers kswapd storm



Control: tag -1 more info

Could you join the PDF?

Le 6 juin 2013 22:09, "Dominique Brazziel" <dbrazziel@snet.net> a écrit :
     I have been hit extremely hard by this bug for about a month
or two now, but it certainly wasn't present in the past.  On my
system the GUI completely freezes, the clock on the top panel stops
on the second after CUPS/Ghostscript/hpcups start doing their thing,
and all mouse and keyboard events are ignored.  Remote ssh sessions
become are unresponsive as well, so monitoring the system (htop, top,
etc.) is not possible.  The hang lasts for anywhere from 5 to 20 minutes
for just a 3 page pdf.

     I suspected high disk usage and review of the sysstat logs
(sar -d -p) confirmed extremely large average disk queue sizes, on the
order of 2000-6000 and sometimes higher.  Review of kernel logs shows
the kernel hung task process being executed as tasks have been
unresponsive for more than 2 minutes.

     One helpful tracker of what is happening is the atop monitor
which dumps data to it's log at 10 minute intervals.  By going
through chronologically until the interval in which the print
job was active I was able to see average disk queues leading up
to the time the job was active and the interval the job was active.
The default display shows kswapd occupying 16% of the CPU and
dozens of processes in uninterruptable sleep state (D).  gs was not
running at this point, but by changing the display to show memory usage,
I see virtual and real memory growth and size of 150M and 116M
respectively.   The iceweasel (firefox) process with ~15 tabs open
has virtual memory size of 1 gig but about 55M of real memory
and shrinking, as are the 8 to 10 chromium processes.

     I think there is a problem with kswapd on this kernel
(V3.8.2-686-PAE), and I have a relatively small system (1 gig RAM),
but 116 megs of real memory seems like a lot to print a small
html/text document and Fedora (17, 18) on the same hardware platform
(Intel Atom N270 w/1 gig of RAM) doesn't experience this extreme
stress or hang.

     I will check the version of ghostscript on Fedora and try and
recreate the problem with a similar memory load (i.e. firefox and
many chromium processes) and see what happens.


--
To UNSUBSCRIBE, email to debian-printing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] 1370549104.11049.23.camel@asusb202.MBA" target="_blank">http://lists.debian.org/[🔎] 1370549104.11049.23.camel@asusb202.MBA


Reply to: