Currently we are on 3.9.3 version of aerospike with 8 node cluster running in DSIK+DRAM mode. Our reads and writes are almost equal
Our cache hit ratio is around 30%. How can this be tuned to cache more ? And is there a particular number that we should be hitting at-least ?
Is the namespace configured to store on device? If so, read up on the post-write-queue, which can be raised to 2048 blocks per-device. If your reads closely follow your writes this will give you a better cache-hit ratio.
Hi Rbotzer
I was looking for option to cache repeat reads , that are not being updated. Is there any way to configure that too (i.e cache objects that being read but not being updated) ?
Also what is the reason for upper limit on the “post-write-queue” ?
I don’t believe there is a way to cache recently read records which were not updated. If there is, I will be interested in knowing too. rbotzer?
Any blocks that are still present in post-write-queue are not eligible for defragmentation on the SSD. So making p-w-q very large will adversely affect defragmentation. p-w-q was intended to facilitate XDR - so that most recently updated records which should be replicated to the remote cluster by XDR are available in cache.
The Primary Index keeps track using some kind of clever scheme as to where the record is - write-block/write-cache/SSD/post-write-queue using the same id.
Hi Arpit,
Aerospike doesn’t cache reads. I assume you’re talking about the case where your namespace stores its data on an SSD. In that case you should use our ACT tool to benchmark your drives, and make sure that you have enough of them to support the reads you need without a cache. For example, the 9x rating for the Samsung PM863 means that one SSD can do 18Ktps reads and 9Ktps writes at 95% of operations sub 1ms. Part of your capacity planning is ensuring the cluster has enough read/write IOPS to achieve what you need.
Thanks Rbotzer for confirming that.