Mack Altman III · Mar 16, 2017

Recommendations for server configuration

I have been asked to assist in the planning of the a new server for our database, which we will be changing operating systems from OpenVMS to Linux (RedHat distribution). However, its difficult to find material regarding what would be recommended, which is likely due to the database being proprietary.

In looking at the information provided below and hoping to decrease processing time, would anyone be able to recommend type of configuration we should have for the new Linux server? Please feel free to ask any clarifying questions.

The current server is running with the following hardware configuration.

Total Physical Memory64 GB DDR2
Memory Allocated for Routine Cache3,584 MB
Memory Allocated for 2KB Database Cache512 MB
Memory Allocated for 8KB Database Cache43,496 MB
Processors (CPU)4 x Dual-Core Intel Itanium McKinley, 1.594GHz, L1: 32 KB, L2: 256 KB
Concurrent Users158

If it helps, the following is from the System Dashboard

System Up Time13h 21m
Global Refs6,295,590,389
Global Sets248,697,076
Routine Refs1,160,200,605
Logical Requests5,585,768,243
Disk Reads10,588,557
Disk Writes8,158,173
Cache Efficiency335.86
Journal Entries147,074,538
Highest License Use78%
4 0 2 871
Log in or sign up to continue


Hi Mack,

I can help here.  The VMS/Itanium system you are migrating from is quite old, and has quite slow processors.  For something like this you can figure at least 4 of the McKinley cores (maybe more) to 1 single current model Intel Xeon E5 v4 series core.  I would look to using a server such as a single-socket system with an Intel Xeon E5-2667v4 processor and 64GB of RAM (more RAM doesn't hurt either).  The E5-2667v4 processor is a 8-core processor @ 3.2Ghz each which is far more CPU than you would need, however it's actually quite difficult to get a smaller server theses.  

For a workload like this, a virtual machine in vSphere, Hyper-V, or KVM would probably be more appropriate.

Also, I have a few comments on your current Caché configuration:

  • The amount of routine buffers configured you have configured (3584MB) exceeds the maximum allowed (max is only 1023MB).  You can confirm in your cconsole.log that startup actually reduced to the max value.  You will want to update your routine cache size to 1023MB so that it takes effect on the next Caché restart.
  • I see you have 512MB of 2KB database buffers allocated and 43496MB of 8KB buffers.  I would suggest removing the allocation of the 2KB buffers completely and just allow any 2KB databases you have to use the 8KB buffers.  That way you aren't artificially capping your database cache.
  • Speaking of 2KB databases, If you still actually have 2KB databases on your system, it is highly recommended to convert those to 8KB databases for data safety and performance reasons.  

Kind regards,

Mark B-

You want to read Appendix B (Calculating System Parameters for UNIX® and Linux) of the Caché Installation Guide, available here:

Some simple advice that I can add is for routine buffers, this depends upon your application. In general you want to allocate enough routine buffers to contain all the routines that you use on a day to day basis, and not worry about the routines that are only used once a year.

For 2 kio buffers, Do you still have databases with 2 kio blocks? If so, why? If you don't have 2 kio databases, or you can convert them to 8 kio databases, do so, and eliminae the 2 kio database buffers.

For 8 kio buffers, this is usually the big user of memory, and where you get the best boost in performance by adding more memory. By default we take 1/8 of  memory for each Caché configuration, subtract what we need for routine buffers and shared memory heap, and use the rest for 8 kio buffers. If this will be the only instance of Caché on a machine, you can compute this yourself using 1/2 of memory.

You can also decide if you have enough memory for 8 kio buffers, by just monitoring the performance of your database. Just look at Cache efficiency. (Global References/(Disk Reads+Disk Writes)). The high the better. Keep adding memory until the improvement is not significant, or you run into some other problem.