Chinaunix

标题: nginx并发到1000就出现假死，然后重启就好了，看后台系统的流量图形很怪异见附件 [打印本页]
作者: royzs    时间: 2016-03-18 14:35
标题: nginx并发到1000就出现假死，然后重启就好了，看后台系统的流量图形很怪异见附件
本帖最后由 royzs 于 2016-03-18 14:35 编辑

看阿里云后台流量图形也很怪异，断断续续的，我怀疑就是程序假死，并发支撑不了超过1000，nginx并发不是4万么，求助求助


nginx_status内容如下
  1. Active connections: 951
  2. server accepts handled requests
  3. 428729 423504 796115
  4. Reading: 0 Writing: 40 Waiting: 911
复制代码
Active connections这个数值从来没超过1000过

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
的内容如下
  1. TIME_WAIT 18216
  2. CLOSE_WAIT 3
  3. SYN_SENT 2
  4. FIN_WAIT1 122
  5. ESTABLISHED 1065
  6. FIN_WAIT2 666
  7. SYN_RECV 7
  8. CLOSING 2
  9. LAST_ACK 48
复制代码
作者: royzs    时间: 2016-03-18 14:39
网站运行运行着再看nginx_status就变成这样了，900多变成几百了
  1. Active connections: 510
  2. server accepts handled requests
  3. 528566 519322 966128
  4. Reading: 0 Writing: 510 Waiting: 0
复制代码
作者: royzs    时间: 2016-03-18 15:39
网站速度也特别慢，我的nginx配置是这样的
  1. server {
  2.         listen       80;
  3.         server_name www.sc.com;
  4.         index index.html index.htm index.php;
  5.         root  /mnt/www/fanwe;

  7.     location / {
  8.         root  /mnt/www/fanwe;
  9.         index  index.html index.htm index.php;
  10.     }

  12.     location /ngx_status
  13.     {
  14.         stub_status on;
  15.         access_log off;
  16.     }

  18.     location ~ \.php$ {
  19.        root           html;
  20.        fastcgi_pass   127.0.0.1:9000;
  21.        fastcgi_index  index.php;
  22.        fastcgi_param SCRIPT_FILENAME    /mnt/www/fanwe$fastcgi_script_name;
  23.        include        fastcgi_params;
  24.     }

  26.         location ~ .*\.(php|php5)?$ {
  27.                 fastcgi_pass unix:/tmp/php-cgi.sock;
  28.                 fastcgi_index index.php;
  29.                 #include fcgi.conf;
  30.         }

  32.         location ~ .*\.(ico|jpg|jpeg|png|gif)$ {
  33.                 expires 1y;
  34.                 valid_referers none blocked www.sc.com *.google.com *.baidu.com;
  35.                 if ($invalid_referer) {
  36.                         return 404;
  37.                 }
  38.         }
  39. }
复制代码
作者: lyhabc    时间: 2016-03-18 19:04
本帖最后由 lyhabc 于 2016-03-18 19:17 编辑

渣打银行            
TIME_WAIT 18216
TIME_WAIT 有点多喔
连接关闭后，进入TIME_WAIT状态，缺省时间是2分钟。之所以留这个时间，是为了让数据包能完全通过 各种规则的检查，也是为了数据包能通过拥挤的路由器，从而到达目的地。
服务器在等到客户端关闭连接

