1 結論

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

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

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

■鎖和線程的數量是兩個矛盾體。

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

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

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

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

2 問題的提出

PROCESSOR進程運行在12G內存，12個CPU的服務器上，性能運行參數如下：

CPU total%

CPU sy%

CPU us%

處理消息的能力

優化前

334%

108.1%

224.1%

37000 package/s

圖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的處理能力成為了系統的瓶頸。

CPU total%

CPU sy%

CPU us%

處理消息的能力

優化後

775%

170.5%

576%

60000 package/s

圖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操作，都需要加解鎖。

CPU total%

CPU sy%

CPU us%

處理消息的能力

優化後

928%

214%

667.9%

97000 package/s

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