New Elliott PSQL Server Processor and RAM Suggestions

Q - We are going to upgrade to a new Windows Server 2012 R2 for PSQL 11 64-bits 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 speaking, we think all 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.  Generally speaking, the PSQL 12 has more friendly licensing than PSQL 11 to use in the virtualizing environment.  PSQL 12 only checks the server NETBIOS name for licensing verification.  On the other hand, PSQL 11 checks many hardware configurations, 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.

Virtualizing Database Server Pros & Cons

There is a debate out there 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 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

Pervasive PSQL

  1. Btrieve Error Codes 001 - 199
  2. Btrieve Error Codes 3000 - 3099
  3. Btrieve Error Codes 3100 - 3199
  4. PSQL Version Required by Each Elliott Version
  5. Do I Need to Change PSQL Server Engine Default Parameters After Installing It?
  6. New Elliott PSQL Server Processor and RAM Suggestions
  7. Can I Dynamically Adjust Elliott / PSQL 11 Server Memory?
  8. Received "Your Computer Does Not Have PSQL 10 or 11 Client " Even though PSQL Client Is Just Installed
  9. Btrieve Error 161 on Password File When Starting Up Elliott
  10. Problems with Using Pervasive Rebuild Utility on APOPNFIL and AROPNFIL Tables
  11. Security Issue with Installing PSQL Client Remotely on User's Workstation
  12. PSQL and Distributed File System (DFS)
  13. How Do I Turn on PSQL Relational Engine Security?
  14. An Example of Debugging NOTE_ORD_VIEW PSQL Expression Evaluation Error
  15. Btrieve Error 025 on COP Open Order by Salesman Report
  16. What Is the *.^01 File for My PSQL Btrieve Table?
  17. Suggested Files to be Monitored by Audit Master
  18. Pervasive Backup Agent Is Not Compatible with Creating Work Files
  19. Hardware Recommendations for Your PSQL Database Server
  20. How to Optimize SQL SELECT Statement When Retrieving Data from Invoice History
  21. New User-Defined Functions in Elliott DDF
  22. How to Improve Query Performance When Retrieving Data from Notes & Invoice History?
  23. How to Retrieve Tracking Number for an Order from Notes
  24. Actian PSQL Not Started Automatically After Server Reboot
  25. Create a New Database in the PCC for Relational Engine Access
  26. Slow PSQL Relational Engine Performance

Feedback and Knowledge Base