2 of 2 people found this helpful
A good rule of thumb used to be: "Increase your infrastructure when the end users start complaining." Today, you can be a bit more proactive than that using something easy like PerfMon in Windows to create a benchmark of statistics, and use that as your baseline for the growth model. If your servers are virtual through VMWare ESX, you can use vSphere and other built-in tools to get the same data with less futzing around.
Good markers are:
- Total CPU. Remember that periods of high CPU utilization aren't inherently bad; it's not like the tachometer for an engine. Sustained periods can be a harbinger of doom, though. As long as the CPU itself remains in an operable thermo zone, don't worry too much about CPU if you're not planning on some major expansion. However, if you are considering adding more users, more devices, or other functionality (like MobilePrint), you'll need to expand your infrastructure to spread the wealth.
- Process CPU. Track the Pharos service processes on the server, and see how much of the total CPU usage they consume. If the Pharos Print Service is cranking 80% of the total CPU utilization (in an overall high CPU utilization scenario), it means it's time to expand. Conversely, if you are experiencing high CPU utilization and the Pharos processes are otherwise chill, you need to find out what is really consuming the CPU and determine if you can excise it from the server.
- Total RAM (as Private Working Set). Like CPU, high RAM consumption isn't necessarily bad, but it means that "where you are is where you are" and if you're looking at getting bigger, you'll need another server.
- Process RAM (as Private Working Set). Track the Pharos service processes' private working set RAM. Again, excessive RAM use by a process is a good indicator that you may need more infrastructure. If you have low RAM utilization in the Pharos apps, but overall high RAM utilization, cast the demon eating your RAM out!
- Free Disk Space. If you implement held Secure queues, you want to manage the free space on the disk that houses those held jobs, because it is awful to have print grind to a halt because the Spooler is saying "sorry, Charlie" to every inbound print job because it has nowhere to put it. Also, if you have separate drives for the operating system and the Pharos software, your server's "C" drive has to have space. It's typically where virtual swap is stored, temp files are stored, and important things like the Registry source files. If "C" runs out of space, a server rebuild is in your future...and nobody really has the time for that.
- Print Jobs in Queue. A high number of sustained jobs in queue means you have a bottleneck. The Pharos Secure Release Service manages a total of 10 secure ports for the secured queues (direct or held), which means that at any given moment, the server can handle 10 simultaneous jobs. If you have a lot of files waiting for an open port (a quick number: if the sum of your processing and waiting spool files is greater than 20, on average, during your work hours), it's time to create another server.
You can also do things like monitor the w3wp.exe process managing the Pharos EDI service, as well as any terminal service (HP, Xerox). IIS worker processes will generally appear to consume a lot of RAM and some CPU as part of their operation, but shouldn't be excessive.
As far as Windows 2008 support: I don't know what the future holds as far as Microsoft is concerned (I'm not too driven to check, but I'm certain it is bleak as it is now the 3rd generation server OS), but it still runs Pharos Uniprint 9.0.x. I wouldn't concern myself with expanding infrastructure just to accommodate OS support. Rather, I would invest the time to plan for operating system updates (either as an in-place OS upgrade to at least Windows 2012R2 if my current hardware supports it, or full migration to new hosts) in my current infrastructure. If you are going to build new, it is still important to look at your current baseline utilization to determine if the new hardware requirements are just to manage the new OS, or if you are going to require accommodating Pharos system growth, too.
I hope this helps! Server utilization, baselines, and optimization are not taught in most IT curriculums...those skills come from The School of Hard Knocks (or serverfault.com).
All the best,
Scott Olswold, That is very good advice (thanks).
You suggest using tools like PerfMon (Performance Monitor) which I've always found a "mysterious" to use and get useful data. Do you have some tips you can share?
For example, you recommend watching the Total CPU. I like using Resource Monitor ("perfmon.exe /res") to get a quick view of current CPU usage. Can you configure PerfMon to measure (in a more useful manner) the Total CPU? What items would be good to select?
Process RAM (as Private Working Set) - What PerfMon settings work well to look at this? Especially for the Pharos service processes.
Print Jobs in Queue - I can see how to look at the Jobs Spooling under Print Queue, but I'm not sure that is giving me useful info on sustained jobs in queue. How best to find # of processing and waiting spool files?
Thanks, and my apologies if these seem like noob questions.
- Paul L.
Without knowing what your situation looks like, it's very hard to say.
We have never run a second server for the purposes of failover or load. In the last decade, for ranges of 600 users doing $100k in chargeback annually we continue to have no problems running a server that is all self contained (SQL, Pharos, all services and components in one box) on a virtual machine with 2 CPU and 4gb RAM. We do have two of them, and technically really don't need them split at this point, it's more of a legacy function separation for us.
As for 2008, we'll be rebuilding our servers on 2012 this coming summer, *maybe* 2016 if Pharos says it's supported and the 2 updates by then work out some of the kinks. The servers have been running long enough that I prefer a rebuild to an upgrade for cleanliness and getting some of the old discontinued configs out of the way, not to mention getting a newer SQL in place. Because it's all virtual I'll just build a replacement in parallel, and then we'll swap over DNS once it's all tested.
To add a different point of view, our installation is using Windows failover clusters (Server 2008 R2) for both Principal and Print servers and has the SQL database in another failover cluster. This is to take advantage of the high availability this configuration provides. Server 2012 and above do not support clustering the print spooler as a discrete service like Server 2008 does, which means that to do this, you would have to host as part of a virtualized server instance. Since you have access to VM architecture, there would be no point. You would be adding a second layer of virtualization. Our upgrade path will be to move to stand alone VMs, possibly consolidating Principal and Print servers into one VM, still having a hosted SQL database in a separate cluster. We have seen considerable advantages to clustering, but it adds a layer of complexity also. Ultimately, we are comfortable with supporting the load and accept the risk of removing the HA layer.
Thanks for this idea. I also didn't know about the server 2012 not being helpful with clustering. I think if I get another server, it will more than likely be 2016 or whatever the newest OS is as that is more of a rule here with our systems team.
Thank you everyone, I guess I will have a new project after we do our update.
We do the same thing at least concerning SQL in our public library system. We actually installed everything on 2016 servers because we just started using Pharos about a year ago. Our environment consisted of 2 Uniprint/SignUp servers (serving separate buildings so no failover), a database server, an application server, and web frontend/MobilePrint server. We recently moved the database from a dedicated SQL server to SQL cluster. However, due to the print spooler change you mentioned, we still just have 2 separate print servers to divide the load. I'd like to have failover at the print spooler level and the MobilePrint application layer, but right now everything is on a VM which at least allows us to minimize any down time caused by hardware failures and maintenance.