o servidor trava sob alta carga

Question

Estamos executando uma configuração que recebeu muita atenção da mídia nos dias de hoje e esperamos que o tráfego continue. Temos 1 balanceador de carga haproxy, 3 servidores de aplicativos (2 imagens, 1 geral) e um servidor de banco de dados. O balanceador de carga leva toda a carga e redireciona com base no URL. O problema é que nosso aplicativo falha ou tem um tempo de resposta muito baixo a cada 10 minutos (nas imagens, quando o gráfico cai). Vocês sabem o que está errado? Se você precisar de mais informações, forneça-o.

configuração haproxy:

global
    log /dev/log  local0
    log /dev/log  local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon


defaults
    log global
    mode  tcp
    option  tcplog
    option  dontlognull
        contimeout 5000
        clitimeout 50000
        srvtimeout 50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http


frontend http
    bind *:80
    mode    http
    option  forwardfor

    acl content_php path_end getImage.php
    acl getMedia path_end getMedia.php

    use_backend getImage if content_php
    use_backend getImage if getMedia

    default_backend backend


frontend monitoring
    bind *:1234
    mode http
    stats enable
    stats uri /
    stats auth gobi:dlkjaDSgasd

backend backend
    mode    http
    option  forwardfor
    balance source
    option  httpclose
    server  app1 10.129.75.237:80 check

backend getImage
    mode    http
    option  forwardfor
    balance roundrobin
    option  httpclose

    server  image1 10.129.62.139:80 check
    server  image2 10.129.63.146:80 check

loadBalancer: servidordebancodedados: generalServer: imageServer1: imageServer2:

    

Answer 1

Então descobrimos o problema. Era, como muitas vezes é, o servidor de banco de dados. Nós tivemos 2 problemas:

1) Nós tivemos uma consulta mysql que usava três junções. Acontece que esta função estava falhando Mysql. Nós reescrevemos esta consulta para usar 4 consultas mysql sem junções e isso resolveu o problema. (Um pouco de hot-fix, provavelmente vamos reescrever a função para que seja possível armazená-la em cache).

2) Estávamos experimentando cerca de 99,9% de espera de E / S quando usamos apenas 10% de cache link . Nós tentamos editar a configuração do mysql (citado na parte inferior). Isso ajudou muito, mas não resolveu o problema. Acontece que outro usuário no servidor compartilhado estava causando 99,8% de picos de E / S. Depois de entrar em contato com o provedor do nosso servidor, eles mudaram o servidor para outra partição e o problema foi resolvido.

table_open_cache = 1024 
sort_buffer_size = 4M 
read_buffer_size = 128k 
query_cache_size= 128M 
query_cache_type = 1 
tmp_table_size = 64M 
thread_cache_size = 20 
innodb_buffer_pool_size = 512M 
innodb_additional_mem_pool_size = 20M 
innodb_log_file_size = 64M 
innodb_log_buffer_size = 8M 
innodb_file_per_table innodb_file_format = Barracuda

    

Answer 2

Essa lentidão pode ser devido ao esgotamento das portas tcp devido ao pico de conexões estabelecidas aguardando a resposta do servidor de aplicativos (talvez usando o banco de dados também ou fazendo solicitações a outros servidores). Nesse cenário, o servidor de aplicativos pode ter 2 (ou mais) abrir portas para cada solicitação.

Entretanto verifique as páginas de erro configuradas no nginx, é melhor ter um html estático para 500 erros, mas faça sua aplicação falhar rapidamente para fornecer o erro o mais rápido possível evitando cálculos desnecessários.

Por exemplo, tenha cuidado com o formulário de contato por e-mail, se os campos não forem devidamente validados e submetidos à camada de aplicativo para computação e persistência no banco de dados, não se esqueça de abrir essas conexões após validar seus dados.

Depois disso, aumente seu net.core.somaxconn=2048 e ative a porta net.ipv4.tcp_tw_reuse=1 com a ferramenta de configuração sysctl .