关于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结果我们可以看出：

1. 未发现cpu有瓶颈

2. 内存大量剩余

3. 系统负载很低

4. 没有磁盘IO

5. 网卡软中断未出现瓶颈（带宽和fps也未到瓶颈）

 

• 测试结果，性能体现

此图我们可以看出：

1. 逐步加压，约200个并发访问时，每秒事务数到顶

2. 随并发数的增加，响应时间随之变长，但每秒响应数量并未同比增加

3. 最终Nginx每秒成功响应2万次请求

 

    大概3年前的服务器（Lenovo WQ R510 G6），1颗4核CPU/4G内存/146G-SAS。相同的测试环境下，都能每秒响应近4万次请求。

    =========================================================================================================

Nginx、Tengine、OpenResty 性能对比测试

    前阵子写过一次“关于Linux系统性能瓶颈定位分析（一），Nginx状态页测试（待续）”，当时留下了一个未定位到的瓶颈。

    如今，在解开它的同时，顺便也对当下流行的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款容器的优点、产品的初衷，进而选择最合适的容器。

 

转载:http://hi.baidu.com/higkoo/item/f3258f02a5afa925a1312d26