O verniz 3.0.2 para o Apache2 às vezes retorna o erro 503

3

Olá pessoal, espero que você possa me ajudar aqui.

Eu tenho um Ngingx parsing http e https para um cache de verniz (3.0.2). Do verniz é enviado para o apache2. Agora, há algum tempo, acompanho alguns erros estranhos do 503. Mas eu não consigo encontrar a bala de prata.

Atualmente, estou registrando os erros do 503 por meio do verniz dessa maneira:

sudo varnishlog -c -m TxStatus:503 >> /home/rj/varnishlog503.log

e, em seguida, referindo-se ao log de acesso do apache para ver se alguma solicitação 503 foi tratada.

Hoje tive uma verificação de integridade do firewall que falhou:

20 SessionOpen  c 127.0.0.1 34319 :8081
20 ReqStart     c 127.0.0.1 34319 607335635
20 RxRequest    c HEAD
20 RxURL        c /health-check
20 RxProtocol   c HTTP/1.0
20 RxHeader     c X-Real-IP: 192.168.3.254
20 RxHeader     c Host: 192.168.3.189
20 RxHeader     c X-Forwarded-For: 192.168.3.254
20 RxHeader     c Connection: close
20 RxHeader     c User-Agent: Astaro Service Monitor 0.9
20 RxHeader     c Accept: */*
20 VCL_call     c recv lookup
20 VCL_call     c hash
20 Hash         c /health-check
20 VCL_return   c hash
20 VCL_call     c miss fetch
20 Backend      c 33 aurum aurum
20 FetchError   c http first read error: -1 11 (No error recorded)
20 VCL_call     c error deliver
20 VCL_call     c deliver deliver
20 TxProtocol   c HTTP/1.1
20 TxStatus     c 503
20 TxResponse   c Service Unavailable
20 TxHeader     c Server: Varnish
20 TxHeader     c Content-Type: text/html; charset=utf-8
20 TxHeader     c Retry-After: 5
20 TxHeader     c Content-Length: 879
20 TxHeader     c Accept-Ranges: bytes
20 TxHeader     c Date: Wed, 06 Jun 2012 12:35:12 GMT
20 TxHeader     c X-Varnish: 607335635
20 TxHeader     c Age: 60
20 TxHeader     c Via: 1.1 varnish
20 TxHeader     c Connection: close
20 Length       c 879
20 ReqEnd       c 607335635 1338986052.649786949 1338986112.648169994 0.000160217 59.997980356 0.000402689

Agora, o servidor de back-end (apache) não possui nenhum erro 503 no log de acesso neste momento. Então estou confuso. Este verniz está jogando um 503 porque acha que o apache é lento? Há muito tráfego chegando neste momento, então sei que o servidor está funcionando.

Eu tenho outros 503 códigos de erro com posts e fica assim não há realmente nenhum padrão. Parece ser em momentos aleatórios e solicitações aleatórias. Mesmo de manhã, quando o servidor não parece estar fazendo nada.

Eu vejo outro padrão no log:

4 VCL_call     c recv pass
4 VCL_call     c hash
4 Hash         c /?id=412
4 VCL_return   c hash
4 VCL_call     c pass pass
4 FetchError   c no backend connection
4 VCL_call     c error deliver
4 VCL_call     c deliver deliver

Aqui fetcherror diz "sem conexão backend". Um verão dos FetchErrors no log de hoje:

16 FetchError   c http first read error: -1 11 (No error recorded)
 5 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
19 FetchError   c http first read error: -1 11 (No error recorded)
 5 FetchError   c http first read error: -1 11 (No error recorded)
23 FetchError   c http first read error: -1 11 (No error recorded)
24 FetchError   c http first read error: -1 11 (No error recorded)
16 FetchError   c http first read error: -1 11 (No error recorded)
 6 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
 5 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
 4 FetchError   c http first read error: -1 11 (No error recorded)
22 FetchError   c http first read error: -1 11 (No error recorded)
 6 FetchError   c http first read error: -1 11 (No error recorded)
21 FetchError   c http first read error: -1 11 (No error recorded)
26 FetchError   c no backend connection
 4 FetchError   c no backend connection
20 FetchError   c http first read error: -1 11 (No error recorded)
39 FetchError   c http first read error: -1 11 (No error recorded)

Eu não alterei os valores de tempo limite padrão para o verniz. Esta é a minha configuração para um dos servidores de backend.

backend xenon {
    .host = "192.168.3.187";
    .port = "80";
    .probe = {
        .url = "/health-check/";
        .interval = 3s;
        .window = 5;
        .threshold = 2;
    }
}

Estou executando o módulo prefork no apache2 com esta configuração

<IfModule mpm_prefork_module>
    StartServers          1
    MinSpareServers       2
    MaxSpareServers       5
    MaxClients           200
    MaxRequestsPerChild  75
</IfModule>

e somente arquivos PHP são enviados para o servidor. Todos os outros arquivos estáticos são manipulados pelo Nginx.

Alguma idéia?

------- EDITAR --------------

Mais algumas informações de depuração

Eu executei um debug.health de varnishadm

Backend radon is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.002560
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
Backend xenon is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.002760
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
Backend iridium is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.000849
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
Backend aurum is Healthy
Current states  good:  5 threshold:  2 window:  5
Average responsetime of good probes: 0.002100
Oldest                                                    Newest
================================================================
4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

E eu tenho monitorado o varnishstat dos dois balanceadores de carga

 3224774         3.99         2.61 backend_conn - Backend conn. success
      27         0.00         0.00 backend_unhealthy - Backend conn. not attempted
      63         0.00         0.00 backend_fail - Backend conn. failures
  358798         0.00         0.29 backend_reuse - Backend conn. reuses
   21035         0.00         0.02 backend_toolate - Backend conn. was closed
  379834         0.00         0.31 backend_recycle - Backend conn. recycles
      26         0.00         0.00 backend_retry - Backend conn. retry

3217751         5.99         2.61 backend_conn - Backend conn. success
      32         0.00         0.00 backend_fail - Backend conn. failures
  364185         0.00         0.30 backend_reuse - Backend conn. reuses
   27077         0.00         0.02 backend_toolate - Backend conn. was closed
  391263         0.00         0.32 backend_recycle - Backend conn. recycles
      36         0.00         0.00 backend_retry - Backend conn. retry

Observe que nenhum deles relatou backend_fail.

/ Ronnie

    
por Ronnie Jespersen 06.06.2012 / 15:04

4 respostas

0

Se este é um servidor ocupado, o que eu suponho é que você declara "Há muito tráfego chegando neste ponto para que eu saiba que o servidor está funcionando" Você avaliou primeiro sua configuração do apache para poder lidar com o fluxo de tráfego? E segundo você está usando nginx para solicitações de proxy para verniz, você definiu um valor de repetição para as solicitações? Por exemplo, ao usar o apache proxypass, você pode fazer algo assim

ProxyPass / http://192.1.1.11:9001/ retry=3 timeout=5

Isso fará com que o proxy não tente novamente para essas solicitações. Encontre o equivalente a isso para o nginx. Isso pode ajudar a atenuar a quantidade de 503s, no entanto, se for um problema de tráfego, você precisará resolver isso. Além disso, você pode considerar o haproxy em vez do nginx como proxy dessa maneira, já que é para isso que ele é feito.

    
por 11.04.2014 / 21:25
0

Eu estava correndo para isso com o Apache, e a solução foi uma combinação dos seguintes (note que estou usando o Apache / 2.4.7 (Ubuntu) + verniz 3.0.5-2 no Ubuntu 14.04 LTS no AWS EC2) :

Tenha em mente que isso foi feito para uma instância M3.Medium no Amazon EC2 (1x Intel Xeon E5-2670 core + 3.75GB RAM). Ajuste conforme necessário para o seu hardware!

  1. Em /etc/default/varnish , edite suas opções de inicialização:

     DAEMON_OPTS="-a :80 \
         -T localhost:6082 \
         -f /etc/varnish/default.vcl \
         -S /etc/varnish/secret \
         -p thread_pools=2 \
         -p thread_pool_max=600 \
         -p listen_depth=1024 \
         -p lru_interval=900 \
         -p connect_timeout=600 \
         -p max_restarts=6 \
         -s malloc,1G"
    
  2. Em /etc/varnish/default.vcl ou qualquer que seja seu VCL, altere os tempos limite de back-end (observe que também os definimos em / etc / default / verniz):

    backend default {
        .host = "127.0.0.1";
        .port = "8000";
        .connect_timeout = 600s;
        .first_byte_timeout = 600s;
        .between_bytes_timeout = 600s;
    }
    
  3. Desative KeepAlives. Esta página tem mais informações (varia de acordo com o software back-end do servidor da Web): link

Para o Apache, tudo o que precisei fazer foi alterar a linha 92 em /etc/apache2/apache2.conf para o seguinte:

    KeepAlive Off

O que eu acho que está acontecendo aqui é que os KeepAlives, como implementados no software de servidor web de back-end, estão enviando reinicializações de conexão explícitas, com as quais o Varnish não funciona bem. Há provavelmente mais nessa história, e eu encorajo você a investigar isso e publicar suas descobertas aqui para as gerações futuras aprenderem.

Leitura adicional: - link (e mais alguns, mas não podem postar os links. Alguns pesquisando por "tempo limite de back-end do keepalive de verniz" devem mostrar o que você deseja)

Mais ajuda de depuração: Se você ainda estiver preso, tente fazer o seguinte: - inicie varnishlog -w err.log no seu servidor Varnish - No seu cliente, obtenha o Siege: link e carregue-o com alguns dos URLs que você viu 503 (dica : urls.txt, use -i -b -c500 -r10 e deve ser o suficiente para acionar os 503s) - inicie varnishlog -r temp -c -m 'TxStatus:503' > err-parsed.txt . Isto irá pegar todas as entradas de log do Varnish onde o Varnish retornou um 503. FWIW, aqui está o texto completo de um dos meus erros. TL; DR o erro que o Varnish estava reportando era FetchError c http first read error: -1 0 (Success) :

936 SessionOpen c 10.8.226.98 51895 :80 936 ReqStart c 10.8.226.98 51895 357447130 936 RxRequest c GET 936 RxURL c /ip/69.120.68.54 936 RxProtocol c HTTP/1.1 936 RxHeader c Host: 10.201.81.157 936 RxHeader c Accept: */* 936 RxHeader c Accept-Encoding: gzip 936 RxHeader c User-Agent: Mozilla/5.0 (apple-x86_64-darwin11.4.2) Siege/3.0.5 936 RxHeader c Connection: close 936 VCL_call c recv lookup 936 VCL_call c hash 936 Hash c /ip/69.120.68.54 936 Hash c 10.201.81.157 936 VCL_return c hash 936 HitPass c 357445183 936 VCL_call c pass pass 936 Backend c 103 default default 936 FetchError c http first read error: -1 0 (Success) 936 Backend c 269 default default 936 FetchError c http first read error: -1 0 (Success) 936 VCL_call c error deliver 936 VCL_call c deliver deliver 936 TxProtocol c HTTP/1.1 936 TxStatus c 503 936 TxResponse c Service Unavailable 936 TxHeader c Server: Varnish 936 TxHeader c Content-Type: text/html; charset=utf-8 936 TxHeader c Retry-After: 5 936 TxHeader c Content-Length: 418 936 TxHeader c Accept-Ranges: bytes 936 TxHeader c Date: Thu, 05 Jun 2014 23:05:48 GMT 936 TxHeader c X-Varnish: 357447130 936 TxHeader c Age: 0 936 TxHeader c Via: 1.1 varnish 936 TxHeader c Connection: close 936 Length c 418

