ab压力测试和 nginx 配置优化及用户打开的最大进程数

本文链接：https://blog.youkuaiyun.com/wudinaniya/article/details/86064797

一 ab压力测试和 nginx 配置优化

压力测试工具 ApacheBench 简称ab，是Apache 中自带的基准性能测试的工具。通过ab命令可以创建并发线程模拟多用户访问或调用某一URL地址。
为了测试服务器的并发能力，可以利用apache 中提供的 ApacheBench 工具，该工具可以在一台计算机中向一个 url 地址发送大量的并发请求，然后检测服务器响应这些请求花费了多少时间，有多少请求处理失败。利用ApacheBench（简称ab）工具可以模拟一台服务器被大量客户端并发连接的情况，以测试服务器的并发能力。

ApacheBench的安装

执行sudo yum -y install httpd-tools 安装apache httpd的工具包，这个工具包中包含压力测试工具ApacheBench。

[root@jtfwq ~]# rpm -qa httpd-tools
[root@jtfwq ~]# yum -y install httpd-tools

nginx 配置优化

1 连接数优化

当nginx作为负载均衡服务器时，能够接收的并发连接应该越多越好。我们可以用 ApacheBench 工具来测试服务器的并发能力。

为了准备测试环境，使用VMware部署两台虚拟机，如图所示。

在上图中，服务器是待测试机，安装了nginx并使用默认配置；客户端使用 ab 工具进行并发访问测试。

linux系统默认限制了一个进程最多打开的文件数量。通过 ulimit -a|grep open 可以查看当前系统的限制。

使用ab工具：

注意：192.168.81.250后面的 / 不能省略。
上述操作中，ab命令的选项-n表示发送的请求总数，-c表示并发数，后面的网址是请求的服务器url地址。

为了能更好地理解ApacheBench的测试报告，下面通过一个具体事例进行演示：

[root@slave1 ~]# ab -n1000 -c1000 http://192.168.81.250/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.81.250 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests                   #完成1000个请求


Server Software:        nginx/1.14.0     #服务器软件
Server Hostname:        192.168.81.250   #服务器主机名
Server Port:            80               #服务器端口号

Document Path:          /                #文档路径
Document Length:        169 bytes        #文档大小

