Disable MongoDB journaling? Are there any benefits in disabling mongodb journaling besides performance gain?
I know journaling provides write durability and crash resiliency. But I can tune syncdelay parameter to make data files flush more frequently, but mongodb docs recommends against this. What effect would it have on my mongodb setup and why should I not set syncdelay on production setups?

Thanks,
Abhi
Are there any benefits in disabling mongodb journaling besides performance gain?


The only other marginal benefit is if you are using a 32-bit build (which is also not recommended for production use). Since 32-bit builds are limited to ~2Gb of addressable data for memory mapped files, the journal is off by default to allow for more data (with journal enabled, the 32-bit data limit is halved to ~1Gb). In all other cases, the journal is enabled by default. For 64-bit systems, the addressable virtual memory is not a limiting factor for data size.

Any performance gain from disabling the journal is a tradeoff for data &amp; operational risk. I would strongly advise against disabling the journal unless your data is ephemeral (i.e. you don't care about losing it or can easily recreate it from another source of truth).

If you are concerned about possible contention or overhead from disk I/O of journaling, you could always move the journal to a separate volume. NOTE: moving the journal to a separate volume may also change your backup strategy, particularly if you were relying on filesystem snapshots to take a comparatively quick backup without having to fSyncLock() and quiesce your database.


  I know journaling provides write durability and crash resiliency. But I can tune syncdelay parameter to make data files flush more frequently, but mongodb docs recommends against this. 


Writes to the journal are fast append-only operations. As you've noted, these provide durability and crash resiliency. If MongoDB stops unexpectedly, it can recover from the journal and data will be in a consistent state.

Without the journal, your data is in an unknown state after an unexpected shutdown and you need to validate it by running repair or (in the case of a replica set node) resync from a known-good copy of the data.


  What effect would it have on my mongodb setup and why should I not set syncdelay on production setups?


The syncdelay setting controls the frequency where the in-memory view is synced with the on-disk view of data (aka the "background flush interval").

By default, the journalCommitInterval is 100ms and the syncdelay (background flush) happens every 60 seconds.

If you adjust the syncdelay too low, you can end up creating a lot of additional I/O (and reduced performance) because writes to dirty pages can no longer be effectively batched together and the same page will be re-written multiple times. If you adjust the syncdelay higher, you can create I/O spikes (and reduced performance) with a large volume of changes being committed in a single batch.

The syncdelay and journalCommitInterval parameters are available as tuneable settings because in some cases it may make sense to adjust these (for example, to try to temporarily help an under-provisioned I/O system by reducing write spikes). In a healthy production system, it would be best to leave these settings as-is.

For more information, How MongoDB’s Journaling Works is a helpful read.