Desaceleração inexplicável do servidor

Question

Desculpas pelo título vago do tópico, resumindo o seguinte, mostrou-se um pouco complicado, afinal ele é, como intitulado, inexplicado. De qualquer forma, desculpas suficientes ...

Esta manhã, descobri que o meu site está a ficar extremamente lento, o que não acontece normalmente, pelo que estou obviamente a tentar descobrir a causa do problema. Sabendo que eu não instalei ou mudei nada recentemente, meu primeiro ponto de partida foi verificar as estatísticas de uso de recursos, que não mostram nada fora do comum:

load average: 0.35, 0.34, 0.36

Verificar isto durante um período de cerca de meia hora (durante o qual as interrupções de tempo foram relatadas pelos usuários) nunca mostra nada acima de 1. Portanto, não é "carga tradicional". Então, estou procurando outras causas possíveis.

Top também não mostra nada fora do comum:

top - 08:34:34 up  1:33,  1 user,  load average: 0.30, 0.36, 0.35               
Tasks: 146 total,   1 running, 145 sleeping,   0 stopped,   0 zombie            
Cpu0  :  6.6%us,  1.3%sy,  0.0%ni, 91.1%id,  0.7%wa,  0.0%hi,  0.3%si,  0.0%st  
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 99.3%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st  
Cpu2  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st  
Cpu3  :  0.3%us,  0.3%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st  
Mem:   4016884k total,  1367624k used,  2649260k free,     5324k buffers        
Swap:  3919840k total,        0k used,  3919840k free,   769024k cached         

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 2593 apache    15   0  446m  66m  40m S  7.6  1.7   1:13.64 httpd              
 2450 mysql     15   0  257m  48m 5976 S  0.3  1.2   4:20.51 mysqld             
 9734 root      15   0 12740 1296  932 R  0.3  0.0   0:00.24 top                
    1 root      18   0 10348  752  628 S  0.0  0.0   0:04.91 init               
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0        
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0        
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0         
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/1      

Então eu comecei a olhar para a rede, o seguinte comando (que eu tirei de uma pergunta SF sobre ataques DDOS):

netstat -n | grep: 80 | corte -c 45- | corte -f 1 -d ':' | ordenação | uniq -c | ordenar -nr | mais

Dá:

534
  5     1.1.1.1
  4     2.2.2.2
  4     3.3.3.3
  3     4.4.4.4
  2     5.5.5.5
  2     6.6.6.6
  2     7.7.7.7
  1     8.8.8.8
  1     9.9.9.9
  1     10.10.10.10
  1     11.11.11.11

Endereço IP editado

Também não parece haver nada fora do comum, embora eu não tenha certeza do que isso significa. Para uma boa medida eu também reiniciei o servidor (força de hábito depois de usar o Windows por tanto tempo;)), mas isso não fez qualquer diferença.

Então, agora eu me vejo perdido, não consigo explicar o que está acontecendo aqui e isso, claro, significa que não posso consertar isso.

Detalhes do servidor Este é um servidor dedicado com as seguintes especificações:

• Processador AMD Opteron (tm) Quad-Core 1381
• 4 GB de RAM

Esta página PHP do servidor do site (somente vbulletin) via Apache com um backend MySQL, também estou executando o APC como opcode cacher.

EDITAR - Mais informações Pode ou não ser útil ...

Usando o Firebug no Firefox Estive observando os tempos de carregamento das páginas. O que parece estar acontecendo é que um recurso aleatório (às vezes uma imagem, um arquivo JS ou um arquivo CSS) leva uma quantidade excessiva de tempo para concluir o recebimento. A solicitação é concluída em questão de milissegundos, mas o recebimento às vezes leva mais de um minuto. No entanto, é um recurso aleatório, cada pedido que faço tem um recurso diferente que demora muito para voltar. Eu não tenho nenhum caching etc. para esses recursos, eles são servidos normalmente através do apache do sistema de arquivos.

EDITAR Saída do iostat:

Linux 2.6.18-164.11.1.el5 12/10/2010      

avg-cpu:  %user   %nice %system %iowait  %steal   %idle                         
           4.66    0.00    2.08    0.84    0.00   92.42                         

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn          
sda              12.48        78.48       144.52    1008089    1856500          
sda1              0.43         2.52         6.95      32354      89224          
sda2              0.01         0.11         0.00       1356          0          
sda4              0.00         0.00         0.00         10          0          
sda5              0.48         5.33         1.61      68413      20706          
sda6             11.57        70.51       135.97     905732    1746570          
sdb              12.43        78.57       144.52    1009340    1856500          
sdb1              0.43         2.24         6.95      28768      89224          
sdb2              0.00         0.08         0.00       1068          0          
sdb4              0.00         0.00         0.00         10          0          
sdb5              0.45         5.35         1.61      68729      20706          
sdb6             11.53        70.88       135.97     910533    1746570          
md1               0.91         4.72         5.96      60666      76520          
md6              14.70       141.37       126.26    1815945    1621898          
md5               0.57        10.65         1.05     136822      13474  

EDITAR

Pode ser útil se eu der a vocês a URL do site:

link

    

Answer 1

Bem, se o problema acontecer com arquivos estáticos, é bom, porque pelo menos você sabe começar a procurar pelo Apache. Você provavelmente vai querer quebrar as ferramentas de depuração e criação de perfil para ver exatamente o que está errado. Supondo que você esteja falando sobre um sistema Linux, strace é provavelmente a ferramenta que você deseja. Com as opções -f e -c , ele seguirá todos os processos filho bifurcados e resumirá a quantidade de tempo gasto em cada syscall. Isso deve ajudá-lo a descobrir o problema.

Pare o Apache e reinicie-o através do strace:

strace -cf /usr/sbin/httpd

(o strace tem uma opção -p para rastrear o pid de um processo existente, mas mesmo com -f ele não rastreia processos filhos que foram bifurcados antes do strace ser chamado.)

Deixe-o funcionar por algum tempo, bata no site enquanto ele está em execução até que você possa acionar a lentidão algumas vezes e interrompê-lo. Analise os resultados.

Se o problema estiver no código do aplicativo em modo usuário, e não em algo que o sistema esteja fazendo, existe um programa chamado ltrace que pode ser usado para resumir o tempo gasto em várias chamadas à biblioteca compartilhada. / p>

Provavelmente, é desnecessário, mas também verificar seus logs do servidor, do sistema e do kernel para garantir que você não esteja vendo falhas inesperadas ou eventos de hardware.

    

Answer 2

Quais medidas você adotou para descartar uma questão do cliente? A carga mínima do servidor e a latência intermitente de solicitações aleatórias de recursos me faria querer excluir um verificador de arquivos em tempo real como o culpado. Isso pode estar errado, mas deve ser trivial descartar.