Universe Database 11.x and 12.x and NUMA in big systems

David,

UniVerse and UniData are not NUMA aware, and I am not aware of any official position on this at the moment.

I was made aware of some interesting facts on an internal presentation on NUMA by another part of Rocket though and I am happy to share the summary information with you. Again I stress this is my take on the information in the presented as we do not have an official statement or position on this at the moment.

NUMA architecture pairs memory modules close to a individual cores, on a multicore machine.  This yields improved performance under most conditions.  But when an application finds its data on the "wrong" memory module (i.e., on a memory module attached to a different core than where the application code is executing), negative performance is suddenly experienced. The way some DBMSs (including UniVerse and UniData) use memory causes them to be particularly vulnerable to this.  The effects can often be counter-intuitive – add more cores or memory, get worse performance.

As we do not have internal support for Numa in UniVerse or UniData I suspect we would follow the advice of other database vendors without NUMA support that if you are going to use it at the OS Level then do not building machines larger than Numa. This also give the warning that you are relying the OS for the Numa functionality it is very unlikely to be super efficent with the database.

I have been testing this NUMA thing for  a while, and following it , getting info 

We have a client with 512GB RAM that fully utilizes both NUMA nodes, having little to none RAM wo/use (that is fs cache mostly) 

I tend to think that numa=off on the kernel SHOULD at least, prevent some of the risks involved with NUMA

Id like some form of confirmtaion or depper analysis from Rocket side on this matter ,as well 

You have been very helpful Jonathan 

The situation with the client is less than good and any bit of improvement or at least less risk, would help