etcd Memory usage

[Shailendra Hullur]

Hi,

We are evaluating etcd for a non-server type of deployment. We will need clustering and notification support. I have been able to run etcd - 3.2.17 on our setup. I see that the memory consumption of the etcd process as shown by top is around 12g, ~1.5GB. I have tried configuring the snapshot-count, but I did not see any change in the memory usage. Please let me know if there is any other option available to reduce the memory consumption. Also, please let me know how to check what is the amount of disk space currently being used by the etcd application.

Thanks,

Shailendra.

[Sam Batschelet]

Just to clarify what is the RSS memory usage, 12GB is Virtual 1.5GB is RSS? Also when you say you reduced snapshot count. You changed it to and from what values exactly? What is the size of you db and are you using v2 or v3 store?

Best,

Sam

[Joe Betz]

Memory usage is also a factor of dataset size and write rate. Tuning how often compaction is run (either by direct requests from the client or via auto compaction settings) might help.

--
You received this message because you are subscribed to the Google Groups "etcd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to etcd-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shailendra Hullur]

The observation was that it uses 1.5GB Virtual and about 128 MB RSS. This is without any data store. This usage was measured when the etcd process started running without any data populated. One of the suggesions in this link https://coreos.com/etcd/docs/latest/tuning.html to optimize the memory usage was to reduce the snapshot-count. I tried the option --snapshot-count with value as 5000 and 1000. I am using etcd version 3.2.17. So, I think it is v3 store. If there is any way to confirm this, let me know.

Cheers,

Shailendra.

[Subba G]

etcd uses in-memory secondary index (using google btree). actual data is stored in bbolt db with revision as key and user provided key, value pairs as data.

since entire index is in memory, your etcd's memory consumption is directly co-related to number of keys.

If db engines line RocksDB and Badger for persistence (these are LSM based, not btree), and save user key as db key, then you can control memory used by DB with number of memtables configured.

However, read performance would be little less, as per Badger bench read perf difference was not significant when SSD is used for storage.

--