[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: |
|
||||||||
| 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: (cherry picked from commit 567676b888c6372c46d6e2507df2bb91546b743b) |
| Comment by Githook User [ 06/Jul/18 ] |
|
Author: {'username': 'will62794', 'name': 'William Schultz', 'email': 'william.schultz@mongodb.com'}Message: |
| 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). |