I had the same issue. After some searching I guessed it was os that sacrificed mongod for memory. If kernel killed your mongod you can find the logs in kernel logs

Mostly kernel logs will be in /var/log/kern.log, The logs might be rotated.

So better to do a grep

grep mongod /var/log/kern.log*

if the logs are archived find -name \*kern.log.*.gz -print0 | xargs -0 zgrep "mongod"

./kern.log.1:Nov 12 12:55:04 ip-xxx-xxx-xxx-xxx kernel: [8413229.118361] mongod invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
./kern.log.1:Nov 12 12:55:04 ip-xxx-xxx-xxx-xxx kernel: [8413229.118365] mongod cpuset=/ mems_allowed=0
./kern.log.1:Nov 12 12:55:04 ip-xxx-xxx-xxx-xxx kernel: [8413229.118371] CPU: 0 PID: 1830 Comm: mongod Not tainted 4.4.0-1062-aws #71-Ubuntu
./kern.log.1:Nov 12 12:55:04 ip-xxx-xxx-xxx-xxx kernel: [8413229.118531] [ 1301]   112  1301   300787   181207     485       4        0             0 mongod
./kern.log.1:Nov 12 12:55:04 ip-xxx-xxx-xxx-xxx kernel: [8413229.118680] Out of memory: Kill process 1301 (mongod) score 355 or sacrifice child
./kern.log.1:Nov 12 12:55:04 ip-xxx-xxx-xxx-xxx kernel: [8413229.130161] Killed process 1301 (mongod) total-vm:1203148kB, anon-rss:724828kB, file-rss:0kB

The short answer is "yes". What values to choose depends very much on your write patterns. This gives background on exactly how MongoDB manages its mappings - it's not anything unexpected.

One wrinkle is that in a web-facing database application, you may care about latency more than throughput. vm.dirty_background_ratio gives the threshold for starting to write dirty pages, and vm.dirty_ratio tells when to stop accepting new writes (ie, block) until all writes have been flushed.

If you are hammering a relatively small working set, you can be OK with setting both of those values fairly high, and relying on Mongo's (or the OS's) periodic time-based flush-to-disk to commit the writes.

If you're conducting a high volume of inserts and also some modifications, which sounds like it might be your situation, it's a balancing act that depends on inserts vs. rewrites - starting to flush too early will cause writes that will be re-written soon, "wasting" io. Starting to flush too late will result in pauses as you flush huge writes.

If you're doing mostly inserts, then you may very well want a large dirty_ratio (to avoid blocking) and a relatively small dirty_background_ratio (small enough to always be writing as you're inserting to reduce latency, and just large enough to linearize some of the writes).

The correct solution is to replay some dummy data with various options for those sysctl parameters, and optimize it by brute force, bearing in mind your average latency / total throughput objectives.