關於Linux系統性能瓶頸定位分析(一),Nginx狀態頁測試
-
使用場景:
Nginx對外提供介面服務,本文以Nginx的狀態頁(stub_status)為例。
-
需要解決的問題:
定位效能瓶頸,並調優
-
測試方法
使用約40臺測試機向一臺Nginx伺服器併發訪問
-
伺服器配置
DELL PowerEdge R510
CentOS 5.8 / Linux 2.6.18-308.8.2.el5 x86_64
Two Quad-Core Xeon E5606 @ 2.13GHz with L2 cache = 1MiB & L3 cache = 8MiB
System Memory 64GiB with width = 64 bits & clock = 1333MHz (0.8ns)
Broadcom BCM5716 driver=bnx2 driverversion=2.2.1j firmware=6.2.12 bc 5.2.3 speed=1Gbit/s
-
ulimit 配置
Firewall is stopped.
getenforce = Disabled
-
sysctl 配置
-
Nginx配置
nginx.conf定製配置項,其它全預設
worker_processes 8;
worker_connections 81920;
location = /status { # 測試此介面
stub_status on;
access_log off;
}
-
測試結果,伺服器壓力
從top結果我們可以看出:
-
未發現cpu有瓶頸
-
記憶體大量剩餘
-
系統負載很低
-
沒有磁碟IO
-
網絡卡軟中斷未出現瓶頸(頻寬和fps也未到瓶頸)
-
測試結果,效能體現
此圖我們可以看出:
-
逐步加壓,約200個併發訪問時,每秒事務數到頂
-
隨併發數的增加,響應時間隨之變長,但每秒響應數量並未同比增加
-
最終Nginx每秒成功響應2萬次請求
大概3年前的伺服器(Lenovo WQ R510 G6),1顆4核CPU/4G記憶體/146G-SAS。相同的測試環境下,都能每秒響應近4萬次請求。
=========================================================================================================
Nginx、Tengine、OpenResty 效能對比測試
如今,在解開它的同時,順便也對當下流行的3個WEB伺服器進行了一些效能對比。
首先,上述瓶頸是由於單一的埠監聽接收請求時存在瓶頸。解決辦法:
1、分別監聽多個IP
2、監聽多個埠
3、修改作業系統核心
本輪測試包括,分別使用Nginx、Tengine和OpenResty測試如下場景(被測伺服器的 CPU核數=24):
A、1個服務程序(Master),多個(等同CPU核數)子程序(worker_processes)監聽1個IP地址和1個埠
B、1個服務程序(Master),多個(等同CPU核數)子程序(worker_processes)監聽所有IP地址(0.0.0.0)和1個埠
C、1個服務程序(Master),1個子程序(worker_processes)監聽1個IP地址和1個埠
D、1個服務程序(Master),多個(等同CPU核數)子程序(worker_processes)分別監聽各個IP地址的同1個埠
E、多個服務程序(Master),1個子程序(worker_processes)分別監聽所有IP地址(0.0.0.0)上的多個埠(等同CPU核數)
使用斷連線(每次請求新建連線)測試內建的靜態頁面,結果如下:
* 場景E的測試過程,使用200個併發無法測出系統的最大能力,故統一提升到300個併發連線。
* 本次測試的最大收穫就是:如何讓系統發揮最大效能(場景E)
OK,在第1輪測試中:
1、Nginx和OpenResty的效能基本相當,OpenResty略差
2、Tengine除了在場景C效能出眾之外,其它場景均墊底
這個結果大出意料和叔度溝通後,可能同測試場景和Tengine自動繫結CPU親緣性的設定有關。比如:場景C是單程序單IP和單埠,結果Tengine的效能即明顯高於其它。而多程序多IP多埠時Tengine即是最差的,場景E測試Tengine時所有軟中斷的使用都集中在最後一顆CPU核上,而其它則分佈到4個CPU上(被測試伺服器網絡卡有4佇列)。
SO,我們關閉Tengine的自動繫結CPU親緣性功能(worker_cpu_affinity off;),進行第2輪測試:
此時Tengine的效能基本同Nginx持平。
另外,還進行了一些額外的場景。比如對場景E進行手動繫結CPU,效能還能略有提升達到10萬QPS。某些場景下Tengine的效能略佔優勢,但總體而言三者的效能無本質區別。
之所以場景1裡Tengine結果詫異,實際是由於容器配置不同導致。
本次測試是在“小資料包”、“短連線”的場景下,對3個容器的基本處理能力進行了測量。其後我們應該更關注這3款容器的優點、產品的初衷,進而選擇最合適的容器。