Version v3.3 of This version of etcd is no longer supported. For the latest version, please see the latest stable version. For the latest stable documentation, see v3.5.
Benchmarking etcd v2.2.0-rc-memory
Physical machine
GCE n1-standard-2 machine type
- 1x dedicated local SSD mounted under /var/lib/etcd
- 1x dedicated slow disk for the OS
- 7.5 GB memory
- 2x CPUs
etcd
etcd Version: 2.2.0-rc.0+git
Git SHA: 103cb5c
Go Version: go1.5
Go OS/Arch: linux/amd64
Testing
Start 3-member etcd cluster, each of which uses 2 cores.
The length of key name is always 64 bytes, which is a reasonable length of average key bytes.
Memory Maximal Usage
- etcd may use maximal memory if one follower is dead and the leader keeps sending snapshots.
max RSS
is the maximal memory usage recorded in 3 runs.
value bytes | key number | data size(MB) | max RSS(MB) | max RSS/data rate on leader |
---|---|---|---|---|
128 | 50000 | 6 | 433 | 72x |
128 | 100000 | 12 | 659 | 54x |
128 | 200000 | 24 | 1466 | 61x |
1024 | 50000 | 48 | 1253 | 26x |
1024 | 100000 | 96 | 2344 | 24x |
1024 | 200000 | 192 | 4361 | 22x |
Data Size Threshold
- When etcd reaches data size threshold, it may trigger leader election easily and drop part of proposals.
- For most cases, the etcd cluster should work smoothly if it doesn’t hit the threshold. If it doesn’t work well due to insufficient resources, decrease its data size.
value bytes | key number limitation | suggested data size threshold(MB) | consumed RSS(MB) |
---|---|---|---|
128 | 400K | 48 | 2400 |
1024 | 300K | 292 | 6500 |
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.