[求助] nginx 服务器在并发达到 300 就出现响应慢,甚至到 8 秒的情况

2019-05-27 16:29:19 +08:00
 q937298063
服务器版本:centos
服务器配置:阿里云实例规格:ecs.c5.large 2 核 4G
服务器环境:nginx 1.14.1 + php 5.6.36 + mysql 5.7.22

问题描述:在并发量在 300 的时候,不知道为什么响应时间特别长 达到了 8 秒甚至 10 秒以上

测试描述: 使用 apache 的 ab 压力测试工具 测试网站的页面,这个页面什么也没有就是单纯的用 php return 了一个 json 字符串。使用的命令是.\abs -c 300 -n 500 地址

测试结果
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path: /
Document Length: 166 bytes

Concurrency Level: 300
Time taken for tests: 12.325 seconds
Complete requests: 500
Failed requests: 257
(Connect: 0, Receive: 0, Length: 257, Exceptions: 0)
Non-2xx responses: 243
Total transferred: 124917 bytes
HTML transferred: 47791 bytes
Requests per second: 40.57 [#/sec] (mean)
Time per request: 7395.060 [ms] (mean)
Time per request: 24.650 [ms] (mean, across all concurrent requests)
Transfer rate: 9.90 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 557 1737 783.3 1517 3500
Processing: 30 2514 2053.8 1862 6267
Waiting: 28 2360 2152.5 1711 6267
Total: 1248 4251 2325.3 5031 8428

Percentage of the requests served within a certain time (ms)
50% 5031
66% 5784
75% 6284
80% 6574
90% 7450
95% 7755
98% 8107
99% 8338
100% 8428 (longest request)


配置信息:
nginx.conf

user www www;

worker_processes auto;

error_log /home/wwwlogs/nginx_error.log crit;

pid /usr/local/nginx/logs/nginx.pid;

#Specifies the value for maximum file descriptors that can be opened by this process.
worker_rlimit_nofile 51200;

events
{
use epoll;
worker_connections 51200;
accept_mutex off;
multi_accept on;
}

http
{
include mime.types;
default_type application/octet-stream;

server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 50m;

sendfile on;
tcp_nopush on;

keepalive_timeout 0;

tcp_nodelay on;

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2;
gzip_types text/plain application/javascript application/x-javascript text/javascript text/css application/xml application/xml+rss;
gzip_vary on;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\.";

#limit_conn_zone $binary_remote_addr zone=perip:10m;
##If enable limit_conn_zone,add "limit_conn perip 10;" to server section.

server_tokens off;
access_log off;
}


php-fpm.conf

[global]
pid = /usr/local/php/var/run/php-fpm.pid
error_log = /home/wwwlogs/php-fpm.log
log_level = notice

[www]
listen = /tmp/php-cgi.sock
listen.backlog = -1
listen.allowed_clients = 127.0.0.1
listen.owner = www
listen.group = www
listen.mode = 0666
user = www
group = www
pm = static
pm.max_children = 32
pm.start_servers = 30
pm.min_spare_servers = 30
pm.max_spare_servers = 200
request_terminate_timeout = 100
request_slowlog_timeout = 0
slowlog = var/log/slow.log
6725 次点击
所在节点    Linux
43 条回复
tankerwng
2019-05-27 16:33:31 +08:00
没 log 没真相,请展示 error.log 。
rockivy
2019-05-27 16:34:59 +08:00
ab 压测要带上-k 参数,开启 keepalive 特性。
q937298063
2019-05-27 16:35:42 +08:00
nginx 没有报错 php-fpm 也木有报错。。。。。我也是很绝望
q937298063
2019-05-27 16:36:22 +08:00
@rockivy 好的 我测试一下 多谢
q937298063
2019-05-27 16:38:17 +08:00
@rockivy 老哥 我带上-k 的测试效果 还是这样 我是这样输入的 .\abs -k -c 300 -n 500 地址
azh7138m
2019-05-27 16:40:05 +08:00
为啥提到了 MySQL,是去数据库查询数据然后返回吗?
q937298063
2019-05-27 16:44:07 +08:00
@azh7138m 木有 只是怕没说明白。顺带说一下,因为我先从线上环境里发现这个问题的。一开始我认为是我写的 sql 语句有问题,最后查看了日志。一次接口调用 sql 时用的时间不超过 0.5 秒所以排除了。目前我从网上资料查询过来,都是说 nginx 和 php-fpm 之间的问题。可是我尝试的修改 php-fpm 的数量依旧没有任何效果。
Citrus
2019-05-27 16:58:18 +08:00
压测期间 CPU 内存情况呢?
q937298063
2019-05-27 16:59:59 +08:00
@Citrus 测试期间的话 cpu 最高达到 56%左右 并没有爆。。。
asilin
2019-05-27 17:00:29 +08:00
排除法:
1. 测试 nginx 服务本身,放一个静态页面 index.html 压测,得到 nginx 和外网带宽的最大 QPS ;
2. 开启 FPM 服务进行压测,此时的 QPS 肯定比 nginx 的低,看是否和现在的故障 QPS 一致;
3. 如果一致,那很明显是 FPM 本身有瓶颈了。

另外建议安装 atop,ganglia 等软件,实时查看服务器当前各项指标,加速找到问题原因。
q937298063
2019-05-27 17:01:32 +08:00
@asilin 嗯 好的 多谢大佬。我先尝试一下。
janxin
2019-05-27 17:05:22 +08:00
看起来不是 nginx 的问题,具体的最好能拉一下 log

几个有用 log 字段可以打印一下
$upstream_connect_time
$upstream_header_time
$upstream_response_time
tankerwng
2019-05-27 17:08:33 +08:00
看看 access,请求没有超时的?全都是 200 ?
q937298063
2019-05-27 17:17:29 +08:00
@janxin 嗯,好的,我修改一下,进行尝试
q937298063
2019-05-27 17:19:37 +08:00
@asilin 我总觉得问题更大了。我 测试了一个静态的页面 里面也是啥也没有 就是一条 json 字符串。然后测试条件与上面一致,结果居然 有 4s 之多?
danc
2019-05-27 17:19:57 +08:00
php 能达到 200 的并发就已经不错了吧
q937298063
2019-05-27 17:20:26 +08:00
有很多,最多的时候有一半之多 502
q937298063
2019-05-27 17:21:12 +08:00
@danc 真的假的 我翻过老的提问,他们都说 1 核 1G 就可以了。。。。
ztxcccc
2019-05-27 17:22:14 +08:00
opcache 开了吗,如果开的话注意一下 opcache 的重新检测时间
danc
2019-05-27 17:22:36 +08:00
我以前装个 wordpress, 不停的按 F5,就能宕机了.加个缓存还好点

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/568073

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX