Details
-
Bug
-
Resolution: Won't Fix
-
Blocker
-
4.0.0
-
Security Level: Public
-
Untriaged
-
Centos 64-bit
-
Unknown
Description
a degradation in stale=false scan performance with run duration of the test is seen.
run with default WAL size:
with default WAL size, scan timeouts start occuring 90 minutes into the test
logs:
https://s3.amazonaws.com/cb-customers/performance/15785/collectinfo-2015-07-26T074724-ns_1%40172.23.100.16.zip
run with 10x WAL size:
with 10x WAL size, scan timeouts start occuring 180 minutes into the test. 10x WAL size provides better write throughput during compaction without increasing catch-up time of compaction process.
logs:
https://s3.amazonaws.com/cb-customers/performance/15785/collectinfo-2015-07-27T035451-ns_1%40172.23.100.16.zip
example timeout error from client:
2015-07-26T20:03:10.193Z-07:00 [Error] [GsiScanClient:"172.23.100.16:9101"] connection "172.23.100.56:41752" response transport failed `read tcp 172.23.100.16:9101: i/o timeout`
Attachments
Issue Links
- relates to
-
MB-15935 2i indexing drain rate can't keep up with 10k updates/sec during stale=false testing
- Resolved