调节内核参数
Linux标准的发行版不可能知道你目前运行的网络环境，所以还得靠你自己利用可以调
节的内核参数动态优化TCP[IP栈。例如长连接会占用大量资源，在大并发的情况下，连接
过多将导致无数的连接失败。通常Apache采用短连接，nginx采用短连接，MySQI采用短
连接。但是短连接可能会导致TIME_ WAIT增多。TIME_WAIT的增多一般不会有太大的问题，但是大量的TIME—WAIT套接字也会把squid等网络应用给拖死。这时，调节几个内核参数就能搞定：
  1. tw：time_wait
  2. # ehc0 1> /proc/sys/net/ipv4/tcp_tw_reuse
  3. # ehc0 1>/proc/sys/net/ipv4/tcp_tw_recycle
  4. # ech0 6000>/proc/sys/net/ipv4/tcp_max_tw_buckets
复制代码
reuse是表示是否允许新的TCP连接重新应用处于TIME_WAIT状态的socket; recycle
是加速TIME_WAIT sockets回收；max _tw _buckets表示TIME_WAIT套接字的最大数量，如
果超过这个数字，TIME_WAIT饔接字将立刻被清除并打印警告信息。这些设置提高了处理
效率，还能把TIME_WAIT所占用内存控制在一定范围。
作者: lyhabc    时间: 2016-03-18 19:27
TIME_WAIT 18216
CLOSE_WAIT 3
SYN_SENT 2
FIN_WAIT1 122
ESTABLISHED 1065
FIN_WAIT2 666
SYN_RECV 7
CLOSING 2
LAST_ACK 48

作者: royzs    时间: 2016-03-18 22:24
回复 4# lyhabc


    tw：time_wait
# ehc0 1> /proc/sys/net/ipv4/tcp_tw_reuse
# ehc0 1>/proc/sys/net/ipv4/tcp_tw_recycle
# ech0 6000>/proc/sys/net/ipv4/tcp_max_tw_buckets

前两个参数都改过的，最下面的那个参数最开始是5000，不够用，系统一直报错kernel: TCP: time wait bucket table overflow
我给调成了2万，3万都不行，最后改成5万不再报错了，但是现在网站还是不稳定，刚启动nginx的时候看并发连接从一两百一直涨到900多1000多点，过几分钟或者半小时nginx就假死了，出现502，重启之后又是循环，所以流量图形里面显示断断续续的
作者: lyhabc    时间: 2016-03-19 10:53
神马版本的nginx？
是不是阿里云参数设置问题？
作者: lyhabc    时间: 2016-03-19 10:56
worker_processes 1;
error_log /usr/local/nginx/logs/nginx_error.log crit;
pid /usr/local/nginx/logs/nginx.pid;
worker_rlimit_nofile 51200;
events
{
use epoll;
worker_connections 6000;
}

nginx.conf 你这里设置是多少？
作者: royzs    时间: 2016-03-19 19:40
本帖最后由 royzs 于 2016-03-19 20:22 编辑

回复 7# lyhabc


    nginx 1.8.0

阿里云的sysctl.conf我改过，贴一下出来
  1. # sysctl -p
  2. net.ipv4.ip_forward = 0
  3. net.ipv4.conf.default.accept_source_route = 0
  4. kernel.sysrq = 0
  5. kernel.core_uses_pid = 1
  6. kernel.msgmnb = 65536
  7. kernel.msgmax = 65536
  8. kernel.shmmax = 68719476736
  9. kernel.shmall = 4294967296
  10. vm.swappiness = 0
  11. net.ipv4.neigh.default.gc_stale_time = 120
  12. net.ipv4.conf.all.rp_filter = 0
  13. net.ipv4.conf.default.rp_filter = 1
  14. net.ipv4.conf.default.arp_announce = 2
  15. net.ipv4.conf.all.arp_announce = 2
  16. net.ipv4.tcp_max_tw_buckets = 6000
  17. net.ipv4.tcp_sack = 1
  18. net.ipv4.tcp_window_scaling = 1
  19. net.core.wmem_default = 8388608
  20. net.core.rmem_default = 8388608
  21. net.core.rmem_max = 16777216
  22. net.core.wmem_max = 16777216
  23. net.core.somaxconn = 262144
  24. net.ipv4.tcp_max_orphans = 3276800
  25. net.ipv4.tcp_max_syn_backlog = 262144
  26. net.ipv4.tcp_timestamps = 0
  27. net.ipv4.tcp_synack_retries = 1
  28. net.ipv4.tcp_syn_retries = 1
  29. net.ipv4.tcp_tw_recycle = 1
  30. net.ipv4.tcp_mem = 94500000 915000000 927000000
  31. net.ipv4.tcp_fin_timeout = 1
  32. net.ipv4.tcp_keepalive_time = 30
  33. net.ipv4.ip_local_port_range = 1024 65000
  34. net.ipv4.tcp_syncookies = 1
复制代码
net.ipv4.tcp_max_tw_buckets = 6000
的时候并发1000就开始假死，我改成50000后勉强4000多并发就不行了
作者: royzs    时间: 2016-03-19 19:42
回复 8# lyhabc


nginx.conf我的配置是这样的
  1. worker_processes 16;
  2. worker_cpu_affinity 0000000000000001 0000000000000010 0000000000000100 0000000000001000 0000000000010000 0000000000100000 0000000001000000 0000000010000000 0000000100000000 0000001000000000 0000010000000000 0000100000000000 0001000000000000 0010000000000000 0100000000000000 1000000000000000;

  4. error_log  /var/log/nginx/error.log crit;
  5. pid        /var/run/nginx.pid;
  6. worker_rlimit_nofile 65535;

  8. events {
  9.     use epoll;
  10.     worker_connections  65535;
  11. }
复制代码
作者: royzs    时间: 2016-03-19 19:52

现在阿里云的后台截图是这样的
作者: royzs    时间: 2016-03-19 20:05
现在最要命的两个问题，一个是打开慢，转圈圈要等四五秒钟，还有一个就是一楼贴出的那些图片，只见并发数升升降降，到一个阶段就有什么东西限制了好像，并发上不去
作者: lyhabc    时间: 2016-03-19 20:25
worker_connections 6000;
这个设置小一点，设置得太多有可能502
作者: royzs    时间: 2016-03-19 20:43
本帖最后由 royzs 于 2016-03-19 20:43 编辑

回复 13# lyhabc


    好的，我改回来
作者: royzs    时间: 2016-03-19 20:56
本帖最后由 royzs 于 2016-03-19 20:57 编辑

回复 13# lyhabc


    改回来之后系统message日志就是一堆
  1. Mar 19 20:55:27 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  2. Mar 19 20:55:27 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  3. Mar 19 20:55:27 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  4. Mar 19 20:55:27 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  5. Mar 19 20:55:32 iZ230e7qzlnZ kernel: __ratelimit: 43 callbacks suppressed
  6. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  7. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  8. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  9. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  10. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  11. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  12. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  13. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  14. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  15. Mar 19 20:55:32 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  16. Mar 19 20:55:37 iZ230e7qzlnZ kernel: __ratelimit: 1492 callbacks suppressed
  17. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  18. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  19. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  20. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  21. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  22. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  23. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  24. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  25. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
  26. Mar 19 20:55:37 iZ230e7qzlnZ kernel: TCP: time wait bucket table overflow
复制代码
502也有
作者: royzs    时间: 2016-03-19 20:57
服务器是阿里云16核16G内存，70m带宽
作者: royzs    时间: 2016-03-19 20:59
  1. Active connections: 3915
  2. server accepts handled requests
  3. 297345 297345 472068
  4. Reading: 0 Writing: 2391 Waiting: 1524
复制代码
这种waiting是不是太多了呢
作者: action08    时间: 2016-03-20 09:22
这个并发的压测试，还是看你的内容

一般是分步骤的，
1，测试纯html文件，这个是nginx连接线路情况的
2，测试phpinfo函数，这个是配置php情况的，nginx基本服务ok的情况下，进一步测试
3，测试数据库，还有这种服务的，自己写php/mysq/redis脚本，继续测试


你说的并发假死的事情，是第几步的情况？？话说访问压力大了，出现问题的情况都比较多，关键是针对瓶颈下手l
作者: action08    时间: 2016-03-20 09:23
本帖最后由 action08 于 2016-03-20 09:25 编辑

现在linux基本都很先进，一般少对系统参数做调整
1，rhel/centos本身就是商用服务器环境
2，ubuntu现在内核桌面和服务器早就合二为一了
3，debian也是为服务器设计的主流系统



都是服务器环境，少动（因为有不少优化教程已经成为古董）
当然我承认，确实有一些网络参数调整一下是有局部意义的性能帮助
作者: lyhabc    时间: 2016-03-20 10:39
现在的问题是：time wait bucket table overflow

再加大一下试试
ech0 100000>/proc/sys/net/ipv4/tcp_max_tw_buckets
作者: royzs    时间: 2016-03-20 10:43
回复 18# action08


    服务器就是LNMP环境，大神你指的分三步是先测试静态然后测试动态吗，因为现在已经是线上环境了，我没有做压力测试，现在nginx配置的缓存，php-fpm调整了max_children参数
nginx.conf如下
  1. user  nginx;
  2. worker_processes 16;
  3. worker_cpu_affinity 0000000000000001 0000000000000010 0000000000000100 0000000000001000 0000000000010000 0000000000100000 0000000001000000 0000000010000000 0000000100000000 0000001000000000 0000010000000000 0000100000000000 0001000000000000 0010000000000000 0100000000000000 1000000000000000;

  5. error_log  /var/log/nginx/error.log crit;
  6. pid        /var/run/nginx.pid;
  7. worker_rlimit_nofile 65535;

  9. events {
  10.     use epoll;
  11.     worker_connections  65535;
  12. }

  14. http {
  15.     #include       /etc/nginx/mime.types;
  16.     include       mime.types;
  17.     default_type  application/octet-stream;

  19.     log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
  20.                       '$status $body_bytes_sent "$http_referer" '
  21.                       '"$http_user_agent" "$http_x_forwarded_for"';

  23.     access_log  /var/log/nginx/access.log  main;

  25.     #sendfile        on;
  26.     #tcp_nopush     on;

  28.     #keepalive_timeout  65;

  30.     server_names_hash_bucket_size 128;
  31.     client_header_buffer_size 4k;
  32.     large_client_header_buffers 4 32k;
  33.     client_max_body_size 300m;
  34.     client_body_buffer_size 128k;

  36.     sendfile on;
  37.     tcp_nopush on;
  38.     keepalive_timeout 60;
  39.     tcp_nodelay on;
  40.    
  41.     fastcgi_cache_path /var/cache/nginx/fastcgi_cache levels=1:2
  42.     keys_zone=TEST:10m
  43.     inactive=5m;
  44.     fastcgi_connect_timeout 300;
  45.     fastcgi_send_timeout 300;
  46.     fastcgi_read_timeout 300;
  47.     fastcgi_buffer_size 4k;
  48.     fastcgi_buffers 8 4k;
  49.     fastcgi_busy_buffers_size 8k;
  50.     fastcgi_temp_file_write_size 8k;

  52.     proxy_connect_timeout 600;
  53.     proxy_read_timeout 300;
  54.     proxy_send_timeout 600;
  55.     proxy_buffer_size 64k;
  56.     proxy_buffers 16 128k;
  57.     proxy_busy_buffers_size 512k;
  58.     proxy_temp_file_write_size 512k;

  60.     gzip on;
  61.     gzip_min_length 1k;
  62.     gzip_buffers 4 16k;
  63.     gzip_http_version 1.1;
  64.     gzip_comp_level 2;
  65.     gzip_types text/plainapplication/x-javascript text/css application/xml;
  66.     gzip_vary on;

  68.     proxy_temp_path /var/cache/nginx/proxy_temp;
  69.     proxy_cache_path /var/cache/nginx/proxy_templevels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;

  71.     #gzip  on;

  73.     include /etc/nginx/conf.d/*.conf;
  74. }
复制代码
vhost文件内容如下
server {
        listen       80;
        server_name www.sc.com;
        index index.html index.htm index.php;
        root  /mnt/www/we;

    location / {
        root  /mnt/www/we;
        index  index.html index.htm index.php;
    }

    location /ngx_status
    {
        stub_status on;
        access_log off;
    }

    location ~ \.php$ {
       root           html;
       fastcgi_pass   127.0.0.1:9000;
       fastcgi_index  index.php;
       fastcgi_param SCRIPT_FILENAME    /mnt/www/fanwe$fastcgi_script_name;
       include        fastcgi_params;
    }

        location ~ .*\.(php|php5)?$ {
                fastcgi_pass unix:/tmp/php-cgi.sock;
                fastcgi_index index.php;
                #include fcgi.conf;
        }

        location ~ .*\.(ico|jpg|jpeg|png|gif)$ {
                expires 1y;
                valid_referers none blocked www.sc.com *.google.com *.baidu.com;
                if ($invalid_referer) {
                        return 404;
                }
        }
}
作者: royzs    时间: 2016-03-20 11:02
回复 20# lyhabc


    改过来了，现在不报那个错了，并发少的时候很稳定，一上到三四千就出问题了

作者: action08    时间: 2016-03-20 13:43
本帖最后由 action08 于 2016-03-20 13:46 编辑

回复 22# royzs


    压力大了，瓶颈出来了，自然就有种种延迟导致的错误


办法，短期有效果加硬件
如果时间条件等等都允许，优化业务逻辑代码，
没办法——银行是不是所有的数据都要求实时哦？？
作者: royzs    时间: 2016-03-20 18:23
回复 23# action08

  2. top - 18:15:03 up  5:14,  2 users,  load average: 0.81, 1.97, 2.56
  3. Tasks: 593 total,   1 running, 592 sleeping,   0 stopped,   0 zombie
  4. Cpu(s):  0.2%us,  0.4%sy,  0.0%ni, 99.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  5. Mem:  16332772k total,  4255400k used, 12077372k free,   517884k buffers
  6. Swap:        0k total,        0k used,        0k free,   290176k cached
复制代码
网站并发1000多，有时候会突然访问不了，过一阵子又自己恢复了，查看系统资源占用，CPU只有百分之十几，内存只用了三分之一，CPU是16核，内存是16G
作者: royzs    时间: 2016-03-20 18:23
找到瓶颈了，RDS CPU占用率100%，居高不下
作者: action08    时间: 2016-03-20 18:36
回复 25# royzs


    恭喜，一般都是数据库io跟不上，换硬件加nosql/cache，等处理方案
作者: royzs    时间: 2016-03-20 18:48
回复 26# action08


    您的意思是说要加nosql把MySQL的数据缓存进来，是这样吗，有没有办法在操作系统的基础上解决这个问题呢，因为程序是买的模版网站，那边技术总给扯皮，也买了阿里云的memcached做缓存，求教

作者: action08    时间: 2016-03-20 18:55
本帖最后由 action08 于 2016-03-21 10:18 编辑

回复 27# royzs


    我没有做过相关的正式项目哦，说得不对不要当真

我也是看嘉宾的分享，看你想怎么解决了
嘉宾说的简单一点的做法，加机器加配置（云服务怎么整，不懂哦）
如果时间等等都比较充裕，那么就改架构，看你自己的项目情况了
作者: royzs    时间: 2016-03-20 21:47
回复 28# action08


    改架构现在看可能性不大，数据库的问题解决了，慢查询找出问题SQL加了索引，然后现在看nginx status

Active connections: 1427
server accepts handled requests
263741 263741 540975
Reading: 0 Writing: 31 Waiting: 1396

这个waiting值一千多，是不是太高了呢，这个意思是有1396个请求在排队么
作者: royzs    时间: 2016-03-20 21:51
回复 29# royzs


    网上的说法是：
waiting — 开启 keep-alive 的情况下,这个值等于 active – (reading+writing), 意思就是 Nginx 已经处理完正在等候下一次请求指令的驻留连接

理解了几遍，实在不明白这个驻留连接，和等待下一次请求指令具体指的什么
作者: action08    时间: 2016-03-20 22:00
回复 29# royzs


    恩，sql不加索引，肯定毫不犹豫的处理

后面的优化就是nosql，也能有个提升，慢慢来吧
作者: lyhabc    时间: 2016-03-20 23:56
买的模板，阿里云，叫阿里云排查吧，提交工单，阿里云貌似RDS都配有SSD
作者: royzs    时间: 2016-03-21 13:46
回复 32# lyhabc


    回复 31# action08


    多谢两位不厌其烦的指导，谢谢
作者: wangbin    时间: 2016-03-21 16:49
TIME_WAIT 4550
SYN_SENT 27
FIN_WAIT1 139
FIN_WAIT2 846
ESTABLISHED 4666
SYN_RECV 21
CLOSING 7
LAST_ACK 18
作者: wangbin    时间: 2016-03-21 16:52
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2