Q - We are going to upgrade to a new Windows Server 2012 R2 for PSQL 11 64-bit by the end of the year.

Does PSQL take advantage of additional Intel processor cores and/or give some advice or algorithms on the amount of RAM that should be installed in that box? Elliott is the only server-based software that will be in used on that box, but it also runs the Web interface to the Elliott eStore front end.

The answer always seems to be the more RAM the better regardless of the application, but are we talking 32, 64 or 128 GB?  What does Netcellent's experience suggest?

A - First of all, we have to make clear that we are not experts in hardware. Generally, most new servers nowadays will be sufficient to run as the Elliott database server.  The following recommendations are some additional issues for you to consider.

Virtualization Issue

On the issue of virtualization, the requirements for a virtualized server are different from a physical server.  Virtualization has a lot of benefits and will give you a lot of flexibility on server hardware usage.  It also helps you to back up your server.  This is something you should consider as an overall IT strategy for your organization, not just for the Elliott database server. PSQL 12 has a more friendly license than PSQL 11 to use in the virtualized environment.  PSQL 12 only checks the server NETBIOS name for licensing verification.  On the other hand, PSQL 11 checks many hardware components, including the size of the memory, CPU, motherboard, disk and MAC address.  As many of you know, in a virtualized environment you can easily change the number of CPUs and memory size.  Unfortunately, that will break the PSQL 11 license.

Virtualized Database Server Pros & Cons

There is a debate on whether the database server should be virtualized or not.  On one side, there are people who believe the database server should run as fast as possible -- since the virtualization is another layer on top of the hardware and makes it run somewhat slower, we should not virtualize the database server. On the other hand, there are people who believe that since there are so many benefits with virtualizing the server, even if it runs somewhat slower, it is still a better way to go.  We don't take a particular stand on this subject.  We just want you to know that there is such a debate out there.

CPU Issue

Let’s assume we are talking about a traditional physical server here. I would suggest that your CPU should have at least 4 cores and preferably 8 - 16 cores. Any more cores than that is unlikely to benefit your PSQL server’s performance for Elliott's user base. This includes the Web services. But you could add more roles to this server in the future. Therefore, adding more cores to prepare for that possible role expansion may not be a bad idea. Of course, this all depends on how much money you need to spend to add the additional cores. 

Test Hyper-Threading

For the same money, between a faster CPU and more CPU, we would suggest that you go with a faster CPU.  Faster CPU does not necessary mean higher clock speed.  In many case, the amount of L1 or L2 cache for the CPU is an important determined factor.  In the past, with older generation CPU, enable hyper-threading will make Elliott run slower. Hyper-threading doubles your server's logical CPU cores at the expense of running each logical CPU at slower speed.  However, with the newer generation of CPU nowadays, we found that Hyper-Threading does not negatively affect the overall performance.  In some case, it even make Elliott run faster.  The only way to know whether Hyper-Threading will benefit your particular server is to perform an actual test.

The typical test we use is to run Elliott A/R Aging Report on the PSQL server console and see how long it will take to complete. When you run the first test, the PSQL has to fetch data from disk to the memory and it is typically slower. For that reason, we don't use the first test number.  For the 2nd test immediately follow, the PSQL already have the needed A/R aging data in the memory, so the aging report will run much faster.  We will use the 2nd test for the bench mark test comparison. Therefore, you will run the two A/R aging report (detail format) on the PSQL server console and compare the result of the 2nd test with our without Hyper-Threading on.  If you don't find meaningful performance advantage with Hyper-Threading off, then leave the Hyper-Threading on. 

If you don't have time to perform this test, the Hyper-Threading is turned on by default. You can leave Hyper-Threading on. The following is an example that shows Hyper-Threading is on where there's 20 cores and 40 logical processors in task manager.

Memory (RAM)

In terms of memory, it is true that this is a key factor in determining the PSQL server performance.  But after a certain point, more memory does not increase PSQL server performance. The idea is that the server needs to have enough memory so that all your Elliott data can be cached in the memory. Look at all your data folders (companies) and determine the total size of all *.BTR files. Take that number times 2 on the low side, or times 4 on the high side. That’s the target we recommend for your server memory.  Again, your server may take on new additional roles in the future, so adding more memory may not be a bad idea.

Storage (Hard Disks)

As for the disk, SSD (Solid State Drives) are still expensive.  You don't have to get them. For some technical reasons, the performance improvement with SSD for a PSQL engine is marginal. In theory, the SSD should be much more reliable since there are no moving parts.  But if you can make sure to use either the RAID-5 or RAID-10 configuration, that will mitigate the risk of hard drive failure. Your disk space should be significantly larger (times 5, 10, or even more) than your current disk space for many reasons. 

Disk C: Partition Size

Make sure your C: partition is large enough (100GB at least, 200GB recommended). We have seen our users running out of disk volume on the C: drive all the time while they still have plenty of disk space left on D: volume. 

EMK