Details
-
Bug
-
Resolution: Unresolved
-
Critical
-
3.0
-
Security Level: Public
-
Platform = Physical
OS = CentOS 6.5
CPU = Intel Xeon E5-2630 (24 vCPU)
Memory = 64 GB
Disk = 2 x SSD
-
Triaged
-
Centos 64-bit
-
-
Yes
Description
Scenario is described in MB-11918.
Rebalance-out: 37GB peak in 2.5.x and 98GB peak in 3.0
http://cbmonitor.sc.couchbase.com/reports/html/?snapshot=leto_ssd_251-1083_1f4_rebalance&snapshot=leto_ssd_300-1121_19f_rebalance
Rebalance-in: 25GB peak in 2.5.x and 111GB peak in 3.0
http://cbmonitor.sc.couchbase.com/reports/html/?snapshot=leto_ssd_251-1083_afc_rebalance&snapshot=leto_ssd_300-1121_99c_rebalance
Rebalance-swap: 25GB peak in 2.5.x and 140GB peak in 3.0
http://cbmonitor.sc.couchbase.com/reports/html/?snapshot=leto_ssd_251-1083_515_rebalance&snapshot=leto_ssd_300-1121_98e_rebalance
Attachments
Issue Links
- relates to
-
MB-11918 Latency of stale=update_after queries reaches 30-60 seconds during rebalance
- Closed
-
MB-11589 Sliding endseqno during initial index build or upr reading from disk snapshot results in longer stale=false query latency and index startup time
- Closed
-
MB-11920 DCP based rebalance with views doesn't leverage faster indexing
- Closed