[Windows] 1 second timer when idling

[Prasanna V. Loganathar]

Hi, 

It seems that when MongoDB is idling on simply on a system, it uses a 1 second timer that constantly queries the journal directory, and also a the performance counter query keys. Haven't looked at the source code, yet, but wonder why it keeps doing that. 

While of course, this is in no way priority since it doesn't matter on servers, I constantly use MongoDB as a personal data store on my systems, and it uses a low, but constant CPU time, which bothers me while on portable devices (Of course, that's not MongoDB's ideal host). I keep having to turn the service on and off, when I need it. The other thing that's evident is the "metrics.interim.temp" that's consolidated into the diagnostic data every 10 seconds - which is rather okay. But querying the performance counters and the journal directory every second for no reason bother me a bit. 

While it's obviously not the ideal host, let's take a look at how Microsoft handles the scenarios for instance - MSSQL Server (Express, LocalDB, or full instance) doesn't use any CPU (or occasional, if any) at all when idling, which makes it perfect for use on personal devices. Hoping to understand a little more if this is indeed a necessity, and/or is there any way make MongoDB idle without using system resources. 

Would be great if a Windows dev could shine some light on this. 

[Bruce Lucas]

The performance counter queries are likely the default once-per-second diagnostic data collection. You can disable this using the diagnosticDataCollectionEnabled parameter. I don't believe querying the journal directory is related to diagnostic data collection though, and the timestamps on the screenshot you provided support that it is unrelated, as they are offset from the perf counter activity by about 0.6 seconds. What impact on CPU utilization do you see if you disable diagnostic data collection?

Thanks,
Bruce

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev+unsubscribe@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-dev/457b6df4-0ded-415e-b497-fd336ea2a4eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sue.l...@10gen.com]

Hi Prasanna,

The journal directory query is because WiredTiger uses an internal thread to pre-allocate journal files so that a user thread does not need to incur the performance hit of fsync'ing out the journal header when changing log files.  That thread runs once per second and will query the journal directory to see how many journal files were created and how many pre-allocated files exist for use and decide what work to do.  You can turn off journal pre-allocation by starting your mongod with:

 --wiredTigerEngineConfigString=',log=(prealloc=false)'

Sue LoVerso

[Prasanna V. Loganathar]

Great! That did most of it. While the CPU usage of an idling mongod process stays around just 0.3% on my core i7 laptop, on a Lenovo IdeaPad, it's sits constantly a little over 1%. And this translated to battery life of reasonable significance (roughly gave me an extra hour on the IdeaPad when the service was stopped). I'm guessing that was because even though the usage was extremely low, it was waking the CPU up constantly from it's sleep states.  

Now disabling this dropped the usage under 0.1% on the my i7, and to about 0.4-0.5% in my IdeaPad. 

Thanks. I appreciate the reply even though this is likely an unsupported corner case issue that'll never affect any mainstream systems.

On Friday, June 16, 2017 at 5:36:17 PM UTC+5:30, Bruce Lucas wrote:

The performance counter queries are likely the default once-per-second diagnostic data collection. You can disable this using the diagnosticDataCollectionEnabled parameter. I don't believe querying the journal directory is related to diagnostic data collection though, and the timestamps on the screenshot you provided support that it is unrelated, as they are offset from the perf counter activity by about 0.6 seconds. What impact on CPU utilization do you see if you disable diagnostic data collection?

Thanks,
Bruce

On Fri, Jun 16, 2017 at 1:09 AM, Prasanna V. Loganathar <p...@prasannavl.com> wrote:

Hi, 

It seems that when MongoDB is idling on simply on a system, it uses a 1 second timer that constantly queries the journal directory, and also a the performance counter query keys. Haven't looked at the source code, yet, but wonder why it keeps doing that. 

While of course, this is in no way priority since it doesn't matter on servers, I constantly use MongoDB as a personal data store on my systems, and it uses a low, but constant CPU time, which bothers me while on portable devices (Of course, that's not MongoDB's ideal host). I keep having to turn the service on and off, when I need it. The other thing that's evident is the "metrics.interim.temp" that's consolidated into the diagnostic data every 10 seconds - which is rather okay. But querying the performance counters and the journal directory every second for no reason bother me a bit. 

While it's obviously not the ideal host, let's take a look at how Microsoft handles the scenarios for instance - MSSQL Server (Express, LocalDB, or full instance) doesn't use any CPU (or occasional, if any) at all when idling, which makes it perfect for use on personal devices. Hoping to understand a little more if this is indeed a necessity, and/or is there any way make MongoDB idle without using system resources. 

Would be great if a Windows dev could shine some light on this. 

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.

[Prasanna V. Loganathar]

Hi Sue, 

Thank you for the info. However, adding that config made no difference. The config change was acknowledged as evident from the log info while starting mongod, but it still queried the file system exactly the same way it did before. Perhaps, there was something wrong with the config that it wasn't exactly received by the engine?

Though, disabling the performance counters helped significantly.

[Prasanna V. Loganathar]

Just a quick update on this though. Since it's just for personal uses, I settled down to disabling the journal. Disabling the journal and the perf counters, brought the CPU usage under 0.01. 

There's still seems to a bunch of timers firing off when compared to DBs like SQLServer that goes completely idle. But I guess that shouldn't be a problem. 

Also, increasing the `commitIntervalMs` to the max 500, dropped the usage significantly as well. Though, unfortunately, there's a soft limit on the max being 500ms. Would be great if the soft value limit was increased by say, 2 to 5 seconds for use cases on non-critical systems such as these. 

This should help the battery without turning off the journal entirely.