In the Aerospike documentation it is recommended that 50% of the provisioned RAM be used for primary and secondary indexes.
We have a Linux server that we purchased that is dedicated to just running Aerospike. In that sort of environment is it alright to use 80% of the provisioned RAM for Aerospike. We are assuming, in a headless dedicated server, that 20% on a 250GB RAM server is plenty to run Linux and other apps. Is this assumption correct?
It is a general conservative guideline which I believe is actually 60%, are you able to provide a link to the docs stating 50?
There also may be a bit of confusion here, are you discussing high-water-memory-pct or memory-size?
Typically we recommend having high-water-memory-pct configured to 60% to allow space during migrations allowing your system to evict data soonest to expire during such spikes. Of course this feature doesn’t work if all of your data’s TTL is set to never expire, in which case you may increase this value above stop-writes-pct.
For memory-size we typically recommend leaving 15-20% of the systems RAM unallocated to any namespace to allow for Aerospike process and Linux system overhead.
I’m a bit confused by this – I you were to allocate 80% of the total system RAM to a given namespace (leaving the rest for the Aerospike process / Linux overhead), but you were also to set high-water-memory-pct to 60%, wouldn’t the Aerospike process just proceed to evict records until the RAM reached 60%?
In other words, given 1TB of available RAM, and a high-water-memory-pct = 60%, is there any point allocating more than 600GB to any given namespace? Is the additional 200GB just there to handle spikes during data migration?
First, I think there is a bit of confusion on how these parameters work so I will try to clear that up. But I believe your sentiment is valid. I will first discuss how these parameters work with each other and then discuss why.
The memory-size for a particular namespace is the maximum amount of data that namespace can store in RAM. The high-water-memory-pct is a threshold that activates the namespace supervisor (nsup) thread’s eviction routine. The threshold is determined by the amount RAM you are using divided by the amount of memory configured for this namespace.
So to use your example, if you have 1TB of available RAM and configure you namespace to 600GB and high-water-memory-pct to 60 then eviction will start at 360GB. Though NSUP now evicting, depending on how NSUP is configured it may not evict fast enough so you may still reach the 90 stop-writes-pct or 540 GB. Stop-writes doesn’t actually mean that all writes stop, just the writes originating from a client. Stop-writes will continue to allow replica writes and migrations to pass through.
For the why I will refer you to this article explaining some of our choices in configuration defaults: