FoundationDB

Constrained RAM in an application development environment


(John Weir) #1

Will FoundationDB run with less than 4 GB of ram? Not in production, but in development of our application.

Our developers have a single VM running the entire stack, on machines (MacBooks) with 16 GB of RAM(max). I’m probably not going to be able allocate another 4GB of RAM on these machines.

Lets say we evaluate FoundationDB and find it will be an amazing addition to our stack. But we can only allocate another 2 GB.

Can a FoundationDB server operate with that little memory,? Our development environments are not very intense, so performance is not much of an issue.

Thanks!


(David Scherer) #2

If you put hardly any data in it, it probably won’t use a ton of memory. Otherwise you will probably run out as it allocates memory for page caching, MVCC, etc - it doesn’t adapt to the actual amount of RAM available.

I think you could configure fdbserver via knobs to run reliably in ~2GB of RAM, obviously with somewhat reduced performance. Something like

knob_page_cache_4k=300e6
knob_target_bytes_per_storage_server=300e6

might be a good start. (Obligatory warning: changing knobs in production systems is dangerous! This advice is for development use only.)


(Rinat Abdullin) #3

I’ve seen FoundationDB survive quite well on a QA server which was overpopulated with running instances and continuously running out of free RAM.


(Christophe Chevalier) #4

Maybe this can be useful to someone.

Here is the actual memory consumption of each process running on a test cluster running 5 process per host (16 GB RAM, ubuntu linux, ssd engine), and without any changes to the settings or knobs! The data are comming straight out of the status json metrics.

The statistics are right after big import job, and after the cluster has settled down to idle, so all the storage nodes have had the opportunity to fill their cache with hot data.

You mileage may vary, values could be different under a different workload, don’t sue me!

Processes grouped by roles:

Storage processes tend to average 3.7 - 4.0 GB, Log processes are around 1 GB, Resolver is ~0.7 GB and the other stateless processes (master, proxy, controller) use 200 - 300 MB RAM

Here is another view, showing the usage per host: looks like only 11.5 - 12 GB of RAM are enough to fit 1 log + 3 storage + 1 stateless.