Details
-
Bug
-
Resolution: Done
-
Critical - P2
-
2.8.0-rc0
-
Fully Compatible
-
ALL
Description
Seeing severe performance issue in capped collections.
- drop-off of couple orders of magnitude in insertion rate apparently around the point where the collection size limit is reached (about 450k docs in this example).
- insertion rate appears to continue to decline
- compression does not matter
- lsm is worse than record store
inserts/s after n docs:
n mmapv1 wt wt wt
|
rec str rec str lsm
|
snappy no comp snappy
|
|
|
10000 48076 39062 39215 38314
|
20000 52083 40816 39370 37735
|
30000 50505 39062 39682 38461
|
40000 52356 40322 38910 37878
|
50000 52356 36630 37174 35971
|
...
|
400000 37313 37313 37174 32258
|
410000 38022 40485 38610 33112
|
420000 37037 42016 40650 35335
|
430000 35971 39370 39370 31347
|
440000 37037 38314 39525 34013
|
450000 38461 38314 38167 33670
|
460000 37593 19920 20449 3943
|
470000 38022 5396 6020 592
|
480000 38610 2217 1959 275
|
490000 38167 1140 1150 229
|
500000 37313 832 829 169
|
function create(size) {
|
db.createCollection("c", {capped: true, size: size})
|
}
|
|
function insert(count) {
|
var every = 10000
|
var bulk = db.c.initializeUnorderedBulkOp();
|
var t = new Date()
|
for (var i=0; i<=count; i++) {
|
if (i>0 && i%every==0) {
|
bulk.execute();
|
bulk = db.c.initializeUnorderedBulkOp();
|
tt = new Date()
|
print(i, Math.floor(every / (tt-t) * 1000))
|
t = tt
|
}
|
bulk.insert({})
|
}
|
}
|
|
|
create(10000000)
|
insert(500000)
|
Attachments
Issue Links
- related to
-
SERVER-16775 Steady decline in performance in capped collections under wiredTiger
-
- Closed
-
-
SERVER-16247 Oplog declines in performance over time under WiredTiger
-
- Closed
-
-
SERVER-16296 Producer-consumer use case shows declining performance over time under WIredTiger
-
- Closed
-