11 Replies Latest reply on Jul 31, 2013 8:10 AM by Scott Olswold

    Windows 2008 R2 Print Server Performance Tuning

    Michael Ward Wayfarer

      Hi All - I was wondering if anyone out there has any good documentation/resources/references with regards to Windows 2008 R2 print server performance tuning? I been searching around and have found plenty of general information, but nothing really addressing print servers specifically.

       

      We're having some issues (possibly performance related) on our busiest print servers, and I want to ensure they are optimally configured.

       

      Thanks

      Michael

        • Re: Windows 2008 R2 Print Server Performance Tuning
          Scott Olswold Guide

          The biggest issues with print servers are disk queuing (spool files writing to the hard disk) and printer drivers. If you are using Pharos Popup, the spool file is usually already rendered to the language of the driver (PCL or PostScript), so CPU is normally not a problem.

           

          What specific issues are you having?

            • Re: Windows 2008 R2 Print Server Performance Tuning
              Michael Ward Wayfarer

              The issues don't appear to be related to the typical print server performance issues - ie not CPU/disk/memory etc.

               

              All of our clients use a single secure print release ('FollowMe') queue configured on a number of print servers running UniPrint 8.3. We're having some Windows 7 clients (not necessarily restricted to Windows 7, just that this is what most clients are running) reporting print jobs 'disappearing' on our two busiest print servers. Ie they click print and everything seems ok. Go to release it from the secure release terminal and the job is not there. There are no alerts in Pharos or any other indication that the print job was actually even received by the print server - so for a while there we were calling it a client issue and investigating there. Yet when the user is moved to one of our other less busy servers, they no longer report the issue.

               

              I've been investigating port exhaustion as a possible culprit, and plan to put in place to registry tweaks to tcpip mentioned here An Unquiet Wiki: If you have to reboot your servers often, its probably port exhaustion. However, I'm not entirely convinced this is the case as the symptons don't really match what we're seeing and the number of connections don't seem that excessive (the busy servers typically have between 1,500 - 2,000 tcp connections during peak times). Still, the registry tweaks won't hurt.

               

              The lack of anything really specific to look at as the issue on the print servers lead me to post this question to see if anyone has any general performance tuning guidelines as I figured it wouldn't hurt to ensure it's properly tuned for optimal performance. If none is available, I'd suggest to Pharos Support it'd be something worth producing/providing!

               

              If anyone has experienced print jobs disappearing like this and/or has a solution, please let me know!

                • Re: Windows 2008 R2 Print Server Performance Tuning
                  Scott Olswold Guide

                  Michael,

                   

                  Ah. A limitation of Windows is that a single port monitor instance can only handle one print request at a time. If you're on Uniprint 8.2 or lower, you have a definite bottleneck, as the shared queue only has one Pharos port defined. In 8.3, the Secure Release Service attaches a number (10?) of Pharos secure ports to the shared queue in a pooled configuration. This has the advantage of allowing 10 simultaneous jobs to be handled, but if you have a single queue defined, you could be putting pressure on that configuration.

                   

                  Normally, a job sent to a queue that has no open port monitor will be put into a Waiting state by Spooler until it can be handled. Visually, you can see this by opening the shared queue and observing how many jobs you see there. If you have a list, then you have a very busy server indeed, but I don't understand why a job is not eventually in a state where it can be released.

                   

                  It may be a good idea to engage logging for the server through the LogSetter tool and see what is happening. You may wish to open an incident report with Pharos Tech Support as well. Also, ensure that you have all of the latest patches for your Pharos components. Go to www.pharos.com/support and click the Uniprint link in the left navigation bar, then click the appropriate version for Uniprint. Patches do not normally require server reboots, but do stop the updated component(s) when executed, so be sure to apply them in an appropriate outage window.

                    • Re: Windows 2008 R2 Print Server Performance Tuning
                      Michael Ward Wayfarer

                      Yeah we've experienced the issue you've outlined in one of our other Pharos UniPrint environments (we have three!) after upgrading to version 8.3, where the single FollowMe queue couldn't handle the number of jobs and started backlogging them. We resolved that by applying the latest Pharos updates and creating a second queue to distribute the load across.

                       

                      Unfortunately that doesn't seem to be what is happening on these servers. The queue itself doesn't appear to be overloaded, ie I can see the jobs being processed just fine with nothing being backlogged. As you say, if this was the problem, I'd expect the jobs to eventually be processed and be available for release.

                       

                      In our case though, the jobs appear to disappear from the client, with no evidence that they actually even made it to the print server itself (although given the large number of jobs going through the print servers and the time delays between a user reporting the fault and me investigating it, it's entirely possible I'm just overlooking the related print spooler event log entries on the server).

                       

                      I'd enable logging on the print servers but that tends to peg the CPU at 100% and really disrupt the environment, so it's not something I like to have enabled for extended periods of time. If I could replicate the problem it wouldn't be so bad as I could just enable it for the time it takes me to replicate it, but as it is, I'd have to leave it enabled until someone reports it.

                       

                      I haven't logged a support call with Pharos Tech yet as I'm not entirely convinced this is a Pharos issue (ie it seems to be more of a Windows issue) and I don't really have much solid data/information to go on. But will do if you think that would be the best way to proceed.

                        • Re: Windows 2008 R2 Print Server Performance Tuning
                          Scott Olswold Guide

                          Michael,

                           

                          Enable logging and look at the LPD Service log, as it is the one responsible for job acceptance. If there are errors here, or other weird behavior, this would be the first place to look. If all is quiet on the western front, then the next target is the SRS, since it takes jobs from LPD and shuffles them to the secure job store.

                            • Re: Windows 2008 R2 Print Server Performance Tuning
                              Michael Ward Wayfarer

                              Ok I was a bit wary about enabling the logging due to the hit on the server I mentioned earlier, but so far it doesn't seem to be affecting it too badly. Possibly version 8.3 is a bit more efficient with the logging?

                               

                              Anyway, I've been looking at the LPD logs and noticed that not every print job that goes through the system is logged - in fact, it only appears to log a job every minute or so, when there are actually many print jobs per minute going through these servers. Is the LPD service log selective in what it logs? Do I need to increase logging levels or something? As it is, if one of these disappearing print jobs happens - it likely won't appear in the log anyway.

                                • Re: Windows 2008 R2 Print Server Performance Tuning
                                  Scott Olswold Guide

                                  Michael,

                                   

                                  If the print server is REALLY busy, then yes, there can be an issue with the log capturing every print job because the buffer used to initially capture the info before writing it out to the log file can't keep up. But the LPD Service should be keeping up regardless. I realize that I haven't asked you what your software version is, beyond 8.3. Have you applied Service Pack 1?

                                   

                                  Regards,

                                  Scott

                                    • Re: Windows 2008 R2 Print Server Performance Tuning
                                      Michael Ward Wayfarer

                                      Yip I've applied Service Pack 1 plus all available hotfixes (as of a couple of weeks ago).

                                       

                                      I wouldn't say the server is execessively busy during peaks hours, but even during off-peak hours, it's only logging the odd print job to the LPD log. The log is mostly just filled with these lines:

                                       

                                      [28250926] :: [2013/07/27 09:35:23.112 P730 T818 d LPDService] [Sync Call] '(CListenerThread::PurgeWorkerThreads) Purging unused worker threads....'

                                      [28250927] :: [2013/07/27 09:35:23.112 P730 T818 d LPDService] [Sync] '(CListenerThread::PurgeWorkerThreads) Purging unused worker threads....' - Lock

                                      [28250928] :: [2013/07/27 09:35:23.112 P730 T818 d LPDService] [Sync] '(CListenerThread::PurgeWorkerThreads) Purging unused worker threads....' - UnLock

                                        • Re: Windows 2008 R2 Print Server Performance Tuning
                                          Scott Olswold Guide

                                          Wow. If that's the bulk of LPD Service logging, then are users going through a standard RPC/UNC connection to get to your print queues? The Print Server log should show the bulk of the activity. If you see a bunch of "error" lines (they have either an " e " or " e] " text pattern), let's go ahead and formalize this as a support incident, with feedback here for the rest of the community's use.

                                           

                                          Thanks!

                                            • Re: Windows 2008 R2 Print Server Performance Tuning
                                              Michael Ward Wayfarer

                                              Yip most users are mapping using standard Windows/Mac connections. A minority are using Pharos popups. No errors in the LPD logs.

                                               

                                              Have been doing some testing, and it looks like only the print jobs printed via popups appear in the LPD logs. Print jobs submitted via a standard network print queue (ie no popups) do not appear. Is this not expected behaviour or does this perhaps indicate a problem with our configuration/installation?

                                                • Re: Windows 2008 R2 Print Server Performance Tuning
                                                  Scott Olswold Guide

                                                  Michael,

                                                   

                                                  Since most users are mapping to the shared queue via normal methods (RPC in the case of Windows, UNC/SMB in the case of MacOS), you won't see any entries in the LPD Service log; that's only used for jobs hitting the server via LPR (Pharos Popup being a large contributor, but other clients can also send via LPR). This means that somewhere in the middle, your jobs are either being rejected by Windows Spooler (check System event logs) or Uniprint (check Alerts). The Print Service log is also very helpful here.

                                                   

                                                  Scott