The NUMA settings really only affects transient / non-shared objects. These are objects where the thread that allocated them is most likely to be the one to access them and in a short enough time span that the thread is not scheduled in a different NUMA zone core. Non-transient and shared objects may have to cross NUMA because there is no way to know what NUMA zones a scheduled thread will need to access.
So if anything was going to show the affects it would be on something that generates lots of transient objects really fast. For that I would look to the geode-benchmark get server side tests. They do local gets on a server without a client and can produce lots of transient objects, though not as many as it used to. Run with and without NUMA settings and see what it yields. I recall doing this a while ago for one benchmark and non-NUMA performance wasn’t great compared to NUMA but I was specifically looking at issue regarding network buffer saturation in the kernel on 72 core machines. -Jake On Feb 28, 2022, at 12:39 PM, Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>> wrote: Hi, We understand the recommendation is to fit the Geode JVM within one NUMA node for optimal performance, so in case we're running in a system with multiple NUMA nodes and our JVM can fit in the memory available in a single NUMA, it is recommended to pin it there ([1]). However, does anyone have any numbers to compare the performance of the same-sized Geode JVM when run on non-NUMA hardware vs run on NUMA hardware where JVM is spread on more NUMA nodes? Have you played with newer JDKs and GCs that have better NUMA awareness to quantify if the drop in performance could be reduced to acceptable levels? Thanks! Alberto [1]: https://geode.apache.org/docs/guide/114/managing/monitor_tune/performance_on_vsphere.html
