Problemas de tráfego estranho do servidor de conteúdo estático nginx do Ubuntu

Question

Eu tenho um Ubuntu 15.10 executando nginx 1.9.3 para servir conteúdo estático que são principalmente imagens e arquivos de vídeo. Não há outros processos personalizados em execução que consomem até 1% dos recursos do servidor. Não há nenhum processamento PHP e nenhuma conexão de banco de dados SQL está acontecendo.

A saída de netstat -an | wc -l está sempre no intervalo de conexões de 700-1500 tcp. Em 95% dos casos, a maioria dos usuários solicita o download de um arquivo de vídeo de 3.5 MB (registros de acesso nginx confirmam isso) que, devido aos mecanismos de cache do nginx e do próprio linux, tenho certeza que estão sempre armazenados na RAM. E de fato - a saída de iotop me diz que há 0 - 0.5% de disco lido na maior parte do tempo, portanto, sei que o problema para o qual estou chegando não está relacionado a E / S de disco.

A execução de nload por um período de três horas informa que meu tráfego se parece com isso:

Curr: 103.41 MBit/s
Avg: 73.97 MBit/s
Min: 14.62 MBit/s
Max: 457.88 MBit/s
Ttl: 141357.91 GByte

Sempre que o número de conexões tcp for maior que ~ 1200, os usuários enfrentarão atrasos / tempos limite ao carregar dados do servidor.

Deixe-me expandir o que observei sobre esses "atrasos / tempos limite" até o momento:

Estou quase certo de que a configuração do nginx não é responsável, já que não são apenas conexões HTTP que atingem o tempo limite, mas mesmo quando pingando (ICMP) o servidor de outro computador, recebo muitos resultados de solicitação expirada. mencionado marcador de conexão tcp é atingido.

Ao executar o Wireshark a partir do Windows e carregar este vídeo de 3,5 MB no navegador (durante as altas cargas mencionadas), vejo que muitos pacotes rotulados com

[TCP ACKed unseen segment] [TCP Previous segment not captured]

isso significa que alguns pedaços (pacotes) deste arquivo de vídeo não são entregues para mim. Isso me fez pensar que o meu problema provavelmente está relacionado à NIC do meu servidor não conseguir processar todo o tráfego de outgoing ou há uma limitação de largura de banda / tráfego da empresa de hospedagem que hospeda meu servidor. No entanto, depois de vários questionamentos, eles me garantiram que não há limite de tráfego definido do lado deles, o que seria um problema para meu consumo atual de largura de banda.

O próximo teste que fiz foi capturar solicitações / respostas de ping provenientes do meu sistema operacional Windows para o meu servidor em ambos os lados - usando o Wireshark no windows e tcpdump no Ubuntu. O resultado é quase sempre o seguinte (durante cargas altas):

No Ubuntu, vejo que todos os pacotes ICMP Ping Request são combinados com um pacote Ping Reply. Não há um único problema lá. No Windows, 5-6 dos 20 pacotes ICMP Ping Request não receberam seus pacotes correspondentes de resposta Ping.

A partir disso, eu sei que o servidor no nível da CPU vê e manipula as conexões corretamente e é apenas após o envio de um pacote (resposta) para a interface de rede (NIC) ou além, há um problema.

Aqui estão minhas configurações para nginx, interface de rede e informações do meu servidor:

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 / sites-available / default

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;
    }
}

Saída do ifconfig (nota: modifiquei o parâmetro txqueuelen ao tentar várias otimizações de NIC para corrigir este problema)

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)

Saída de sysctl -a

link

Nota: eu modifiquei vários parâmetros como:

net.core.somaxconn
net.core.netdev_max_backlog
net.ipv4.tcp_max_syn_backlog 

Na tentativa de combater esse problema.

Também defini ulimit -n 900000 quando pensei que esse problema poderia estar relacionado ao número de arquivos abertos que cada processo pode ter.

Especificações do meu servidor:

Placa-mãe: ASUS X99-A

CPU: Estou tendo problemas para determinar o modelo exato do Core i7 para a CPU devido ao fato de 'nome do modelo' de cat /proc/cpuinfo outputs Genuine Intel(R) CPU @ 2.40GHz , mas sei que ele tem 24 núcleos e aqui está a saída de cat /proc/cpuinfo : link

RAM: 64 GB

HDD: 4TB da Seagate

NIC: Intel® I218V integrado, 1 x controlador de LAN Gigabit

Eu tenho lutado com esse problema por 1 semana agora. A NIC é a causa desse problema? Talvez eu esteja enganado em minhas suposições? Eu posso fornecer qualquer outra saída de comando necessária.