影響MongoDB資料庫效能的幾個重要因素

1.鎖
MongoDB用一個鎖確保資料的一致性。但如果某種操作長時間執行，其他請求和操作不得不等待這個鎖，導致系統效能降低。
為了驗證是否由於鎖降低了效能，我們可以檢查serverStatus輸出的globalLock部分資料。如果引數lobalLock.currentQueue.total
的值一直比較大，說明系統中有許多請求在等待鎖，同時表明併發問題影響了系統的效能。
  如果globalLock.totalTime的值與uptime的值接近，說明資料庫在鎖狀態佔用了系統大量時間。如果globalLock.ratio的值
也高，說明資料庫處理了大量的長查詢，引起長查詢的因素主要有：

•   1).索引使用不恰當甚至低效
•   2).資料庫的設計沒有最佳化
•   3).查詢語句本身結構效能低下
•   4).系統架構有問題

2.記憶體
MongoDB透過記憶體對映資料檔案，如果資料集很大，MongoDB將佔用所有可用的系統記憶體。正是由於記憶體對映機制將記憶體的管理交給操作
系統來完成，簡化了MongoDB的記憶體管理，提高了資料庫系統的效能，但是由於不能確定資料集的大小，需要多少記憶體也是個未知之數。
透過serverStatus()輸出的關於記憶體使用的狀態方面的資料，我們能夠深入的瞭解記憶體使用情況。

•       1).檢查引數mem.resident的值，如果超過了系統記憶體量並且還有大量的資料檔案在磁碟上，表明系統記憶體過小；
•       2).檢查引數mem.mapped的值，如果這個值大於系統記憶體量,那麼針對資料庫的一些讀操作將會引起作業系統的缺頁錯誤，記憶體的換入換出將會降低系統的效能。

3.缺頁錯誤
當MongoDB請求的資料不在實體記憶體中，必須從虛擬記憶體中讀取時，就會引起缺頁錯誤。為了檢查缺頁錯誤，我們可以檢查serverStatus()
輸出項中extra_info.page_faults的值。單次的缺頁錯誤對系統來說並不是問題，它表明MongoDB要讀取的資料很多都不在記憶體中，需要從
磁碟中讀取。增加系統記憶體量可以降低缺頁錯誤的次數，但是單臺機器的實體記憶體畢竟是有限的，而我們的資料檔案通常都比記憶體要大，為了
解決這個問題，我們可以部署分片叢集。


4.連線數
有時候客戶端的連線數超過了MongoDB資料庫伺服器處理請求的能力，這也會降低系統的效能，我們可以透過serverStatus()輸出的關於連線數
方面的引數進行進一步分析。引數globalLock,activeClients表示當前正在進行讀寫操作客戶端連線數，current表示當前客戶端到資料庫例項
的連線數，available表示可用連線數。對於讀操作大的應用程式，我們可以增加複製整合員數，將讀操作分發到secondary節點上，對於寫操作
大的應用程式，我們可以透過部署分片叢集來分發寫操作。