Performance with large printer database

Michael Sweet mike at
Thu Jan 27 13:07:11 PST 2005

Patrick Spinler wrote:
> Hi:
> I'm attempting to run a 4 node cups server cluster, cups 1.1.23-1 on 
> redhat enterprise 3.
> Our printer database is currently about 6000 definitions long.  This is 
> identical on each of the servers.
> On the servers, lpstat -a returns a list of all 6000 servers in about 8 
> seconds.   A wget of the cups admin printer list page returns in about 
> the same amount of time (although mozilla takes about a minute to parse 
> and display that page. :-)  ).
> As a test, I've set up a solaris 8 and a linux FC2 client, each running 
> a cups-1.1.23 package, with 4 BrowsePoll directives in each client's 
> cupsd.conf, one BrowsePoll for each of the print servers.
> what I am finding is that when I start the cups daemon on the client, it 
> immediately shoots to near %100 of the cpu, and stays there for hours 
> and hours.  during this time, it is wholely unresponsive to any request. 
>  For instance, I can't do a lpstat, or lpr, or anything, on the client. 
>  any such command simply hangs.
> Please advise me.  What, if anything, can I do?

First, unless your servers are on a different network, it will be
MUCH more efficient (read: less network traffic, faster client
responses) if you don't use BrowsePoll on the clients, and instead
just use BrowseAddress on the servers.

Second, tune the BrowseInterval and BrowseTimeout parameters; the
defaults are usable up to about 100 printers (which yields 3-4
printer updates per second).  If you have the defaults set on the
client, then they will be processing 800 printer updates per
second, which *will* bog the systems down.

Third, be prepared to need a lot of RAM on the clients; 4 servers
with 6000 printers apiece will yield 30000 printers on each client
if you have implicit classes enabled, which will need ~60MB of memory
to track them (the current overhead is ~2k per printer...)

You can split the printers up (e.g. so that each server handles half
of the available printers) to realize similar redundancy and load-
balancing but cut the memory, CPU, and network overhead on the

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software

More information about the cups mailing list