I'm testing MongoDB (community edition) upgrade from 2.6 to 3.6 (version 3.6.5 is installed) in my company. It's running on Debian Jessie on AWS EC2.
We are experiencing some strange behavior (or maybe it's normal): when we are using WiredTiger storage engine on Mongo 3.6 - between mongo service start and time when it starts to listen connections there's like 2 minutes delay (depends on disk type attached).
With Mmapv1 storage engine it's starting to listen for connections immediately.
Database has more than 16k collections with very different numbers of documents in them (from few to tens of thousands), database size with compression enabled is around 4,5 GB, without compression ~11GB
Server on which it's experienced is AWS EC2 instance c4.xlarge (4 cores, 8GB of RAM), I've tried different volumes type attached - magnetic (here startup time was even 4-5 minutes), gp2 (300/3000 IOPS), io1 (with IOPS on 1000 level).
There was no significant difference in startup time between having database files on gp2 or io1 volume (volumes created from scratch not from snapshots so AWS disk warm up is not a case here).
Most of the startup time is spent on WT checkpoint, from mongod.log:2018-07-18T13:25:11.119+0200 D STORAGE [WTCheckpointThread] starting WTCheckpointThread thread
2018-07-18T13:26:11.418+0200 D STORAGE [initandlisten] Slow WT transaction. Lifetime of SnapshotId 1 was 60259ms
No matter if filesystem type is EXT3 or XFS, filesystem is mounted with or without noatime option, transparent huge pages disabled or enabled , readahead disabled or enabled - it's always between 60s - 120s (or sometimes more).
I've also tried with separated directory for WiredTiger indexes option but it didn't speed up.
We have database journaling disabled, no replica set in place during tests (but on production replication it will be involved).
Any idea if there's anything else I could try? or maybe it's normal behavior, from startup observation I noticed that during WT checkpoint it access each collection file (around ~16k files) so I guess that's where startup is mostly delayed.