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
Gerrit Reviews
For Gerrit Dashboard: MB-11919 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
40617,7 | MB-11919 Log sequence number difference in indexing | master | couchdb | Status: MERGED | +2 | +1 |
40728,2 | MB-11919: Try out throttling | master | manifest | Status: MERGED | +2 | +1 |
40729,1 | MB-11919: Limit updater starts | master | couchdb | Status: ABANDONED | +1 | 0 |
40790,2 | Revert "MB-11919 Log sequence number difference in indexing" | master | couchdb | Status: MERGED | +2 | +1 |