Espero que isso ajude!

    
por 06.06.2014 / 01:38
0

503 significa que não há back-end saudável disponível. O Apache não respondeu à sonda no tempo limite ou com 200

backend.health de varnishadm

Pode fornecer status de integridade de back-end. Esta é a razão pela qual seus logs do Apache não têm 503 logados

    
por 16.01.2017 / 05:19
0

Espero que seja um erro de digitação, mas você mencionou que não houve erros nos registros de acesso? Os erros estariam no log de erros (-: verifique lá, se ainda não o fez? O arquivo se chama error_log . Além disso, verifique seu httpd.conf para o nível do log de erros. Tente defini-lo como debug e reiniciar para ver mais detalhes nos logs de erro.Eu acredito que o padrão é warn .Note, há uma sobrecarga de desempenho com a depuração, por isso fez até que você tenha os dados necessários e defini-lo de volta para warn .

Outro item a ser considerado é aumentar / ajustar algumas das configurações do seu prefork. Se você está vendo muito tráfego "vindo, estes são muito baixos - IMO. Aqui estão os padrões no meu RHEL 6.1, apache 2.2:

<IfModule prefork.c>
    StartServers            8
    MinSpareServers         5
    MaxSpareServers        20
    ServerLimit           256
    MaxClients            256
    MaxRequestsPerChild  4000
</IfModule>

As configurações ideais dependem da sua instalação do apache e do hardware que você está executando - memória, CPUs, etc. Eu começaria aumentando os três primeiros. Consulte o Apache MPM prefork para obter mais informações sobre esses parâmetros.

    
por 06.06.2012 / 16:03