我正在公司测试 MongoDB（社区版）从 2.6 升级到 3.6（安装了 3.6.5 版）。它在 AWS EC2 上的 Debian Jessie 上运行。我们遇到了一些奇怪的行为（或者可能是正常的）：当我们在 Mongo 3.6 上使用 WiredTiger 存储引擎时 - 在 mongo 服务启动和开始监听连接之间大约有 2 分钟的延迟（取决于连接的磁盘类型）。使用 Mmapv1 存储引擎，它会立即开始监听连接。数据库有超过 16k 个集合，其中的文档数量差异很大（从几个到几万个），启用压缩后的数据库大小约为 4.5 GB，未压缩时约为 11GB
遇到此问题的服务器是 AWS EC2 实例 c4.xlarge（4 核，8GB RAM），我尝试过连接不同类型的卷 - 磁性（此处启动时间甚至为 4-5 分钟）、gp2（300/3000 IOPS）、io1（IOPS 在 1000 级别）。在 gp2 或 io1 卷上拥有数据库文件之间启动时间没有显著差异（卷是从头创建的，而不是从快照创建的，因此 AWS 磁盘预热不是这种情况）。大部分启动时间都花在 WT 检查点上，来自 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
无论文件系统类型是 EXT3 还是 XFS，文件系统是否使用 noatime 选项挂载，透明大页面是否启用或禁用，预读是否启用 - 它总是在 60 秒到 120 秒之间（有时甚至更长）。我还尝试过使用 WiredTiger 索引选项的独立目录，但速度并没有加快。我们禁用了数据库日志记录，测试期间没有设置副本集（但在生产中将设置副本）。
知道还有什么我可以尝试的吗？或者可能是正常行为，从启动观察中我注意到在 WT 检查点期间它访问每个集合文件（大约 ~16k 个文件），所以我猜这就是启动最延迟的地方。
WiredTiger 的启动延迟是否正常，或者我是否错过了什么？