1 結論

通過本次效能優化，總結了幾條經驗。

■頻繁的加解鎖會提高系統空間的CPU佔用率

鎖在核心的實現是通過佇列來實現的，加鎖操作把執行緒放入等待佇列，解鎖操作是才能夠等待佇列獲取一個執行緒來獲取鎖。所以頻繁的加解鎖CPU的開銷是非常大的。

■鎖和執行緒的數量是兩個矛盾體。

對於固定數量的鎖，執行緒的數量並非越多越好。我們需要在兩者之間找平衡點。如何來找？通過測試找出最優值。

■多CPU環境下的CPU瓶頸問題的定位

在多CPU環境中，如果某個CPU佔用率接近100%，可以得出這樣的結論，某個執行緒的粒度太大造成了CPU使用率不均衡，可以通過減小執行緒粒度來解決這個問題。

如果每個CPU的佔用率遠小於100%，不能得出CPU不是瓶頸的結論，本文就是一個典型的案例。當處理某個任務的執行緒數量不夠，且執行緒有等待的操作(比如：加鎖動作，sleep動作)，等待的操作可以使得執行緒在各個CPU之間均衡的排程，從而使得我們看到各個CPU的佔用率分佈均衡並且比較低。這種效能問題只能通過結合應用程式碼來進行定位，在本文中通過觀察佇列的大小來的得出CPU是瓶頸的結論。這種問題的解決方案是增加執行緒數量。

2 問題的提出

PROCESSOR程序執行在12G記憶體，12個CPU的伺服器上，效能執行引數如下：

圖1 優化前的效能引數

優化目標：

1增加CPU的利用率

2降低系統空間CPU率佔用率的佔比

3 問題分析

如圖2所示，PROCESSOR專門處理DISPATCHER分發過來的訊息， 處理完成之後傳送給REDUCER進行合併入庫處理。如圖3所示，Processor網元採用的流水線架構。每個SubProcessor由一個執行緒實現，每個subprocessor對應一個單獨的佇列。subprocessor從自己的佇列獲取待處理的訊息，處理完成之後，若訊息還需進一步處理，則會把這個訊息放入下個subprocessor的訊息佇列中。subprocessor在處理訊息的過程中，會把相關的統計資料放入記憶體表。【注：現階段，MSA僅僅提供了使用者/BS/PCF的統計資訊】。

圖2  組網結構

圖3 processor的內部架構

通過測試發現，但DISPATCHER傳送的訊息到達閥值後，subprocessor-4對應的佇列中的訊息首先達到其閥值10000，當佇列中的訊息達到閥值後，會阻塞subprocessor-3向queue-4放入訊息，所以隨後導致queue-3佇列滿，以此類推，queue-1佇列滿，所以PROCESSOR丟棄UDP訊息。所以subprocessor-4是系統的瓶頸，我們需要提高subprocessor-4處理訊息的能力。

優化措施1：增加subprocessor-4中的執行緒數量

我們把subprocessor-4對應的執行緒提供到4個，效能測試結果如下。可以發現，提升幅度非常大。還有沒有進一步優化的空間？cache的處理能力為500000次/S，每個訊息攜帶4個service，處理每個service需要操作cache兩次，包括一次查詢和一次insert。所以500000次/s= 60000 * 8。所以現在cache的處理能力成為了系統的瓶頸。

圖4 第一步優化後的效能

圖5 第一次優化後TOP命令顯示CPU佔用率詳細資訊

優化措施2：減少操作cache的次數

我們把subprocessor-4中處理訊息的一個service需要兩次cache操作壓縮到一次。即cache提供insertIfAbsent介面。進行這個優化後，下一個瓶頸在哪裡？我們通過跟蹤各個subprocessor的佇列，發現subprocessor-1的佇列首先達到閥值。理所當然，subprocessor-1的處理能力成了系統瓶頸。

優化措施3：增加subprocessor-1中的執行緒數量

subprocessor-1的任務是對訊息佇列中的訊息進行解碼。通過測試發現，subprocessor-1中的執行緒數量的最優值為6。如果執行緒數量過高，發現處理訊息的能力反而下降。這是由於多個執行緒都需要從相同的佇列中獲取訊息，訊息佇列成了熱點，執行緒必須通過互斥鎖來解決併發。總所周知，頻繁的進行加解鎖時非常耗費CPU的，所以執行緒為6是加解鎖開銷和訊息解碼之間的最佳平衡值。

檢視圖7，你會發現一個非常意外的結果。系統空間CPU佔比(sys/us)下降了。這是減少cache操作次數的結果，每次進行cache操作，都需要加解鎖。

圖6 第3步優化後的結果，本的是的輸入訊息只包含了一個service 

圖7 第3步優化後的TOP命令的顯示