We want to know if we can likely fit in a SearchStax “NDN1” (1GB of RAM and 8GB storage; $20 or $40/ month) or instead need an “NDN2” (2GB of RAM and 16GB storage, $40 or $80/month.
To do this we will compare to our current self-managed Solr, which runs on a AWS EC2 t3a.small, which is 2GB RAM.
We think the storage space is more than sufficient for our small collection on either NDN1 or NDN2. (As far as we can tell, we only need 70MB(?) of storage space). We don’t think this is an issue.
CPU is roughly equivalent, and our solr’s CPU needs are minimal. Also CPU the same probably between NDN1 and NDN2. We don’t think this is an issue.
It’s really about RAM, and if the NDN1 can handle the same usage patterns as our current setup, or all the ones we realistically may encounter.
Current EC2 Solr
production, in use
This is from the production solr dashboard (with an uptime of only 4 days though).
The machine has 2GB of RAM. The JVM has been given a Xmx max size of 2GB – actually a bit excessive, since it’ll trying to use all machine RAM and swapping heavily if it gets there.
However, it’s only actually using 287MB of RAM. The JVM has reserved 512MB of RAM from the OS (possibly because we gave it that as an -Xms minimum size), but isn’t currently using it.
This production machine has only been up for 4 days? Is it possible that over time it will use even more RAM?
staging, after reboot
Compare to staging solr, immediately after reboot.
Only using 155MB after reboot (with index in place).
The SearchStax NDN1
Immediately after a reboot (with a full index), this is what our SearchStax NDN1 reports in Solr dashboard.
We can see that while it is advertised as a “1GB” machine, the JVM only has a bit less than half of that. This isn’t tunable by us, it’s SearchStax’s choice. This is to leave space in RAM for other OS and maintainance tasks, and we can see that the system Physical Memory is pretty healthy too.
Only using 109MB on boot, a bit less than our staging solr for some reason, but in the ballpark.