Nosso servidor ocasionalmente se recusa a servir uma página HTML simples.
Isso está acontecendo durante um número relativamente alto de solicitações. No entanto, o processador não está muito carregado e há muita memória livre. O erro parece ocorrer em média em 1 em 50 solicitações, dependendo da carga do servidor.
Preciso encontrar a origem do problema e tomar as medidas adequadas para eliminá-lo.
Suspeito que a origem do problema seja um grande número de pacotes de rede recebidos. Existem 5.000 pacotes por segundo em média. Tráfego - 2 MBits/seg Essa pode ser a causa do erro?
Há uma coisa interessante, caso o servidor não responda, a string de solicitação não é registrada em access.log pelo Apache.
O erro pode ser repetido em vários computadores clientes. O DNS não está envolvido, pois acessei o servidor pelo IP.
Criei um perfil do caso do problema com o utilitário tcpdump. Estas são as sessões boas e ruins rastreadas pelo tcpdump. A solicitação é a mesma em ambos os experimentos. Bom - o servidor retorna resposta. Ruim - sem resposta, erro de tempo limite.
---- Bad ----
12:23:36.366292 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:23:39.362394 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:23:45.365567 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,nop,sackOK>
--------
---- Good ----
12:27:07.632229 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:27:10.620946 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:27:10.620969 IP myserver.superbservers.com.www > 123.45.67.890.63914: S 2654770980:2654770980(0) ack 3581365571 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
12:27:10.838747 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 1 win 4380
12:27:10.957143 IP 123.45.67.890.63914 > myserver.superbservers.com.www: P 1:213(212) ack 1 win 4380
12:27:10.957152 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 213 win 108
12:27:10.965543 IP myserver.superbservers.com.www > 123.45.67.890.63914: P 1:630(629) ack 213 win 108
12:27:10.965621 IP myserver.superbservers.com.www > 123.45.67.890.63914: F 630:630(0) ack 213 win 108
12:27:11.183540 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 631 win 4222
12:27:11.185657 IP 123.45.67.890.63914 > myserver.superbservers.com.www: F 213:213(0) ack 631 win 4222
12:27:11.185663 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 214 win 108
--------
Hoster: SuperbHosting
SO: Ubuntu
Parâmetros do servidor: E6300 CONROE 1.86GHZ 2 X 1MB CACHE 1066 1GB DDR2 667MHZ
Este é um link para o arquivo de configuração do Apache que usamoshttp://repkin5.snow.prohosting.com/apache.txt
Este é o relatório de status do servidor obtido logo após o erro de tempo limite.http://repkin5.snow.prohosting.com/server-status.htmExistem apenas 10 Servidores Filhos em execução em 120, portanto há espaço suficiente para novas solicitações.
VMSTAT
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 8900 725900 8468 65684 0 0 5 18 11 33 4 3 92 1
Responder1
- Há uma coisa interessante, caso o servidor não responda, a string de solicitação não é registrada em access.log pelo Apache.
Isso parece um problema de rede. O servidor deve registrar todas as solicitações recebidas, mesmo que não possa responder por algum motivo. Você pode querer verificar se não está vendo perda de pacotes no servidor web.
Responder2
Há uma pequena chance de você estar em uma posição em que os buffers de kernel disponíveis para conexões TCP sejam baixos. Eu esperaria algum registro disso (faça login no servidor, teste até obter uma "sem resposta" e, em seguida, execute dmesge veja se algo parece aplicável).
Para ajustar a configuração da rede,este pode ser um ponto de partida.
Como disse Chris Nava, provavelmente vale a pena ter certeza de que você não está apenas tendo perda de pacotes na rede, então comece a verificar usando ping (responder a um ping, infelizmente, não é a mesma coisa que lidar com um pacote TCP ).