[SERVER-51363] Every 5 minutes mongod.exe wakes up an external drive Created: 05/Oct/20 Updated: 27/Oct/23 Resolved: 22/Dec/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.2.8 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Glen Miner | Assignee: | Mark Benvenuto |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Steps To Reproduce: | Run Process Monitor https://docs.microsoft.com/en-us/sysinternals/downloads/procmon Filter for Path that includes a drive Mongo isn't supposed to be using. You could also filter by process name mongod.exe. Wait briefly and it'll reveal the pattern of unwanted IO. |
| Sprint: | Security 2020-12-14, Security 2020-12-28 |
| Participants: |
| Description |
|
My local MongoDB server is installed to my S: drive where the configs and logs live. storage: systemLog: IE: it has no reason to access any other drive however it I found something periodically accessing my P: drive which is an external USB disk. I noticed this because the external drive normally likes to sleep since it's mostly idle but the unwanted access would occasionally force the it to wake up noisily. Using Process Monitor I traced this to my mongod.exe process which appears to be querying disk space every 5 minutes: 3:01:03.0012146 PM mongod.exe 21348 QuerySizeInformationVolume P:\ SUCCESS TotalAllocationUnits: 1,465,097,471, AvailableAllocationUnits: 233,436,301, SectorsPerAllocationUnit: 8, BytesPerSector: 512 2:56:01.0028637 PM mongod.exe 21348 QuerySizeInformationVolume P:\ SUCCESS TotalAllocationUnits: 1,465,097,471, AvailableAllocationUnits: 233,436,301, SectorsPerAllocationUnit: 8, BytesPerSector: 512 3:06:05.0016549 PM mongod.exe 21348 QuerySizeInformationVolume P:\ SUCCESS TotalAllocationUnits: 1,465,097,471, AvailableAllocationUnits: 233,436,301, SectorsPerAllocationUnit: 8, BytesPerSector: 512
My first though was to disable the free cloud monitoring but this did not help. I scoured the manual page for the config and couldn't see anything either. I took a quick look through the git repository to try to see if I could trace back to where this was coming from but the trail went cold.
I would be great if whatever this diagnostic was could be turned off so my system can save power and reduce wear by letting the drive spin down.
|
| Comments |
| Comment by Mark Benvenuto [ 22/Dec/20 ] | |||||||||||||||||||||||||||||||||
|
Closing this as works as designed since this is a behavior of Windows Performance Counters and not something MongoD can control. | |||||||||||||||||||||||||||||||||
| Comment by Mark Benvenuto [ 01/Dec/20 ] | |||||||||||||||||||||||||||||||||
|
I traced the issue with procmon and identified the issue as a implementation behavior of the Performance Counters that mongod is collecting. As mentioned above, this can be stopped by setting diagnosticDataCollectionEnabled but the diagnostic component for performance analysis will stop and free monitoring will lose much of its data (it reads the diagnostic data). The diagnostic data is collected at a 1 second interval but the 5 minute scan of the disk drives is probably a result of some Windows cache of disk free space expiring every 5 minutes. Here is the stack trace I capture from procmon on my development machine:
| |||||||||||||||||||||||||||||||||
| Comment by Glen Miner [ 06/Oct/20 ] | |||||||||||||||||||||||||||||||||
|
Fair point; either way ty for the workaround! | |||||||||||||||||||||||||||||||||
| Comment by Bruce Lucas (Inactive) [ 06/Oct/20 ] | |||||||||||||||||||||||||||||||||
|
I believe the reason we record data for all volumes is that it can be difficult to determine the volumes actually in use from dbpath; consider for example the complication of symbolic links on Linux. Also collecting data for volume used for paging is important. Disk striping introduces another complication. I'm not as familiar with Windows so not sure what considerations apply there. I'll route this to the appropriate team to consider whether it is feasible to limit data collection to only volumes that might potentially impact mongod. | |||||||||||||||||||||||||||||||||
| Comment by Glen Miner [ 05/Oct/20 ] | |||||||||||||||||||||||||||||||||
|
I hasten to add, though, why would it be accessing a drive it isn't supposed to be using? Might be best of both worlds if it stuck to the drive[s] it's been told to us. | |||||||||||||||||||||||||||||||||
| Comment by Glen Miner [ 05/Oct/20 ] | |||||||||||||||||||||||||||||||||
|
This worked perfectly – thank you! Don't worry, I wouldn't use for a retail deployment but for my workstation this is really helpful! | |||||||||||||||||||||||||||||||||
| Comment by Bruce Lucas (Inactive) [ 05/Oct/20 ] | |||||||||||||||||||||||||||||||||
|
glen.miner this is most likely our diagnostic data capture facility, which record a variety of mongod and system metrics. Among these we record disk information every ~5 minutes for all mounted volumes. Normally we wouldn't expect this to require a disk access as this information should be cached by the o/s, but it seems like possibly it does under some circumstances. Unfortunately there's no way to disable only that data collection. You can disable diagnostic data collection entirely using the diagnosticDataCollectionEnabled parameter, but we don't recommend it is very important for diagnosing any problems you might encounter. |