[SERVER-16868] Significant slowdown in capped collection performance when cap reached Created: 15/Jan/15  Updated: 24/Jan/15  Resolved: 22/Jan/15

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.8.0-rc5
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Darren Wood Assignee: Mathias Stearn
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-16667 Isolated writes with extreme latencie... Closed
duplicates SERVER-16919 Oplog can grow much larger than confi... Closed
is duplicated by SERVER-16919 Oplog can grow much larger than confi... Closed
Related
is related to SERVER-16921 WT oplog bottleneck on secondary Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Same workload and setup as SERVER-16697. Test runs well and quickly fills collection on a C3-4xl EC2 machine, the number of client threads (100) may need to be reduced on less capable hardware.

mongod --storageEngine=wiredTiger --wiredTigerCacheSizeGB 1

$ git clone https://github.com/wiredtiger/mongo-tests.git
$ cd mongo-tests/SERVER-16697/
$ mongo --quiet 16697.js 

Participants:

 Description   

When a smaller cache is used (1GB) and a high insert workload is applied to a capped collection, high insert latencies are seen once the collection reaches the capped value.



 Comments   
Comment by Githook User [ 16/Jan/15 ]

Author:

{u'username': u'michaelcahill', u'name': u'Michael Cahill', u'email': u'michael.cahill@wiredtiger.com'}

Message: SERVER-16868 Limit the truncates done by each thread to manage WT capped collections.
Branch: master
https://github.com/mongodb/mongo/commit/6bab2f390cfbae08bf0801668f54a5fd35db2bfc

Generated at Thu Feb 08 03:42:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.