Nginx + o servidor ubuntu do apache2 caiu com várias centenas de visitantes

Question

Eu tenho o servidor Linode 768MB RAM no Linode. E eu tenho o blog Wordpress. No meu servidor instalei o ubuntu, o nginx como frontend e o apache2 como backend. E eu tenho módulos APC e memcache. Às vezes o site está falhando. Mas o uso de CPU do servidor é menor do que os níveis críticos (apenas no máximo 60-70). No entanto, durante o travamento do site, posso ver os níveis críticos de uso de E / S do disco rígido. Eu li que isso pode estar relacionado a configurações incorretas do mysql.

Meu nginx.conf:

worker_processes 2;
events {
    worker_connections  1024;
    # multi_accept on;
}
http {
    sendfile        on;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  12;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Meu nginx proxy.conf:

proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    10m;
client_body_buffer_size 128k;
#client_header_buffer_size 64k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffer_size   16k;
proxy_buffers       32   16k;
proxy_busy_buffers_size 64k;

Meu site nginx conf:

server {
        listen   80;
        server_name mysite.org;

        location / {
                proxy_pass  http://127.0.0.1:8080;
                include     /etc/nginx/conf.d/proxy.conf;
                root   /home/mysite/www/;
                index  index.html index.htm index.php;
        }

        location ~* ^.+\.(jpg|jpeg|cur|flv|avi|gif|png|ico|zip|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf)$ {
            root   /home/mysite/www/;
        }

        location ~* ^.+\.(htm|html|js|htc|css|tgz|gz|rar|bz2)$ {
           root   /home/mysite/www/;
           gzip_static on;
       }

My.cnf

#
# * Fine Tuning
#
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
query_cache_size        = 16M

Hardware:

cpu (4x): Intel(R) Xeon(R) CPU L5520  @ 2.27GHz, 2260 MHz 
storage: Xen Virtual Storage 0, Xen Virtual Storage 1
memory: 768mb

Apache conf:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>
<IfModule mpm_worker_module>
    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>
<IfModule mpm_event_module>
    StartServers          2
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Links de estatísticas do Linode: link e link

Como posso otimizar minhas configurações de nginx + apache2 + mysql para evitar downs de sites? Obrigado ..

    

Answer 1

Eu tive esses problemas e consertei por algumas afinações no apache e no mysql

"upstream timed out" error in nginx

ou

INFO: task: apache2 (or mysql or nginx) blocked for more than 120 seconds.

esse problema ocorrerá quando o uso do recurso do apache for tão alto e indisponível. Se o mysql não responder rápido e atrasar a resposta às consultas, o apache aumentará seus níveis e sua memória ficará cheia e ... BoooOOM

o seu maior problema é o MYSQL e uma maneira fácil de corrigi-lo é instalar o aplicativo mysqltuner e fazer recomendações que

você precisará ajustar seu apache no segundo passo também! primeiro use "top" ou algo similar (em tráfego pesado no servidor) e encontre o encadeamento ativo máximo do tamanho do apache em mb. agora você deve levar o restante do servidor livre para o apache configurando MaxClients

por exemplo, se o seu ram for 12 e o seu mysql tiver 5 GB de ram - e o tamanho máximo do apache que encontrar for de cerca de 70mb, configure o MaxClients em 70 ~ 80 e deixe o resto do RAM para o OS. É tão importante que você configure seus serviços tão bem que eles não ocupam toda a memória disponível em tráfegos pesados!

    

Answer 2

Você precisa identificar a causa real da E / S do disco, em vez de apenas adivinhá-la. A primeira etapa é usar os dados históricos coletados por sar (se você não instalou sysstat em sua máquina e ajustou-a para coletar dados a cada minuto, faça isso '' 'now' ''). Procure por trocar primeiro e acima de tudo; o volume usado e as páginas de entrada / saída são potencialmente úteis.

Se a troca não parecer ser o caso, verifique qual dispositivo de bloco tem o problema de E / S de disco. Isso ajudará a restringir qual parte do sistema provavelmente está causando a E / S do disco, se você tiver várias partições.

Se você conseguir detectar o problema em ação, executar iotop pode ser realmente útil para identificar o processo ofensivo. Sua desvantagem é que executá-lo de forma não interativa é uma praga, porque para obter dados úteis você realmente precisa pesquisar a cada segundo, e gravar tudo isso em disco pode causar E / S de disco suficiente para deixar sua máquina submersa ainda mais rápido. / p>

Uma vez que você descobriu quem é o infrator, você precisa consertá-lo. Se o MySQL é, de fato, o culpado, então sim, você precisará ajustá-lo. Eu não vou entrar em um artigo detalhado sobre o ajuste do MySQL, já que a Internet (e este site) já está cheia deles. Basta dizer que, sim, os parâmetros padrão do MySQL são uma porcaria completa e você sempre precisa ajustar seu banco de dados.

Alguns pontos gerais da sua configuração:

• A execução do nginx e do Apache é desnecessária, desperdiça memória e, portanto, não estará ajudando em um problema de troca ou um problema geral de E / S de disco (porque haverá menos memória disponível para o cache de disco). Livre-se do Apache e execute o php-fpm (ou FCGI PHP da velha escola) para servir seu conteúdo dinâmico.
• A E / S de disco do Linode é geralmente muito ruim (acabamos de migrar um grande cliente da Linode, em parte porque o disco I / O disponível era tão ruim que estava causando problemas de desempenho). Se você realmente vai estar fazendo uma quantidade razoável de tráfego, você deve ser capaz de ter uma classe melhor de VPS.