[SERVER-35994] Reduce CPU load in secondary_reads_unique_indexes.js test Created: 06/Jul/18  Updated: 29/Oct/23  Resolved: 06/Jul/18

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: 4.0.1, 4.1.1

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

Issue Links:
Backports
Related
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0
Participants:
Linked BF Score: 4

 Description   

The secondary_reads_unique_indexes.js test starts up 16 reader threads, each using its own mongo shell process, and does multiple reads repeatedly. This can incur very high CPU usage on a machine. The high load appears to be generated primarily by the mongo shell processes, not the mongod nodes.

For example, running this test on a 12 core Linux workstation nearly maxed out all cores when the reader threads were running. We should consider adding some short sleeps to these read loops in an attempt to make this test less intensive. This will reduce the likelihood of it locking up a machine when running with other tests concurrently.



 Comments   
Comment by Githook User [ 06/Jul/18 ]

Author:

{'username': 'will62794', 'name': 'William Schultz', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-35994 Reduce CPU load in secondary_reads_unique_indexes.js test

(cherry picked from commit 567676b888c6372c46d6e2507df2bb91546b743b)
Branch: v4.0
https://github.com/mongodb/mongo/commit/de81cb94239caa6529d0aece7791c860cbb8a371

Comment by Githook User [ 06/Jul/18 ]

Author:

{'username': 'will62794', 'name': 'William Schultz', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-35994 Reduce CPU load in secondary_reads_unique_indexes.js test
Branch: master
https://github.com/mongodb/mongo/commit/567676b888c6372c46d6e2507df2bb91546b743b

Comment by Louis Williams [ 06/Jul/18 ]

I think adding short sleeps would be fine if to help reduce test failures. The test was designed to catch one potential regression of secondary reads, but there are other tests that would definitely catch errors even if this test didn't.

Comment by William Schultz (Inactive) [ 06/Jul/18 ]

louis.williams Would you see any problem in doing this? i.e. adding short (possible randomized) sleeps at the end of each for-loop iteration here. It seems that what matters for this test would be the ordering of a read relative to a batch application. The overall frequency of the secondary reads seems less important (i.e. how long they wait between issuing new reads).

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