CUPS 1.4.4 slow - problem checklist?

John A. Murdie john at cs.york.ac.uk
Mon Oct 18 08:55:11 PDT 2010


My department which uses CUPS 1.4.4 is finding it rather slow. Is there a standard list of potential problems I could check for? (I can't find such a list in the documentation.)

I'm seeing a cupsd taking 75-100% of CPU continually on a Slackware Linux 13.1 system running in a QEMU version 0.12.4 1GB virtual machine on a dual quad core Xeon system with 16GB memory. It has 18GB of spool space. It's serving roughly 40 printers and MFDs and perhaps 200 people (yes, lots of troublesome personal printers) with a mix of Linux and Windows desktops (the latter printing via a Windows print server to CUPS), and coping with a mere 10 or so jobs a minute at peak times. (I'd like to know how to get accurate statistics out of CUPS 1.4.4 - to monitor and graph them over time.) There is a second, independent, CUPS scheduler (but nothing else) on the same virtual machine, listening on a different port, with just four printers, whose variable data is on the same filesystem, which see perhaps 20 - 60 documents printed a day. We've run this configuration for several years - starting with CUPS 1.1 - and it's never been this slow. The cupsd.conf configuration file has not changed in months, though old queues have been deleted and new ones added. We do use cups-lpd to obtain the Windows print jobs, but I can see from /var/log/messages that we are not getting spurious requests from there.

The CUPS estimator http://www.cups.org/estimator.php, given:

  40   PostScript printers
   0   Non-PostScript printers
9x12"  Output size (virtually everything is A4, very little A3)
   4MB Print size (I don't know what our average size is, but mostly PDFs)
  10   Jobs to print concurrently (Average)
 500   Jobs printed each day (Guess!)
Daily  History (Arbitrary)

suggests a 800MHz system with 266MB of RAM and 4.4GB disc with MaxJobs 100 - a much poorer spec than what we have, and the value for MaxJobs is what we have set.

The one odd type of error message in error_log is one I've never been able to get to the bottom of - see http://www.cups.org/str.php?L3288 - but see only a few of them a minute, and they don't seem to cause the associated request to be rejected.

There is one stopped printer - out of toner and toner on order - with 20 or so documents waiting to print. I've paused that queue; don't see why that should make a difference, and it hasn't!




More information about the cups mailing list