LAMP stack em 64 bits, 16 core box mastiga 100% de CPU

Question

=== RESOLVIDO ===

Este problema foi resolvido. Acontece que o ImageMagick tem problemas com várias CPUs. Compilar o ImageMagick para usar uma CPU resolveu o problema.

================

Eu adicionei um novo servidor web como uma atualização, mas ele cai em segundos.

A caixa antiga tem 8 núcleos Xeon a 2.33GHz. A nova máquina tem 16 núcleos Xeon a 2,40GHz. A memória é 8G e 32G na nova máquina.

A outra grande diferença é um salto de 32 bits para 64 bits.

O SO é o CentOS 5.6 em ambos e o Apache também é 2.2.3-45 em ambos.

PHP é 5.2.10 e compilado manualmente. as opções de configuração são idênticas, exceto pelos bits da arquitetura.

De todas essas informações, você poderia pensar que a nova máquina iria gritar, mas a caixa atual lida com a carga e cai ocasionalmente. A nova máquina morre todas as vezes em menos de um minuto.

A memória está boa, a E / S é boa, mas a CPU está atrapalhada. Aqui está a saída do mpstat de ambos

caixa antiga

09:14:18 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
09:14:20 PM  all   31.34    0.00    2.62    9.68    0.12    1.00    0.00   55.24  11163.50
09:14:20 PM    0   53.00    0.00    5.50   16.00    0.50    6.50    0.00   18.50  10249.50
09:14:20 PM    1   36.68    0.00    2.51   11.06    0.00    0.00    0.00   49.75    126.00
09:14:20 PM    2   17.41    0.00    1.99    7.96    0.00    0.00    0.00   72.64    125.50
09:14:20 PM    3   41.00    0.00    3.00    9.00    0.00    0.00    0.00   47.00    125.50
09:14:20 PM    4   30.00    0.00    2.00    7.50    0.00    0.50    0.00   60.00    143.00
09:14:20 PM    5   28.50    0.00    2.00   12.00    0.00    0.00    0.00   57.50    142.50
09:14:20 PM    6   22.61    0.00    1.51    7.54    0.00    0.00    0.00   68.34    125.50
09:14:20 PM    7   21.50    0.00    2.50    6.50    0.00    0.00    0.00   69.50    125.50

nova caixa

09:13:41 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
09:13:43 PM  all   98.69    0.00    0.81    0.00    0.03    0.47    0.00    0.00   4723.50
09:13:43 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   1000.50
09:13:43 PM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    2  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    3  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    4   98.01    0.00    1.49    0.00    0.00    0.50    0.00    0.00      0.00
09:13:43 PM    5  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    6  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    7   98.51    0.00    1.49    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    8  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    9   99.50    0.00    0.50    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   10  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   11  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   12   95.50    0.00    4.00    0.00    0.00    0.50    0.00    0.00     84.50
09:13:43 PM   13  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   14  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   15   87.56    0.00    4.98    0.00    0.50    6.97    0.00    0.00    3640.0  

O tráfego chega por meio de um balanceador de carga e é dividido em 50/50 entre os dois. Assim que ligo a nova máquina, carrego os picos para 200 e tenho que desligá-la quando ele parar de atender as solicitações.

