哪些因素會影響 MongoDB 的鎖定百分比

我們正在嘗試更好地優化我們使用 MongoDB 實例的方式。我們似乎經常獲得較高的鎖定百分比，並且正在尋求幫助將其最小化。這是一些 mongostat 輸出：

insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
    1    107    186      0       0     196       0  3.06g   7.3g   333m      0     11.2          0       0|0     2|0    66k   224k    85   15:55:22 
    2    102    285      0       0     296       0  3.06g   7.3g   333m      0     15.7          0       0|0     2|0    89k   216k    84   15:55:23 
    2     79    325      0       0     335       0  3.06g   7.3g   333m      0     20.2          0       0|0     3|0    96k   149k    85   15:55:24 
    2     92    193      0       0     203       0  3.06g   7.3g   333m      0     10.9          0       1|1     6|1    63k   149k    86   15:55:25 
    3    102    235      0       0     245       0  3.06g   7.3g   331m      0     14.5          0       0|0     2|0    75k   177k    84   15:55:26 
    3     79    267      0       0     275       0  3.06g   7.3g   331m      0     16.5          0       1|0     2|0    80k   133k    86   15:55:27 
    2     66    219      0       0     226       0  3.06g   7.3g   264m      0     14.3          0       0|0     2|0    66k   112k    88   15:55:28 
    2    100    201      0       0     211       0  3.06g   7.3g   334m      0     10.2          0       0|0     3|0    67k   142k    87   15:55:29 
    3    118    227      0       0     244       0  3.06g   7.3g   322m      0     13.8          0       3|1     6|1    78k   150k    87   15:55:30 
    2    112    189      0       0     198       0  3.06g   7.3g   334m      0     10.8          0       0|1     2|2    64k   213k    87   15:55:31 
    2     80    266      0       0     278       0  3.06g   7.3g   246m      0     15.8          0       0|1     3|1    82k   179k    86   15:55:32 
    1     82    307      0       0     314       0  3.06g   7.3g   334m      0     18.1          0       0|0     2|0    89k   158k    86   15:55:33 
    2     94    278      0       0     285       0  3.06g   7.3g   334m      0     17.1          0       0|0     0|0    83k   184k    86   15:55:34 
    3    101    246      0       0     256       0  3.06g   7.3g   332m      0     14.2          0       0|0     1|0    82k   179k    86   15:55:35 
    3     99    203      0       0     213       0  3.06g   7.3g   334m      0     12.5          0       0|0     2|0    67k   154k    88   15:55:36 
    2    115    174      0       0     189       0  3.06g   7.3g   335m      0       11          0       1|0     3|0    63k   172k    88   15:55:37 
    2     97    199      0       0     209       0  3.06g   7.3g   335m      0     10.3          0       0|0     2|0    65k   192k    87   15:55:38 
    2    103    366      0       0     373       0  3.06g   7.3g   334m      0     23.5          0       1|4     3|4   107k   256k    85   15:55:39 
    2    105    338      0       0     349       0  3.06g   7.3g   334m      0     22.9          0       0|0     1|0   101k   207k    83   15:55:40 

這比以前好多了，這要歸功於更好的索引。然而，我們顯然還有更多工作要做。關於這個數據集的事情：

• 硬體是一個 4-proc 盒子，平均負載通常在 1.3 和 1.9 之間
• 4GB 記憶體
• SAN 支持的儲存報告的延遲峰值為 35 毫秒，但大多數時間通常在 5 米到 20 毫秒之間。
• I/O 操作非常少
• ‘qr’ 和 ‘qw’ 數字確實表明我們沒有遇到大排隊。

當文件通過我們的處理平台時，我們使用 Mongo 來跟踪元數據。為我們擁有的每個實際文件創建一個 Mongo 文件（實際文件是舊的 Office 類型的文件）。每個處理階段查詢一些資訊，然後寫回資訊（有時相當多）。根據我們處理的數據，可能有很多階段。

這是一個更新繁重的工作負載，因此鎖定百分比是一個關鍵的擴展統計數據。我們還沒有分片，很大程度上是因為在我們需要分片之前，我們需要看看單個實例可以擴展多遠。

我們還需要調查哪些其他領域來降低鎖定百分比，或者我們剛剛碰壁需要分片？

這些是有趣的統計數據。我認為您可能會在更新時遇到文件大小增長的問題，需要將文件複製到磁碟上的新位置。如果確實如此，您也許可以通過手動填充文件來恢復部分鎖定百分比。它在第一次插入時增加了一些複雜性，但還不錯。請參閱官方文件中的此文件：http ://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-ManualPadding

只是一個想法…

引用自：https://dba.stackexchange.com/questions/16913