[SERVER-35208] Use large instance type for certain concurrency suites Created: 24/May/18  Updated: 29/Oct/23  Resolved: 01/Jun/18

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 4.0.0-rc0
Fix Version/s: 4.0.0-rc2, 4.1.1

Type: Task Priority: Major - P3
Reporter: Robert Guo (Inactive) Assignee: Robert Guo (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-35197 Change CleanEveryN to CleanupConcurre... Closed
Related
is related to SERVER-35416 Use large instance type for certain c... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: TIG 2018-06-04, TIG 2018-06-18
Participants:

 Description   

We should use "large" instance types for the concurrency_replication_causal_consistency suites. They start 5 nodes that each have a 1GB oplog and 1GB WT cache, this overwhelms our "small" instances which have 7.5GB memory. We workaround the problem at the moment by running CleanEveryN to remove the data files and restart the cluster, so the oplog doesn't get too big.

Similarly, concurrency sharded and replication suites on the linux repeated builder should also run on the large instance type.



 Comments   
Comment by Githook User [ 04/Jun/18 ]

Author:

{'username': 'guoyr', 'name': 'Robert Guo', 'email': 'robert.guo@10gen.com'}

Message: SERVER-35208 use large instance for some concurrency_replication_causal suites

(cherry picked from commit d0b8d07d0a30c570a76ab902560d896810b5825e)
Branch: v4.0
https://github.com/mongodb/mongo/commit/4de58fdd7430dbeb95df9233e5ec83f8622ad1d6

Comment by Githook User [ 01/Jun/18 ]

Author:

{'username': 'guoyr', 'name': 'Robert Guo', 'email': 'robert.guo@10gen.com'}

Message: SERVER-35208 use large instance for some concurrency_replication_causal suites
Branch: master
https://github.com/mongodb/mongo/commit/d0b8d07d0a30c570a76ab902560d896810b5825e

Generated at Thu Feb 08 04:39:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.