NGINX 处于 D 状态,阻塞

2020-08-02 01:17:19 +08:00
 yuyuyu

centos7,4CPU 8G,nginx 时不时在 top 里出现 d 状态,查了下是 uninterruptible sleep,出现的时候 iftop 网络全部跌至低谷,io 飙升,nginx 不接受也不处理新请求,业务阻塞死,大概 1 秒以后恢复,期间 CPU 、内存都正常,看 IOPS 也很低才几百(通过阿里云的监控看的),nginx 使用了 cache,把 proxy_cache 相关的全部注释掉关闭 cache 后不再出现 d 状态,这到底是啥问题?服务器是阿里 ECS,CPU 和内存肯定够用,IO 也不高,下面是出现问题时的状态:

avg-cpu: %user %nice %system %iowait %steal %idle 10.61 0.00 12.12 25.25 0.00 52.02

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 51.00 217.00 163.00 1123.00 880.00 6212.00 11.03 11.63 9.05 2.46 10.00 0.41 53.20

avg-cpu: %user %nice %system %iowait %steal %idle 12.56 0.00 13.57 39.20 0.00 34.67

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 0.00 257.00 168.00 930.00 716.00 5100.00 10.59 38.18 34.77 5.36 40.08 0.51 56.20

avg-cpu: %user %nice %system %iowait %steal %idle 16.58 0.00 16.58 63.32 0.00 3.52

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 29.00 291.00 184.00 1635.00 1040.00 37052.00 41.88 56.54 31.08 7.70 33.71 0.47 86.00

iotop:

Total DISK READ : 625.15 K/s | Total DISK WRITE : 680.54 K/s Actual DISK READ: 625.15 K/s | Actual DISK WRITE: 31.36 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 3174 be/4 nginx 320.49 K/s 328.40 K/s 0.00 % 42.88 % nginx: worker process 4012 be/4 root 0.00 B/s 0.00 B/s 0.00 % 39.93 % [kworker/u4:3+flush-253:0] 3173 be/4 nginx 304.66 K/s 352.14 K/s 0.00 % 36.35 % nginx: worker process Total DISK READ : 1148.47 K/s | Total DISK WRITE : 1089.07 K/s Actual DISK READ: 1148.47 K/s | Actual DISK WRITE: 3.77 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 4012 be/4 root 0.00 B/s 0.00 B/s 0.00 % 41.17 % [kworker/u4:3-events_unbound] 3173 be/4 nginx 570.28 K/s 574.24 K/s 0.00 % 37.87 % nginx: worker process 3174 be/4 nginx 578.20 K/s 514.83 K/s 0.00 % 37.18 % nginx: worker process

下面是我的 NGINX 配置: worker_processes 2; worker_shutdown_timeout 180s;

error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid;

worker_rlimit_nofile 65535; events {

worker_connections 65535;

} http {

include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" $upstream_cache_status $request_time $upstream_response_time';

access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
gzip on;
gzip_types application/json text/plain application/x-javascript application/javascript text/javascript text/css application/xml text/xml;
gzip_min_length 1k;
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 8 512k;
server_tokens off;
underscores_in_headers on;
proxy_temp_path /tmp/cache_tmp;
proxy_cache_path /tmp/cache levels=1:2 keys_zone=cache1:100m inactive=7d max_size=20g;
upstream backend {

	server xxx:xx max_fails=3 weight=3 fail_timeout=60s;
}
server {

	listen 80;
	location / {

		proxy_pass http://backend;
		proxy_http_version 1.1;
		
		proxy_set_header Connection "";
		proxy_cache cache1;
		proxy_cache_convert_head off;
		proxy_cache_key $uri
		proxy_cache_revalidate on;
		proxy_cache_methods GET HEAD POST;
		
	}
}

}

3204 次点击
所在节点    NGINX
9 条回复
vk42
2020-08-02 01:24:24 +08:00
查下阻塞的时候 wchan 是什么?
mml
2020-08-02 02:00:46 +08:00
几百 iops 和下面那些 iowait 都不低啊。
yuyuyu
2020-08-02 10:47:46 +08:00
@mml 但阿里 ecs 给的性能完全不止这点啊,他们的云盘有 10000 iops,我也给阿里发了工单,他们说 iops 不高,让我检查下 nginx 的 cache 设置,但我实在不知道这个 proxy_cache 还有什么可以优化的地方
realpg
2020-08-02 11:50:18 +08:00
基本是 IO 的问题。
运作良好时候会有 10000 IOPS
映射的块有问题时候 就上不去了啊……
yuyuyu
2020-08-02 11:52:17 +08:00
@realpg 那这个要怎么解决?多挂几块云盘分散一下?
realpg
2020-08-02 11:54:33 +08:00
另外,虚拟环境,考虑 DIRECTIO,与 VM 的 IPSAN 、Local SSD IO cache 的问题,这个不好调试
yuyuyu
2020-08-02 19:25:17 +08:00
@realpg 用 fio 测了下随机写 4K,只有 9M/s 左右,是不是这个原因? 32K 就有 72M/S,NGINX 怎么优化?
linuxmap
2020-08-03 11:22:19 +08:00
可以考虑一下这样的架构。nginx1+ats+nginx2:nginx1 专心的做业务处理,使用 lua 会非常的方便 ats 专门做缓存 nginx2 做回源处理。
linuxmap
2020-08-03 11:23:54 +08:00
proxy_cache 在磁盘满了之后的 磁盘调整的策略好像有点问题, 楼主可以分析一下这块的代码。

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

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

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

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

© 2021 V2EX