Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM

This kind of problem also occurred on two of my PCs. Both are connected to a Brother 2140 using a Raw-Socket.

The problem is the following: When I start to print a pdf (400kB) using evince the CPU usage of gs goes to 100% on one core and when the usage is reduced my memory will be blown up (physical and swap used to max).

The PDF is attached.

Same problem my PC - single core Pentium 4 flat-lining until I kill the gs process.

lp 2376 19.0 42.6 479544 438124 ? R 10:46 0:06 gs -q -sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE -dPARANOIDSAFER /var/spool/cups/tmp/foomatic-HHY4yi

Printer is CLP-300 connected to USB port (not turned on at as I write)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 9.10
Release: 9.10
Codename: karmic

(upgraded from Jaunty)

I have found out that the gs process was flat-lining the CPU because there were a number of PDF jobs in the print queue.
These PDFs are converted Powerpoint slides and seem to be printed very inefficiently.
One PDF has 6 pages - each page displays 6 ppt slides - ie. the PDF has been created from a PPT that has 31-36 slides.
It took 12 minutes to print these 6 pages.
The CPU is 1.6 Ghz single-core Pentium4.
This is similar situation to Thorsten above - he is also printing .PDF files.

The problem seems to be connected to the upgrade of Ubuntu 9.04 to Ubuntu 9.10. The process gs behaves on my computers completely normal if Ubuntu 9.10 is fresh installed. So the problem does not anymore occur on my computers.

i have installed fresh 9.10 but the problem seem to me. CPU 2.10 ghz. 2048 mb ram.

I have Ubuntu 9.10 freshly installed, yet i have the problem of gs and pdftotext taking up huge amount of CPU while downloading a bunch of pdf files using Transmission torrent client.

ubuntu 9.10 - 64 bit - Same problem when trying to print PDF on a network Canon printer,

