Puncte:0

Utilizarea 100% a procesorului de la iowait cauzată de Nginx, nerezolvată prin activarea sendfile și dezactivarea direcției

drapel us

Rulez un serviciu web care efectuează câteva operațiuni de bază de procesare a imaginilor.

Serverul web acceptă mai întâi încărcările de imagini de la utilizatori și le stochează temporar. Un server backend descarcă apoi imaginea printr-o solicitare HTTP get și realizează procesarea propriu-zisă. Apoi este trimis înapoi la serverul web. Apoi utilizatorul descarcă imaginile. Imaginea procesată este de obicei semnificativ mai mare decât imaginea originală.

Serviciul web întâmpină ocazional vârfuri iowait cu o utilizare ridicată a procesorului și serverul dă o eroare de timeout indisponibilă a cererii. Iowait-ul ridicat este de la nginx.

Soluția dată pentru probleme similare recomandă pornirea sendfile și dezactivarea direcției. am si eu a dezactivat buffer-ul și request_buffers din moment ce am citit că și asta ar putea fi o sursă de problemă. Deși acest lucru pare să reducă oarecum apariția problemei, se întâmplă totuși sporadic și nu am idee de ce.

Mi-am copiat fișierele de configurare de mai jos. Are cineva recomandări despre ce altceva trebuie schimbat? Problema mă înnebunește cu adevărat.

Server {
     dacă ($http_user_agent ~ ^$){
        întoarce 503;
    }

    dacă ($http_user_agent ~* „Mozilla/4.0\ \(compatibil;\ MSIE\ 6.0;\ Windows\ NT\ 5.1;\ SV1;\ .NET\ CLR\ 1.1.4322;\ .NET\ CLR\ 2.0.50727\ )") {
        întoarce 503;
    }


    nume_server [exprimat: site];

    access_log /var/log/[redactat: fișier jurnal];
    error_log /var/log/[redactat: fișier jurnal];

    asculta 0.0.0.0:443 ssl; 
    ssl_certificate [exprimat: adresa certificat]
    ssl_certificate_key [redactat: cheie cert]
    includ /etc/letsencrypt/options-ssl-nginx.conf; # gestionat de Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # gestionat de Certbot

    pagina de eroare 502 /custom_502.html;
    locație = /custom_502.html {
        root /usr/share/nginx/html;
        intern;
        }
    locație = /error_502.png {
        root /usr/share/nginx/html;
    }
    client_max_body_size 300M;
    proxy_request_buffering dezactivat;


    Locație / {
                # trimite cererile de aplicație către serverul gunicorn
                proxy_pass http://localhost:8001;
                proxy_redirect dezactivat;
                proxy_set_header Gazdă $gazdă;
                proxy_set_header X-Real-IP $adresă_la distanță;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        locație /static {
                
                proxy_max_temp_file_size 0;
                directio off;
                sendfile activat;
                alias [exprimat: locație site]/static;
                expiră 5d;
        }

}


Server {
      dacă ($http_user_agent ~ ^$){
        întoarce 503;
    }

    dacă ($http_user_agent ~* „Mozilla/4.0\ \(compatibil;\ MSIE\ 6.0;\ Windows\ NT\ 5.1;\ SV1;\ .NET\ CLR\ 1.1.4322;\ .NET\ CLR\ 2.0.50727\ )") {
        întoarce 503;
    }

  dacă ($gazdă = [exprimat: adresa]) {
        returnează 301 https://$host$request_uri;


    asculta 0.0.0.0:80;
    nume_server [exprimat: site]; 
    întoarce 404;     
    client_max_body_size 300M;

}

                                                       

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.