MongoDB執行個體的IOPS使⽤率是⼀個⾮常重要的監控指標。如果MongoDB執行個體的IOPS使⽤率達到或接近100%，會導致業務響應緩慢，甚⾄業務不可⽤。本文介紹查看MongoDB執行個體IOPS使用率的方法，以及導致IOPS使用率高的原因和最佳化策略。
背景資訊
⼀般雲資料庫廠商為了避免宿主機出現I/O爭搶，會使⽤CGroup（ Control Groups ）等技術進⾏執行個體間的I/O隔離和IOPS（Input/Output Operations Per Second）限制，即不同規格的執行個體配置對應不同的IOPS使⽤上限。
注意事項
MongoDB單節點架構執行個體、4.2版本複本集雲端硬碟版執行個體以及4.2版本分區叢集雲端硬碟版執行個體暫不支援查看IOPS使用量和IOPS使用率。
目前上述架構的執行個體在控制台監控資訊頁面的監控指標IOPS使用量和IOPS使用率一直顯示為0，無法代表真正的IOPS監控資料。
查看IOPS使用率
您可以通過監控圖查看IOPS使用率
登入MongoDB管理主控台，在基本資料頁面的規格資訊地區，確認該執行個體的最⼤IOPS上限。不同執行個體規格對應的IOPS使⽤上限請參見：執行個體規格概述。
登入MongoDB管理主控台，在監控資訊頁面，根據監控指標IOPS使用量和IOPS使用率來確認該執行個體的最⼤IOPS上限。⼤部分情況下阿⾥ApsaraDB for MongoDB的data⽬錄和log⽬錄使⽤同⼀塊盤，所以IOPS使⽤量=data_iops+log_iops。
I/O問題的常見原因
常見導致MongoDB磁碟I/O問題的可能原因如下：
記憶體不夠。I/O問題與記憶體的CacheSize⼤⼩息息相關。CacheSize越⼤，表示能夠緩衝的熱資料越⼤，即系統需要的磁碟I/O量越低，則出現I/O瓶頸的機率越低；反之，CacheSize越⼩，表示能夠緩衝的熱資料越少，系統刷髒更加頻繁，則出現I/O瓶頸的機率越⼤。
與磁碟I/O相關的參數和配置問題。例如MongoDB Journal和運⾏⽇志頻繁重新整理，寫入安全機制（WriteConcern）設定不合理，分⽚叢集的MoveChunk錯誤等。
關於更多Journal內容可參考：Journaling。
關於更多WriteConcern內容可參考：Write Concern。
I/O問題的最佳化策略
如果是阿里雲MongoDB，建議您根據業務需求選擇合適的執行個體規格，並關注索引的最佳化和部分應用系統的寫入最佳化。
配置合適的執行個體規格
由於在配置前很難預估熱資料與CacheSize的⽐例設定為多少最合適，通常情況下，在保證MongoDB執行個體滿⾜業務要求的情況下，確保每日的最高CPU使⽤率和IOPS使⽤率控制在50%以內即可。
索引最佳化
查詢全表掃描或使用了不恰當的索引，例如匯出全表資料期間，會消耗大量的I/O。建立過多的索引會使資料規模很大，導致WiredTiger Cache緩衝的熱資料減少，業務資料寫操作過程中需要多⼀次I/O操作以更新索引，從而影響I/O效能。為了避免以上情況，建議您建立合適的索引，詳情請參見Indexes。
業務架構和營運最佳化
在業務架構層⾯，要避免磁碟I/O成為瓶頸，需要最佳化以下幾個方面：
控制並發寫入/讀取線程數
MongoDB是多線程應用，過⾼的並發寫入速度和複雜查詢並發數，容易引起IOPS瓶頸，甚⾄導致Secondary節點持續延遲。如果I/O瓶頸是由於業務寫⼊量導致，建議您將MongoDB執行個體升級至MongoDB分⽚叢集模式，通過資料的⽔平拆分來線性擴容MongoDB的寫⼊效能。
儘可能避免峰值寫⼊
部分業務由於定期寫入或資料批量持久化，容易造成IOPS峰值。針對這種情況，在當前的執行個體配置不⾜以⽀撐該峰值寫⼊的情況下，建議您將業務側改造為平滑寫入，例如給每⼀個批量寫⼊操作添加⼀個隨機時間⽚。
避免業務⾼峰期間做營運操作
部分對效能影響較⼤的營運操作，從本質上講也會造成IOPS峰值。如果必須執行此類操作，建議您在業務低峰期執行。容易引起I/O⾼峰的常見操作有批量寫⼊、更新、刪除資料，添加索引，對集合執⾏Compact操作，大量匯出資料等。