strace contra o httpd não parece tão revelador, mas aqui está a saída de um strace -c -f -p

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 73.52    2.763912         419      6594      1663 futex
  8.65    0.325110          55      5869      4099 open
  5.35    0.201250         107      1873       381 stat
  3.12    0.117305          67      1748       165 lstat
  2.30    0.086434        2010        43           wait4
  1.64    0.061543           7      8825       769 read
  1.31    0.049158         125       394           clone
  0.77    0.028874          53       543           chdir
  0.75    0.028356          29       973           munmap
  0.34    0.012783          35       370           times
  0.30    0.011298         257        44           madvise
  0.24    0.008897           7      1312           fstat
  0.22    0.008225           1      9341         2 poll
  0.18    0.006682           2      2777        14 write
  0.14    0.005358           5      1184           mmap
  0.13    0.005020          19       262           set_robust_list
  0.13    0.004990           3      1688        30 writev
  0.13    0.004799           7       671       598 access
  0.08    0.003194           0      6531           recvfrom
  0.06    0.002404           4       673         8 sendto
  0.06    0.002398           4       578           getcwd
  0.06    0.002367           5       491           mprotect
  0.05    0.002013           4       457           brk
  0.05    0.001965           2       883           semop
  0.05    0.001924           3       760           lseek
  0.04    0.001622           2       845           setitimer
  0.04    0.001525           4       412           epoll_wait
  0.04    0.001486           1      2595           close
  0.04    0.001430           3       412           accept
  0.04    0.001429           3       433       231 connect
  0.04    0.001388           1      1185           rt_sigaction
  0.03    0.000999           2       594           rt_sigprocmask
  0.03    0.000963           0      2325           fcntl
  0.02    0.000935           1       690           setsockopt
  0.01    0.000393           1       534           socket
  0.01    0.000380           1       393        12 shutdown
  0.00    0.000158           1       127           setuid
  0.00    0.000156           0       411           getsockname
  0.00    0.000156           2        70        46 unlink
  0.00    0.000080           0       254           epoll_ctl
  0.00    0.000000           0        64           ioctl
  0.00    0.000000           0        38         6 select
  0.00    0.000000           0        10           alarm
  0.00    0.000000           0       230           getsockopt
  0.00    0.000000           0         3           rename
  0.00    0.000000           0        22           getrusage
  0.00    0.000000           0       127           setgid
  0.00    0.000000           0       254           geteuid
  0.00    0.000000           0       127           setgroups
  0.00    0.000000           0       127           epoll_create
------ ----------- ----------- --------- --------- ----------------
100.00    3.759359                 67166      8024 total

========== EDIT / UPDATE ==========

Descobri que, quando limitei o tráfego para 10% no balanceador de carga, conforme sugerido, ele ainda desmoronou. Quando eu bati nele com cerco e 400 conexões, ele se manteve muito bem. A carga aumentou, mas ficou em torno de 6 e atendeu a todas as solicitações.

Eu tenho os registros de acesso desativados, mas ativei um pouco e avisei ao balanceador de carga para começar a enviar tráfego novamente. Deixei isso correr até o load atingir 200, que foi cerca de 3 minutos e salvei o log.

Eu analisei o log para solicitações de uso com cerco. Isso me daria um benchmark mais preciso.

Com certeza, sem dados ativos, mas apenas eu acertando, aumentei o load para 200. Comecei a cortar o arquivo ao meio e testar a metade superior e inferior. Estou continuando isso até que eu possa encontrar o pedido específico ou pedidos que quebram o servidor.

Até agora, parece algo que faz uso pesado do ImageMagick, mas reduzi as solicitações de 10K GET para 50 e ainda estou indo.

    

Answer 1

Isso não vai ler tanto como uma resposta, mas como uma série de etapas para ajudar você a rastrear isso.

1. Instalar o Ganglia: link . É a minha ferramenta de solução de problemas de carga preferida. Você vai gostar.
2. Veja se você pode usar seu balanceador de carga para enviar uma porcentagem menor do tráfego, digamos 5%, para o novo servidor. Isso permitirá que seu servidor espere ficar por mais tempo.
3. Execute o topo em seu novo servidor e ordene por CPU através da chave de classificação "P". Veja o que está levando a maior parte dos ciclos.
4. Verifique todas as ligações do PHP para o MySQL e Apache e as bibliotecas estão instaladas corretamente. Este é o meu suspeito número um para o que está errado com base nas informações que você forneceu até o momento. O fato de você ter compilado manualmente seu PHP também gera uma potencial bandeira vermelha. Verifique duas vezes suas opções de configuração e verifique se nada foi alterado no que é esperado ou exigido na alteração de 32/64 bits.
5. Ative e examine os logs: php error_log e logs de erros do apache para ver o que está acontecendo. Isso é sempre informativo, mas você precisará separar o sinal do ruído em seu ambiente específico.

Um ou mais desses passos provavelmente ajudarão a entender o que está errado.

    

Answer 2

Se você mudar para os pacotes php ou php53 da sua distribuição, o alto uso da CPU ainda ocorrerá?

Se você estiver usando um cache de opcode, o alto uso da CPU ainda ocorrerá se você desativá-lo?

Se você executar uma ferramenta como o apachebench com um script PHP "hello world" simples em vez de seu aplicativo real, o uso excessivo da CPU ainda ocorrerá?

Você pode desativar os módulos PHP um por um e testar se o alto uso da CPU ainda ocorre depois que cada um deles é desativado?

Você pode usar um profiler / depurador PHP para analisar o que está acontecendo em seu aplicativo?