Если нет мониторинга (кастомного или через MMS), я бы начал с
mongostat.
xm:~$ mongostat -h d3.s1.fs.drive.bru:27021
connected to: d3.s1.fs.drive.bru:27021
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn set repl time
*0 15 *0 *0 0 4|0 0 2590g 5183g 2.32g 14 a:0.1% 0 0|0 2|0 2k 426k 552 driveFS-1 PRI 13:20:00
*0 17 *0 *0 0 4|0 0 2590g 5183g 2.33g 27 a:0.1% 0 0|0 0|0 4k 772k 552 driveFS-1 PRI 13:20:01
1 10 *0 *0 2 6|0 0 2590g 5183g 2.33g 15 a:0.1% 0 0|0 0|0 18k 355k 552 driveFS-1 PRI 13:20:02
*0 20 2 *0 0 4|0 0 2590g 5183g 2.33g 17 a:0.0% 0 0|0 0|0 3k 374k 552 driveFS-1 PRI 13:20:03
1 14 2 *0 2 4|0 0 2590g 5183g 2.33g 21 a:3.3% 0 0|0 0|0 113k 690k 552 driveFS-1 PRI 13:20:04
*0 11 *0 *0 0 3|0 0 2590g 5183g 2.32g 16 a:0.1% 0 0|0 0|0 2k 290k 552 driveFS-1 PRI 13:20:05
А потом бы посмотрел в логи MongoDB (если включён
slowms) на предмет длинных запросов вроде:
2015-01-24T13:18:26.824+0300 [conn121317] query a.fs.chunks query: { query: { files_id: 2318948981658353664, n: 0 }, $readPreference: { mode: "nearest", tags: [ { group: "d2" }, {} ] } } planSummary: IXSCAN { files_id: 1, n: 1 } ntoreturn:2 ntoskip:0 nscanned:1 nscannedObjects:1 keyUpdates:0 numYields:1 locks(micros) r:126010 nreturned:1 reslen:52407 599ms
Ну и дальше попробовал бы скоррелировать какие нибудь page fault и прочее по времени с медленным запросом. Можно подключить dstat/iostat, если есть подозрение на диск. 
