我有一个运行nginx 1.9.3的Ubuntu 15.10，用于提供主要是图像和video文件的静态内容。 没有其他自定义进程正在运行，甚至只占用serer资源的1％。 没有任何PHP处理，也没有任何SQL数据库连接发生。
netstat -an | wc -l的输出 netstat -an | wc -l总是在700-1500个tcp连接的范围内。 在95％的情况下，大多数用户请求下载一个3.5 MB的video文件（nginx访问日志证实这一点），由于nginx和linux本身的caching机制，我相信总是存储在RAM中。 事实上， iotop输出告诉我，大部分时间里有0 – 0.5％的磁盘读取，所以我知道我遇到的问题与磁盘I / O无关。
运行nload 3小时，告诉我，我的stream量是这样的：
Curr: 103.41 MBit/s Avg: 73.97 MBit/s Min: 14.62 MBit/s Max: 457.88 MBit/s Ttl: 141357.91 GByte
每当tcp连接的数量大于1200时，用户在从服务器加载数据时会遇到延迟/超时。
让我展开一下我到目前为止所观察到的有关这些“延迟/超时”的内容：
我几乎可以肯定，nginx的configuration不是怪，因为它不只是HTTP连接，超时，但即使从另一台计算机简单地ping（ICMP）服务器时，我得到了很多“请求超时”的结果，当上面提到的TCP连接标记已到达。
当从Windows运行Wireshark并在浏览器中加载这个3.5 MB的video（在提到的高负载时），我看到很多数据包标有
[TCP ACKed unseen segment] [TCP Previous segment not captured]
这意味着这个video文件的一些块（包）没有传递给我。 这让我想到，我的问题很可能与我的服务器的NIC无法处理所有outgoingstream量或者承载我的服务器的托pipe公司的带宽/stream量限制有关。 然而，在多次询问之后，他们向我保证，从他们那边没有设置stream量限制，这对我当前的带宽消耗来说是一个问题。
我做的下一个testing是捕获从我的Windows操作系统到我的服务器的ping请求/回复 – 在Windows上使用Wireshark，在Ubuntu上使用tcpdump 。 结果几乎总是（高负荷时）：
在Ubuntu上，我可以看到每个ICMP Ping请求数据包都与一个Ping应答数据包匹配。 那里没有一个单一的问题。 在Windows上，20个ICMP Ping请求报文中有5-6个没有收到匹配的Ping Reply报文。
由此我知道CPU级别上的服务器正确地看到和处理了连接，并且在向networking接口（NIC）发送一个数据包（应答）之后或之后就出现了问题。
这里是我的configurationnginx，networking接口和我的服务器信息：
nginx.conf
user www-data; worker_processes auto; pid /run/nginx.pid; events { use epoll; worker_connections 20000; multi_accept on; } worker_rlimit_nofile 25000; http { ## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 15; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; client_max_body_size 500M; ## # SSL Settings ## ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on; ## # Logging Settings ## access_log /var/log/nginx/access.log; #access_log off; error_log /var/log/nginx/error.log; ## # Gzip Settings ## gzip on; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; ## # Virtual Host Configs ## open_file_cache max=2000 inactive=20s; open_file_cache_valid 60s; open_file_cache_min_uses 5; open_file_cache_errors off; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }
在/ etc / nginx的/网站可用/默认
server { listen 80 backlog=4096 default_server; listen [::]:80 default_server; # SSL configuration # # listen 443 ssl default_server; # listen [::]:443 ssl default_server; # # Note: You should disable gzip for SSL traffic. # See: https://bugs.debian.org/773332 # # Read up on ssl_ciphers to ensure a secure configuration. # See: https://bugs.debian.org/765782 # # Self signed certs generated by the ssl-cert package # Don't use them in a production server! # # include snippets/snakeoil.conf; root /var/www/html; # Add index.php to the list if you are using PHP index index.php index.html index.htm index.nginx-debian.html; server_name 93.188.8.60; location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. try_files $uri $uri/ =404; } # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { include snippets/fastcgi-php.conf; # # # With php5-cgi alone: # fastcgi_pass 127.0.0.1:9000; # # With php5-fpm: fastcgi_read_timeout 900; fastcgi_pass unix:/var/run/php5-fpm.sock; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # location ~ /\.ht { deny all; } }
ifconfig的输出 （注：当尝试各种网卡优化来修复这个问题时，我修改了txqueuelen参数）
eno1 Link encap:Ethernet HWaddr 30:5a:3a:56:39:bc inet addr:93.188.8.60 Bcast:93.188.8.255 Mask:255.255.255.0 inet6 addr: fe80::325a:3aff:fe56:39bc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:50327240672 errors:0 dropped:173244 overruns:0 frame:0 TX packets:104203043819 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:5000 RX bytes:4067795598631 (4.0 TB) TX bytes:151795336718586 (151.7 TB) Interrupt:20 Memory:fb200000-fb220000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:133764933 errors:0 dropped:0 overruns:0 frame:0 TX packets:133764933 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:10569844193 (10.5 GB) TX bytes:10569844193 (10.5 GB)
sysctl -a的输出
https://pastebin.com/zv86U9jn
注：我已经修改了几个参数，如：
net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_max_syn_backlog
试图解决这个问题。
我还设置了ulimit -n 900000当时我认为这个问题可能与每个进程允许拥有的打开文件的数量有关。
我的服务器规格：
主板：华硕X99-A
CPU：由于cat /proc/cpuinfo “型号名称”输出Genuine Intel(R) CPU @ 2.40GHz但是我知道它有24个内核，这里是输出从cat /proc/cpuinfo ： https ： //pastebin.com/TR7aS1NM
内存：64 GB
硬盘：4TB希捷
NIC：板载Intel®I218V，1个千兆局域网控制器
我一直在为这个问题奋斗了一个星期。 NIC是这个问题的原因吗？ 也许我错在我的假设？ 我可以提供任何其他需要的命令输出。