OPERATIONAL DEFECT DATABASE
...
...
My local MongoDB server is installed to my S: drive where the configs and logs live. storage: dbPath: S:\MongoDB\data {{}} systemLog: destination: file logAppend: true path: S:\MongoDB\log\mongod.log 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.
mark.benvenuto commented on Tue, 22 Dec 2020 23:08:36 +0000: Closing this as works as designed since this is a behavior of Windows Performance Counters and not something MongoD can control. mark.benvenuto commented on Tue, 1 Dec 2020 22:22:51 +0000: 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: C:\Windows\System32\drivers\FLTMGR.SYS!FltDecodeParameters + 0x195a C:\Windows\System32\drivers\FLTMGR.SYS!FltDecodeParameters + 0x1508 C:\Windows\System32\drivers\FLTMGR.SYS!FltDecodeParameters + 0x616 C:\Windows\System32\drivers\FLTMGR.SYS!FltDecodeParameters + 0x3be C:\Windows\system32\ntoskrnl.exe!NtQueryInformationFile + 0xc20 C:\Windows\system32\ntoskrnl.exe!NtQueryVolumeInformationFile + 0x536 C:\Windows\system32\ntoskrnl.exe!setjmpex + 0x6983 C:\Windows\System32\ntdll.dll!ZwQueryVolumeInformationFile + 0x14 C:\Windows\System32\perfdisk.dll!CloseDiskObject + 0x2da4 C:\Windows\System32\perfdisk.dll!CloseDiskObject + 0x26da C:\Windows\System32\perfdisk.dll!CloseDiskObject + 0xd41 C:\Windows\System32\perfdisk.dll!CollectDiskObjectData + 0x275 C:\Windows\System32\advapi32.dll!LsaGetUserName + 0x620 C:\Windows\System32\advapi32.dll!PerfRegQueryValue + 0x325 C:\Windows\System32\KernelBase.dll!MapPredefinedHandleInternal + 0x8e9 C:\Windows\System32\KernelBase.dll!RegQueryValueExW + 0xed C:\Windows\System32\pdh.dll!PdhCollectQueryData + 0xf7c C:\Windows\System32\pdh.dll!PdhCollectQueryData + 0x23d C:\Windows\System32\pdh.dll!PdhCollectQueryData + 0x59 Z:\mongo\build\install\bin\mongod.exe!mongo::PerfCounterCollector::collect + 0x5c, Z:\mongo\src\mongo\util\perfctr_collect.cpp(487) Z:\mongo\build\install\bin\mongod.exe!mongo::`anonymous namespace`::WindowsSystemMetricsCollector::collect + 0x5c, Z:\mongo\src\mongo\db\ftdc\ftdc_system_stats_windows.cpp(105) Z:\mongo\build\install\bin\mongod.exe!mongo::FTDCCollectorCollection::collect + 0x55a, Z:\mongo\src\mongo\db\ftdc\collector.cpp(92) Z:\mongo\build\install\bin\mongod.exe!mongo::FTDCController::doLoop + 0x3a1, Z:\mongo\src\mongo\db\ftdc\controller.cpp(249) Z:\mongo\build\install\bin\mongod.exe!::operator() + 0x2b, Z:\mongo\src\mongo\db\ftdc\controller.cpp(145) Z:\mongo\build\install\bin\mongod.exe!std::invoke > + 0x28, C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\type_traits(1596) Z:\mongo\build\install\bin\mongod.exe!std::_Apply_impl,std::tuple > + 0x3a, C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\tuple(948) Z:\mongo\build\install\bin\mongod.exe!std::apply,std::tuple > + 0x79, C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\tuple(953) Z:\mongo\build\install\bin\mongod.exe!::operator() + 0x8c, Z:\mongo\src\mongo\stdx\thread.h(186) Z:\mongo\build\install\bin\mongod.exe!std::invoke > + 0x28, C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\type_traits(1596) Z:\mongo\build\install\bin\mongod.exe!std::thread::_Invoke >,0> + 0x56, C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\include\thread(44) C:\Windows\System32\ucrtbased.dll!register_onexit_function + 0xec C:\Windows\System32\kernel32.dll!BaseThreadInitThunk + 0x14 C:\Windows\System32\ntdll.dll!RtlUserThreadStart + 0x21 glen.miner commented on Tue, 6 Oct 2020 15:15:32 +0000: Fair point; either way ty for the workaround! bruce.lucas@10gen.com commented on Tue, 6 Oct 2020 13:22:50 +0000: 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. glen.miner commented on Mon, 5 Oct 2020 23:03:36 +0000: 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. glen.miner commented on Mon, 5 Oct 2020 23:02:52 +0000: This worked perfectly – thank you! Don't worry, I wouldn't use for a retail deployment but for my workstation this is really helpful! bruce.lucas@10gen.com commented on Mon, 5 Oct 2020 19:58:56 +0000: 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.
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.
Click on a version to see all relevant bugs
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