Affects me as well, printing a PDF takes for ages, often more then 20 minutes, at times it seems hours (i print another way, say, give the pdf to a friend, and sometime in the afternoon my document get's printed) ...

one core of the cpu get's totally hogged

printer is a network printer, lexmark X342n, cups config:
MakeModel Lexmark X342n Foomatic/pxlmono (recommended)
DeviceURI lpd://192.168.0.155/PASSTHRU
State Idle
StateTime 1260521511
Type 8400916
Filter application/vnd.cups-raw 0 -
Filter application/vnd.cups-postscript 100 foomatic-rip
Filter application/vnd.cups-pdf 0 foomatic-rip
Filter application/vnd.apple-pdf 25 foomatic-rip
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job

forgot to mention, ubuntu 9.10, fresh install

In the last days the pxlmono driver in Ghostscript (the one which you are using) got vastly improved. I have applied the appropriate patches to the Ghostscript of Lucid. Please try a live CD of Lucid Alpha 1. Does printing go faster with it?

same problem, my system:

Ubuntu 9.10 (KK) 64 bits, fresh installation. Printer HP Deskjet D2460 Eons to print a PDF

Thanks in advance

David

I'm not even printing anything. I just turned the computer on, and had a processor at 100%. Ubuntu 9.10, fresh install, 32-bit.

Super_merlin -
Check your print queues - there is a good chance you have an old .PDF job in a print queue from a previous session.

Same issue with me, sending a pdf or ps to a printer on a headless server.

* Problem also occurs if scp'ing files and printing locally (i.e. lpr filename.pdf) - when leaving it (10 mins for a 3-page pdf on a 700MHz processor, it eventually came out).
* Print queue is empty

Till Kamppeter: Is it possible to rollback to an earlier version of that driver to test?

Everyone who is using the "pxlmono" or "pxlcolor" driver of Ghostscript (PCL-XL/PCL-6 drivers), please try a live CD of Lucid as to these drivers several fixes were applied recently. Please tell whether the fixed Ghostscript in Lucid solves the problem.

Till, thanks for that.

I have downloaded the Lucid Alpha nightly desktop ISO build from Jan 28th and installed it.
(This has taken a while because this is unstable on my PC - the graphical session keeps hanging)

I printed out the attached PDF to a Samsung CLP-300 (using monochrome, double-sided printing) and timed the process until page 1 & 3 have been printed. At this time the CPU drops, and the printer is ready for pages 2 & 4.

Karmic (fully patched) - 2 minutes, 45 seconds
Lucid (Alpha - 28th Jan nightly build) - 3 minutes

That is, the problem is not fixed in Lucid for me.

Everyone who has this problem please, I need the following information:

1. The file you tried to print. If you did not supply it yet, please attach it to the bug report. If the problem occurs for you directly after boot, please you have a file from the last session still in the print queue. You can find all stuck files in the print spool directory:

mkdir spoolfiles
sudo cp /var/spool/cups/d* spoolfiles/
sudo chmod 777 spoolfiles/*

Attach these files to this bug report.

2. How did you print? Which application did you use, which settings?

3. What is your printer/driver? Please attach the PPD file from /etc/cups/ppd/.

4. What is the Ghostscript command line. As sson as Ghostscript is running crazy, run the shell command "top" to see the offending "gs" process and note its process number. Then leave "top" with "q" and get the full Ghostscript command line via the shell command

ps auxwww | grep <process number>

Post the Ghostscript command line here.

5. Get an error_log in debug mode as described on https://wiki.ubuntu.com/DebuggingPrintingProblems in the "CUPS error_log" section. CUPS must be in debug mode while the offending job takes place. So clean up

cancel -a
sudo killall -9 gs

set CUPS into debug mode and print the offending file again. As soon as the problem occurs, attach error_log and do also the steps 1-4.

Further testing ...

I attached Lab01.pdf above.

Steps followed ..

david@thich:~$ cupsctl LogLevel=debug
david@thich:~$ cupsctl LogDebugHistory=999999
david@thich:~$ sudo /etc/init.d/cups restart
 * Restarting Common Unix Printing System: cupsd [ OK ]

david@thich:~$ evince /media/sda3/home/david/Desktop/Lab01.pdf &
(Printed document to Samsung CLP-300)

david@thich:~$ ps auxwww | grep "2407"
lp 2407 13.3 1.5 43904 31220 ? S 18:48 0:06 gs -q -dBATCH -dSAFER -dQUIET -dNOPAUSE -sPAPERSIZE=a4 -g9920x14032 -r1200x1200 -sDEVICE=pbmraw -dCOLORSCREEN -dMaxBitmap=500000000 -sOutputFile=|cat 1>&3 -_

david@thich:~$ sudo cp /var/log/cups/error_log .
david@thich:~$ sudo chmod 777 error_log

/var/log/cups/error_log is attached.

(from test above)

By testing with a similar driver ("foo2zjs" on the HP LaserJet 1020) I could see how the problem got caused. The driver requires incoming PDF being converted to PostScript and instead of using the desired call of Poppler's pdftops it used an awkward Ghostscript call which is only supported as a fallback. I have fixed this in the upstream BZR repository of foomatic-filters now. I will tell when the package for Lucid is ready and ask you to test a Lucid live CD again then.

In general the following classes of printers are covered by this fix: All printers with "Foomatic/foo2..." drivers, all printers with "Foomatic/Postscript" drivers, PostScript printers from Ricoh and OEM.

For printers using "Foomatic/pxl...." drivers you can already test a Lucid live CD now, as Lucid's Ghostscript has a possible fix for these printers.

Also some proprietary (manufacturer-supplied) drivers using foomatic-rip can have this problem and the fix in foomatic-filters will solve it.

This bug was fixed in the package foomatic-filters - 4.0.3-0ubuntu3

---------------
foomatic-filters (4.0.3-0ubuntu3) lucid; urgency=low

  * debian/patches/10_foomatic-rip-use-poppler-pdftops-with-cups.patch:
    CUPS manipulates $PATH when calling filters and this makes foomatic-rip
    calling CUPS' pdftops instead of Poppler's pdftops. This fails and so
    always the awkward Ghostscript/pswrite fallback is used, producing
    huge temporary PostScript files which the following process (driver
    or PostScript printer) renders very slowly or does not render at all
    due to excessive memory usage (LP: #463059).
 -- Till Kamppeter <email address hidden> Tue, 2 Feb 2010 13:14:17 +0100

Everyone who wants to test the fixed foomatic-filters in Lucid, please test with the next daily live CD or update your Lucid as soon as the fixed foomatic-filters package mentioned above hits the mirrors.

Uploaded SRU for Karmic to -proposed, package is waiting for appreoval. debdiff of the changes is attached.

Accepted foomatic-filters into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Brilliant !
I applied the 'foomatic-filters' patch in Karmic-proposed.
Earlier test in Karmic - 2 mins, 45 secs from clicking 'Print' button to job leaving queue (and CPU dropping)
Test with proposed patch - 1 minute from clicking 'Print' button to job leaving queue
ie. 2.75 times faster
Thanks.

Also tested job described on Nov 15 (on different but similar powered PC) -
'One PDF has 6 pages - each page displays 6 ppt slides - ie. the PDF has been created from a PPT that has 31-36 slides.
It took 12 minutes to print these 6 pages'
This job now takes 1 minute 20 secs - 9 times faster.

Tybion, thank you very much, we will include the fix in the automatic updates for everyone soon.

The fixed foomatic-filters package fixes also bug 325232.

This bug was fixed in the package foomatic-filters - 4.0.3-0ubuntu2.1

---------------
foomatic-filters (4.0.3-0ubuntu2.1) karmic-proposed; urgency=low

  * debian/patches/10_foomatic-rip-use-poppler-pdftops-with-cups.patch:
    CUPS manipulates $PATH when calling filters and this makes foomatic-rip
    calling CUPS' pdftops instead of Poppler's pdftops. This fails and so
    always the awkward Ghostscript/pswrite fallback is used, producing
    huge temporary PostScript files which the following process (driver
    or PostScript printer) renders very slowly or does not render at all
    due to excessive memory usage (LP: #463059).
 -- Till Kamppeter <email address hidden> Tue, 2 Feb 2010 13:33:17 +0100

Don't know if this deserves its own bug or not, but the fix here does not do the whole job for me. I have the new foomatic-filters (4.0.3-0ubuntu2.1) installed but still get the behavior described above when printing from windows. Set up is as follows -

A karmic desktop (P4, 2.4GHz, 1GB ram) with local printer Epson Stylus CX5200 installed in CUPS/gutenprint.
Wireless network supporting one karmic laptop and one vista laptop.

Using the lab01.pdf test file posted here, local printing takes about 30 seconds. Remote printing from the karmic laptop takes only a few seconds more. Remote printing from the vista machine takes 5 minutes. Watching a top screen, I can see that when the print job from karmic is running, ghostscript is not called. Cups runs, then gutenpr runs, then it prints. The job coming in from the windows machine however calls gs, which consumes 100% of CPU for 5 minutes. I grabbed the command line from ps:

lp 6143 100 2.7 40788 28152 ? R 10:29 0:35 gs -dSAFER -dCompatibilityLevel=1.3 -dAutoRotatePages=/None -dAutoFilterColorImages=false -dNOPLATFONTS -dPARANOIDSAFER -sstdout=%stderr -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/printer -dDoNumCopies -r600 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr -sOutputFile=- -dSAFER -dCompatibilityLevel=1.3 -dAutoRotatePages=/None -dAutoFilterColorImages=false -dNOPLATFONTS -dPARANOIDSAFER -sstdout=%stderr -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/printer -dDoNumCopies -r600 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -c .setpdfwrite -f -

This is after I restarted cups on the server and rebooted the laptop. We are not running samba here, just printing direct to cups across the network.

twowheeler, your problem is not the foomatic-filters bug reported by the original poster. The Ghostscript command line which you have posted in your comment is of the pstopdf CUPS filter.

Please report a new bug (package "cups") and tell also how you configured your printer on the Windows client. Also disable and clean your print queue with

cupsdisable <print queue name>
cancel -a

then print a job from the Windows client

and save the incoming job file
sudo -s
cp /var/spool/cups/d* /tmp
chmod 777 /tmp/d*
exit

and attach the file to this bug.

After that, run

cupsenable <print queue name>

This way we can use your file for further tests.

The problem is Evince.
I am currently using Lucid Lynx with HP PSC 1200 and replacing Evince with Acroread prints at usual speed much faster than Evince.
Evince is version 2.30.1-0ubuntu1

Today I hit jackpot again, having a D630 trying to print a PDF file with Evince to a HP Laserjet 3600 with 10.04. GS took one core to 100%, making system unresponsive again, it's hard to kill the basterd then ;)

Strange, I am printing PDF files for quite some time, why now, all of a sudden, this problem again? I start with replacing Evince for now.

If there are still problems with high resource consumption by Ghostscript, see bug 668800.

The foomatic-rip fix makes Ghostscript not being used and so works around a Ghostscript bug, bug 668800. In addition the Cairo bug 680628 makes the problem even worse. So if you have still problems, please discuss them in these bug reports.

precise pangolin affected too (wasn't the case in natty).

There's a new bug for precise (ubuntu 12.04): https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/668800

Resolved this issue by lowering and creating custom DPI values.

Default DPI from foomatic postcript PPDs is usually 600 DPI or 1200 DPI. Ghostscript `pdftops` and `gs` both take a long time converting high DPI values. The 600 DPI also creates a large postscript file which in turn are slow over the network as well as slow spooling on the printer itself. Printers have low RAM & small CPU.

When I lowered DPI to 300 the print jobs were almost instantaneous. However the print quality was degraded.

I modified the PPD files for dozen or so laser printers and found that 400DPI is identical to 600DPI in terms of print quality. With our printers I found the "sweet spot" to be 350DPI for print quality and maximum speed.

To get custom "time/quality sweet spot" DPI values, you will need to edit your PPD file:
cp /etc/cups/ppd/MYPRINTER.ppd $HOME/
Edit MYPRINTER.ppd 'Resolution' section and add 350 and 400 DPI.

*DefaultResolution: 350x350dpi
*Resolution 150x150dpi/150x150 DPI: "<</HWResolution[150 150]>>setpagedevice"
*Resolution 300x300dpi/300x300 DPI: "<</HWResolution[300 300]>>setpagedevice"
*Resolution 350x350dpi/350x350 DPI: "<</HWResolution[350 350]>>setpagedevice"
*Resolution 400x400dpi/400x400 DPI: "<</HWResolution[400 400]>>setpagedevice"
*Resolution 600x600dpi/600x600 DPI: "<</HWResolution[600 600]>>setpagedevice"

You may want to update the ModelName, ShortNickName and NickName to indicate that this file has been modified.

You can then either use the web interface to upload your custom ppd file or copy it to /usr/local/share/ppd/MYPRINTER.ppd
Then restart cups service. Your custom PPD option will then appear in the pick-list when Modify Printer.

Once the PPD is installed then go to the Default Options to set the DPI Resolution. You may want to test the timing/quality for 300, 350, 400, 600. I had 2 printers where 300DPI quality was just as good as the 600 DPI.

If an end-user enjoys the long print delay so they can socialize at the printer - or enjoys burning CPU cycles imagining that their 1200dpi is actually "better quality", then all they have to do is increase the DPI setting on the print dialog before they send their job.