I have a Windows 2003 SP2 print server. There are over 100 print queues setup on the server. The server has 4 GB RAM and two processors. I receive complaints that printing becomes very slow, sometimes jobs take up to 15 minutes to print. If I reboot the server, that clears it up for about a week. then it starts all over again. Any suggestions on how to improve performance?
-
Are you doing any performance monitoring? Is there a resource bottleneck when this happens that the reboot clears? Is there anything relevant in the event logs? – MDMarra Jul 19 '12 at 19:25
-
1The first step in improving performance is identifying the cause of the performance problem. What have you looked at so far? CPU? Memory? Disk I/O? – joeqwerty Jul 19 '12 at 19:40
2 Answers
Are you seeing anything odd in the Event Log? Based on your description I'm immediately suspicious of kernel memory (paged or non-paged pool) exhaustion.
I'd take a look at the Performance Analysis of Logs tool as a way to get some general feeling for where the bottleneck lies with this issue. This tool "ingests" Counter Log files gathered by "Performance Monitor" and produces various reports for different server workloads. For you, I'd consider running the "SystemOverview" PAL threshold file to get a general feeling for the issue's cause. (The PAL tool can export a Performance Monitor template that will direct you as to what counters to store in the log file. If you're not familiar with Performance Monitor the PAL site has some good training items about PAL and logging.)
I strongly suspect a run of PAL with log data gathered from a clean boot up to the issue occurring will give you an indication of the cause of the issue.
![](../../users/profiles/7200.webp)
- 141,071
- 19
- 191
- 328
-
I should have mention, the server is a VMware virtual machine. I have added another processor, and will use PAL, to see if I can find out what is going on. thank you very much. – Mike Randolph Jul 19 '12 at 20:05
-
1I've got a very similar machine at the site I'm working at today-- a Windows Server 2003 SP2 machine running on ESXi 4.1 w/ 98 print queues, and it has good uptime and performance. I suspect you have a crazy printer driver at play. – Evan Anderson Jul 19 '12 at 20:08
-
Agreed. I had a VMWare VM with 1vCPU, 2GB RAM and over 100 queues that happily chugged along without issue until it was patch day. They all used the same HP UPD though so there weren't any driver issues to worry about. – MDMarra Jul 19 '12 at 20:45
-
@MDMarra: That sounds nice. I wish I could get away w/ just using the HP UPD. I'm stuck with a bunch of oddball copiers and printers on top of the usual HP suspects. No Xerox machines anymore, thankfully. I loathe their drivers. – Evan Anderson Jul 19 '12 at 22:51
-
@Mike Randolph Why are you adding another processor? I hope you realize that this will probably lead to longer CPU queue times for that VM - it will have to wait for as many processors (cores) as you allocate to it to be free at the same time. On a print server that shouldn't need the extra CPU cycles afforded by more procs/cores, you're probably doing more harm than good... not to mention that changing the number of vCPUs in a VM (after OS installation) can cause serious instability problems. I think you just shot yourself in the foot pretty hard here. – HopelessN00b Jul 20 '12 at 12:42
Without more data, any answers are going to be little more than groping around in the dark. As suggested, gather information from perfmon and/or the event logs. Post them here, and someone might be able to provide you with an accurate answer based on analysis, rather than guessing.
I would also suggest, however, that instead of rebooting the machine, next time, restart the print spooler. I've seen that work the majority of the time as a workaround while the root cause is uncovered, and it's probably preferable to bouncing the whole VM each time. (It would also help somewhat narrow down the scope of where to look for answers, should restarting the spooler service be as effective as a reboot.)
![](../../users/profiles/118258.webp)
- 53,385
- 32
- 133
- 208