24GB is the inflection point because of configured hashmap load factor for the 950k chain size (~2.5). This results in table heads totaling 13.6GB. As these must stay memory resident, that leaves 10.4GB for all other processes and table bodies. As this gets squeezed paging increases and time goes parabolic as heads start getting pushed out of RAM. This is a hard point in the store architecture.
LF can be changed via config (only at store create), resulting in smaller heads. Halving the buckets doubles the load factor and therefore the average search cost doubles. So the heads can remain in RAM at 6.8GB while the node pays a more proportional cost in body paging. This of course also has a limit, but as we have shown on the RPi5, it works well at 16GB.