☰

nginx trava algumas solicitações POST por um tempo

tag-icon • tag-icon nginx docker wordpress docker-compose
nginx trava algumas solicitações POST por um tempo

Tenho a seguinte pilha em execução no Ubuntu 18.08 e definida como docker-compose:

  1. instancia demariadb:10.3.20
  2. instância personalizada do wordpress com base wordpress:5.3.0-php7.2na instalada ioncubenela
  3. instância nginx personalizada com base nginx:1.13na instalada nginx-amplify-agentnela

Configuração do nginx:

user  nginx;
worker_processes  auto;

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

events {
    worker_connections  10000;
}

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"';

    log_format  main_ext  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for" '
                          '"$host" sn="$server_name" '
                          'rt=$request_time '
                          'ua="$upstream_addr" us="$upstream_status" '
                          'ut="$upstream_response_time" ul="$upstream_response_length" '
                          'cs=$upstream_cache_status' ;

    access_log  /var/log/nginx/access.log  main_ext;
    error_log  /var/log/nginx/error.log warn;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

site é definido da seguinte maneira:

server {
        listen 80;
        listen [::]:80;

        server_name some.org www.some.org;

        location / {
                rewrite ^ https://$host$request_uri? permanent;
        }
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name some.org www.some.org;

        index index.php index.html index.htm;

        root /var/www/html;

        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/some.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/some.org/privkey.pem;

        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header Referrer-Policy "no-referrer-when-downgrade" always;
        add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
        # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        # enable strict transport security only if you understand the implications

        location / {
                proxy_connect_timeout 600;
                proxy_send_timeout    600;
                proxy_read_timeout    600;
                proxy_redirect        off;
                proxy_pass http://wordpress;

                proxy_set_header      X-Real-IP $remote_addr;
                proxy_set_header      X-Forwarded-Proto https;
                proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header      Host $host;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }

        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }

        location ~* \.(css|js|gif|ico|jpeg|jpg|png)$ {
                expires max;
                log_not_found off;
        }
}

A pilha inteira funciona conforme o esperado, a menos que 10 a 15 usuários acessem o site e tentem executar ações. Nesse caso, algumas solicitações começam a travar (geralmente é a mesma solicitação POST para algum componente) e após 3-4 minutos está sendo lançado sem nenhum erro e o usuário pode realmente ver o resultado disso. Durante o congelamento, o site não se responsabiliza pelo mesmo navegador (mas por outros está tudo bem!). Assim que a solicitação for liberada - o site será responsável novamente.

Os registros também são bem estranhos:

  • Uma vez que a solicitação suspensa/pendente chega ao servidor, ela é exibida nos logs de acesso do nginx, mas não nos logs do wordpress
  • Depois que a solicitação é finalmente liberada (ou seja, tratada), ela é exibida pela segunda vez nos logs de acesso do nginx e nos logs do wordpress, mas os tempos são diferentes

registros de acesso nginx:

62.96.39.243 - - [17/Jan/2020:10:56:41 +0000] "GET /something

78.43.40.52 - - [17/Jan/2020:10:56:41 +0000] "POST /ajax-bidsform.html?meth=post&yid=d7f9f1a1a0bf HTTP/2.0" 200 208 "https://some.org/xchange_XRP_to_SBERRUB/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36" "-"

78.43.40.52 - - [17/Jan/2020:10:56:41 +0000] "GET /something

wordpress:

134.19.130.91 - - [17/Jan/2020:10:56:40 +0000] "GET /something

78.43.40.52 - - [17/Jan/2020:10:50:07 +0000] "POST /ajax-bidsform.html?meth=post&yid=d7f9f1a1a0bf HTTP/1.0" 200 559 "https://some.org/xchange_XRP_to_SBERRUB/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36"

62.96.39.243 - - [17/Jan/2020:10:56:41 +0000] "GET /something

Como você pode ver, o travamento POST /ajax-bidsform.html...tem horário de 10h56 nos logs do nginx, mas 10h50 no wordpress - e esse é exatamente o horário em que essa solicitação foi feita pelo cliente. Pelo que entendi, isso significa que a solicitação ficou presa em algum lugar no nível nginx por quase 6 minutos até ser passada para o wordpress. Como você pode ver, não tenho diretivas de proteção ddos ​​do nginx.

Além disso, algumas observações da minha parte: durante as solicitações suspensas, não há picos de CPU ou RAM de longo prazo, portanto, provavelmente não está relacionado a problemas de hardware. Eu também estava pensando que isso está de alguma forma relacionado ao script suspenso (ou seja ajax-bidsform.html), mas começou a acontecer somente quando migramos para a instância de nuvem do digital-ocean da hospedagem virtual (onde isso nunca aconteceu antes), então acho que é um problema de configuração. A linha do tempo das solicitações nos logs também é uma prova disso.

Até agora eu tentei:

  1. Aumentar worker_connectionspara 10.000
  2. Aumente a instância do nginx (não a do host) net.core.somaxconnpara 1024

Mas o problema ainda está acontecendo. Qualquer ideia ou pensamento seria muito apreciado!

Responder1

10:56 nos logs do nginx, mas 10:50 no wordpress

Eu interpretaria isso como o wordpress recebendo a solicitação às 10h50 e retornando o resultado ao nginx às 10h56. Para ter certeza, você pode adicionar upstream_response_timeno log_formatnginx. VerUsando o registro NGINX para monitoramento de desempenho de aplicativos.

informação relacionada