Scale up, but don’t skimp
I recently helped out one of our biggest corporate customers to resolve issues with their print server.
During the last week of the financial year (when printing load is the highest) their print server became overloaded and stopped working. This sounds bad, but we quickly got things working smoothly again and learned that PaperCut scales incredibly well if you allocate appropriate system resources!
This customer had been running PaperCut for about 6 months without issue. Over this period they were gradually transitioning hundreds of print queues from legacy print servers to the server hosting PaperCut. This single print server was hosting all queues for their offices country-wide. The extra load of these additional print queues combined with the end-of-year printing load pushed the server to the limit.
When analyzing the problem I noticed that this server was handling a huge print load. In the 30-day period prior the following printing occurred:
- 477,287 print jobs
- 2,021,454 pages printed
- Between 22,000 to 25,000 print jobs each week day
Wow! That’s a lot of printing!
They were also using hold/release queues and Find-Me printing (aka pull printing) to provide secure print release and to reduce paper wastage. The result was an average of around 500-600 print jobs waiting in the queue to be released.
The cause of the problem was under resourcing. Their setup was:
- A single server hosting the both the print queues and the PaperCut application server
- The server was a virtual machine assigned only a single processor
- Allocated 3GB of RAM
- Running on a 32-bit Windows Server operating system
My recommendation was to leave the print queues on the existing server, but move the PaperCut Application Server service to a server with 4GB of RAM, 2 or more processors, and running a 64-bit operating system with the 64-bit add-on pack. This configuration:
- Spreads the load between 2 servers
- Allows the PaperCut Application Server to take advantage of more memory (64-bit)
- More available processors allowed efficient processing of simultaneous print jobs
Since making these changes, their system has been running very smoothly. Their servers are now handling more load than ever, and without overloading the servers.
If you’re managing a large PaperCut installation, and in particular leveraging some of PaperCut’s advanced print management features such as secure print release, then there’s a few lessons to take from this:
- Don’t skimp on RAM or CPU resources
- Monitor your servers. Particularly if you’re adding print queues and increasing print load
- Consider running a 64-bit OS to allow for future expansion (e.g. more memory)
- Run PaperCut on an external database like SQL Server, Oracle, PostgreSQL or MySQL
CC image courtesy of Emilian Robert Vicol on flickr