Does etcd support larger storage instead of 8G

[Doyle-net]

Does the latest version of ETCD already support larger storage instead of 8G
"bbolt" has improved storage performance etcd-io/bbolt#141

[king-jam]

I can't find a support comment but it does support the new free list type with –backend-bbolt-freelist-type config flag.

https://etcd.io/docs/v3.4.0/op-guide/configuration/#--backend-bbolt-freelist-type

[tangcong]

Can you describe your business scenario in detail？ @Doyle-net
Larger storage may bring the following problems：

1. more memory
2. slow restart
3. bigger snapshot
4. slow queries may result in OOM

[king-jam]

To provide a use case, I will be storing upwards of 400-500k objects that are anywhere from 1KB to 100KB in size. That could lead to a 50GB database based on estimates. I can put anything for hardware behind it (SSD/NVMe/TBs of RAM/etc).

Do you foresee that being possible with the hash map based freelist implementation?

[tangcong]

I have not tried such a large size. It is a little risky. In addition to the freelist, there may be memory overhead, startup time, and recovery time（the leader has to send the snapshot to node when a node data lagging behind), and good storage structure design to avoid all slow queries. It would be great to share your test results and problems found if you will try to test in large size cases. @king-jam

[jingyih]

Note that the underlying bbolt mmap its file in memory. For better performance, usually it is a good idea to ensure the physical memory available to etcd is larger than its data size.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.