Concurrency Level:      1000             #并发数
Time taken for tests:   1.042 seconds    #完成测试所用的时间
Complete requests:      1000             #完成的请求数
Failed requests:        0                #失败的请求数
Write errors:           0
Non-2xx responses:      1000
Total transferred:      319000 bytes                   #总传输数据量大小
HTML transferred:       169000 bytes                   #HTML数据量大小
Requests per second:    959.72 [#/sec] (mean)          #平均每秒请求数
Time per request:       1041.971 [ms] (mean)           #平均每次并发请求所用时间
Time per request:       1.042 [ms] (mean, across all concurrent requests)  #平均每个请求所用时间
Transfer rate:          298.98 [Kbytes/sec] received   #平均每秒传输的数据量

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        4  181 189.6    133     566
Processing:    30  127  63.6     97     582
Waiting:       16  118  61.6     91     297
Total:         54  308 186.3    310     680

Percentage of the requests served within a certain time (ms)    #各请求的时间分布如下
  50%    310                                                    #50%的请求花费了310毫秒
  66%    319
  75%    324
  80%    395
  90%    635                                                    #90%的请求花费了635毫秒
  95%    637
  98%    638
  99%    639                                                    #99%的请求花费了639毫秒
 100%    680 (longest request)                                  #所有请求花费了680毫秒

从上述测试报告可以看出，服务器能够承受1000个并发连接，总共耗时约1.04秒。接下来将请求总数和并发设置为1030，会发现ab无法进行测试，出现如下提示。

socket: Too many open files (24)

如图：

该提示表示打开的文件超出了系统限制。按照 linux 一切皆文件的理念，连接数也是文件，linux系统默认限制了一个进程最多打开的文件数量。默认是1024。使用如下命令可以查看（前面提到过）：

[root@slave1 ~]# ulimit -a|grep open
open files                      (-n) 1024

从上述结果中可以看出，当前对于文件打开数量（open files）的限制为 1024，使用 ulimit -n 数字命令可以临时更改这个数量。下面修改打开文件数量为 65535：

修改linux服务器对于打开文件数量的限制方法1（临时有效）：

[root@slave1 ~]# ulimit -n 65535                 #修改打开文件数量限制
[root@slave1 ~]# ulimit -a|grep open             #查看打开文件数量限制
open files                      (-n) 65535

但这只更改了客户端linux系统，而服务器端仍然存在限制，所以重新运行ab命令进行测试

[root@slave1 ~]# ab -n1500 -c1500 http://192.168.81.250/trace/images/01.png

在1500 并发连接情况下，依然会出现失败的请求，所以也要改服务器端对打开文件数量的限制。在ab的测试报告中会看到如下信息：

Complete requests:      1500     #完成发送的请求数
Failed requests:        1        #失败的请求数

从信息中可以看出，在1500的并发数下nginx服务器出现了失败的情况。

修改linux服务器对于打开文件数量的限制方法2(永久有效)：
--- 更改配置文件 /etc/profile 和 /etc/security/limits.conf

 #将ulimit加入到 /etc/profile 文件底部
[root@slave1 ~]# echo "ulimit -n 65535" >> /etc/profile

#加载修改后的profile
[root@slave1 ~]# source /etc/profile

OK，好多朋友都以为大功告成了，可以突然发现自己再次登录进来的时候，ulimit的值还是1024，这是为什么呢？
关键的原因是你登录的用户是什么身份，是不是root用户，由于服务器的root用户权限很大，一般是不能用来登录的，都是通过自己本人的登录权限进行登录，并通过sudo方式切换到root用户下进行工作。用户登录的时候执行sh脚本的顺序：
/etc/profile.d/file
/etc/profile
/etc/bashrc
/mingjie/.bashrc
/mingjie/.bash_profile

由于ulimit -n的脚本命令加载在第二部分，用户登录时由于权限原因在第二步还不能完成ulimit的修改，所以ulimit的值还是系统默认的1024。

解决办法：
修改linux的软硬件限制文件/etc/security/limits.conf.

[root@slave1 ~]# echo "* soft nofile 65535" >> /etc/security/limits.conf 
[root@slave1 ~]# echo "* hard nofile 65535" >> /etc/security/limits.conf 
[root@slave1 ~]# ulimit -a|grep open
open files                      (-n) 65535

2 优化nginx连接数

前提是先设置好 linux服务器对于打开文件数量的限制

为了使nginx能够承载更高的并发数，可以编辑 conf/nginx.conf 配置文件进行配置，具体如下。

#user  nobody;
user root;
worker_processes  auto;
worker_rlimit_nofile 65535;

events {
    worker_connections  65535;
	multi_accept on;
}

在上述配置中，worker_processes 指令用于指定工作进程的个数，设置为auto时 nginx 将根据 cpu 的核心数来控制；worker_rlimit_nofile 用于设置最多打开的文件数量；worker_connections 用于设置每个工作进程可接收的连接数；multi_accept 表示是否允许一个工作进程响应多个请求。
nginx 支持select、poll、kqueue、epoll 等多种类型的连接处理方式，在默认情况下会自动选择最适合系统的方式。在系统内核和 glibc （C运行库）支持的情况下，nginx会自动使用 epoll 方式。epoll 时linux平台上性能非常高的一种多路I/O复用模型。

接下来，使用ApacheBench工具进行 3000 并发数测试，具体操作如下。

[root@slave1 ~]# ab -n3000 -c3000 http://192.168.81.250/trace/images/01.png
.
.
.


Concurrency Level:      3000
Time taken for tests:   4.114 seconds
Complete requests:      3000
Failed requests:        0

从测试报告中可以看出，nginx 完成了并发测试，没有出现失败的请求。

二用户打开的最大进程数

1 查看用户打开的最大进程数

ulimit -a

max user processes (-u) #系统限制某用户下最多可以运行多少进程或线程

再比如：

或者直接使用 ulimit -u

2 这些个值是怎么来的？

ulimit -u 出现的max user processes 的值默认是 # cat /proc/sys/kernel/threads-max的值/2，即系统线程数的一半

3 怎么修改linux最大进程数

我的一个低配版的服务器参数如下：(ulimit -a 或 ulimit -u 查看)

[root@izbp1845cet96se1qmb5ekz ~]# ulimit -u
3895

3.1 在 /etc/security/limits.conf 文件里添加如下内容：

* soft nproc 65535
* hard nproc 65535

方法如下：

[root@izbp1845cet96se1qmb5ekz ~]# echo "* soft nproc 65535" >> /etc/security/limits.conf 
[root@izbp1845cet96se1qmb5ekz ~]# echo "* hard nproc 65535" >> /etc/security/limits.conf

如果使用*号让全局用户生效是受文件/etc/security/limits.d/20-nproc.conf中nproc值大小制约的

3.2 修改 /etc/security/limits.d/20-nproc.conf
修改为：
* soft nproc 65535

如图：

3.3 系统总限制

经过以上3.1，3.2 两步，再次查看 max user processes ，已变更为：

但上面的max user processes (-u) 65535 的值也只是表象，用户最大进程数无法达到65535，因为用户的max user processes的值，最后是受全局的kernel.pid_max的值限制。也就是说若kernel.pid_max=3895 ，那么用户能打开的最大进程数还是3895。

查看全局的 pid_max 方法：

方法一：

[root@izbp1845cet96se1qmb5ekz ~]# cat /proc/sys/kernel/pid_max 
32768

方法二：

[root@izbp1845cet96se1qmb5ekz ~]# sysctl kernel.pid_max
kernel.pid_max = 32768

其实，这个值 32678 已经够用了。

修改这个值的方法：
echo 65535 > /proc/sys/kernel/pid_max

所以以上都操作完成后，才算是正确修改了max user processes 的值

上面只是临时生效，重启机器后会失效

永久生效方法：

在/etc/sysctl.conf中添加kernel.pid_max = 65535

# vim /etc/sysctl.conf

kernel.pid_max = 65535

或者：

echo "kernel.pid_max = 65535" >> /etc/sysctl.conf

然后重启机器

ab压力测试 和 nginx 配置优化 及 用户打开的最大进程数

一 ab压力测试 和 nginx 配置优化

二 用户打开的最大进程数

ab压力测试和 nginx 配置优化及用户打开的最大进程数

一 ab压力测试和 nginx 配置优化

二用户打开的最大进程数