Não tenho certeza se tenho um problema com um vazamento de memória (como sugere minha empresa de hospedagem) ou se precisamos ler link . Talvez vocês, pessoas inteligentes, possam nos ajudar?
Esta é uma VM de front-end do servidor Web que executa essencialmente apenas nginx & php-fpm no RHEL 5.5. Este servidor está alimentando o Magento, um thinggy PHP eCommerce. O servidor está sendo executado em um ambiente compartilhado, mas estamos mudando isso em breve.
De qualquer forma .. depois de uma reinicialização, o servidor roda muito bem, mas dentro de um dia ele vai se transformar em nada. As páginas levarão literalmente 2 minutos para carregar, picos de CPU como loucos, etc. O console fica até lento quando eu faço SSH. É como se todo o meu servidor estivesse sendo derrubado.
Eu também tenho monitorado o servidor de banco de dados via tráfego de entrada top e tcpdumping. O DB permanece ocioso por uma boa parte desse tempo de carregamento "lento". Quando eu começo a ver as consultas vindas do servidor front-end, a página é carregada logo em seguida.
Aqui estão algumas estatísticas depois de eu fazer o login durante uma desaceleração, depois de reiniciar o php-fpm:
[mike@front01 ~]$ free -m
total used free shared buffers cached
Mem: 5963 5217 745 0 192 314
-/+ buffers/cache: 4711 1252
Swap: 4047 4 4042
[mike@front01 ~]$ top
top - 11:38:55 up 2 days, 1:01, 3 users, load average: 0.06, 0.17, 0.21
Tasks: 131 total, 1 running, 130 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.3%sy, 0.0%ni, 99.3%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 6106800k total, 5361288k used, 745512k free, 199960k buffers
Swap: 4144728k total, 4976k used, 4139752k free, 328480k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31806 apache 15 0 601m 120m 37m S 0.0 2.0 0:22.23 php-fpm
31805 apache 15 0 549m 66m 31m S 0.0 1.1 0:14.54 php-fpm
31809 apache 16 0 547m 65m 32m S 0.0 1.1 0:12.84 php-fpm
32285 apache 15 0 546m 63m 33m S 0.0 1.1 0:09.22 php-fpm
32373 apache 15 0 546m 62m 32m S 0.0 1.1 0:09.66 php-fpm
31808 apache 16 0 543m 60m 35m S 0.0 1.0 0:18.93 php-fpm
31807 apache 16 0 533m 49m 30m S 0.0 0.8 0:08.93 php-fpm
32092 apache 15 0 535m 48m 27m S 0.0 0.8 0:06.67 php-fpm
4392 root 18 0 194m 10m 7184 S 0.0 0.2 0:06.96 cvd
4064 root 15 0 154m 8304 4220 S 0.0 0.1 3:55.57 snmpd
4394 root 15 0 119m 5660 2944 S 0.0 0.1 0:02.84 EvMgrC
31804 root 15 0 519m 5180 932 S 0.0 0.1 0:00.46 php-fpm
4138 ntp 15 0 23396 5032 3904 S 0.0 0.1 0:02.38 ntpd
643 nginx 15 0 95276 4408 1524 S 0.0 0.1 0:01.15 nginx
5131 root 16 0 90128 3340 2600 S 0.0 0.1 0:01.41 sshd
28467 root 15 0 90128 3340 2600 S 0.0 0.1 0:00.35 sshd
32602 root 16 0 90128 3332 2600 S 0.0 0.1 0:00.36 sshd
1614 root 16 0 90128 3308 2588 S 0.0 0.1 0:00.02 sshd
2817 root 5 -10 7216 3140 1724 S 0.0 0.1 0:03.80 iscsid
4161 root 15 0 66948 2340 800 S 0.0 0.0 0:10.35 sendmail
1617 nicole 17 0 53876 2000 1516 S 0.0 0.0 0:00.02 sftp-server
...
Há mais alguma coisa para a qual eu deveria estar olhando ou mais alguma informação que possa ser útil? Sou apenas um desenvolvedor, mas as lentidões neste sistema me preocupam e dificultam meu trabalho.
Me ajudem, ServerFault!
No caso de alguém mais sofrer isso.
Acabamos de experimentar o mesmo problema. Um vazamento de memória no php5-fpm. A RAM é usada com cada solicitação de página e, eventualmente, maximizada. Em seguida, a CPU entra em overdrive com o processo KSWAP executando o disco de troca.
a única coisa que consertou, apesar de não ser a configuração ideal, foi mudar nosso arquivo de conjunto de arquivos
pm = dynamic
para
pm = ondemand
a memória agora parece estável.
Veja duas coisas para verificar:
O mais provável é que você tenha um vazamento de memória. pm.max_requests irá matar / reiniciar o processo filho do php-fpm depois de ter lidado com muitas solicitações. Como demora cerca de um dia para a sua caixa desacelerar para um rastreamento, tente definir isso para um número para fazer com que cada processo filho seja reaparecido a cada 20 minutos ou mais. Portanto, se você receber 200 pedidos por minuto, e você tem 5 processos, definir pm.max_requests a 800. Se você não quiser fazer a matemática, uma definição entre 500-1000 poderia funcionar. Brinque com ele para encontrar um equilíbrio entre perder tempo recuperando processos versus desperdiçar RAM no vazamento de memória.
Php-FPM pode estar criando muitos processos filhos quando ocorre um pico de tráfego, fazendo com que ele fique sem RAM e comece a trocar para o disco. Decida quanto de RAM total alocar para php-fpm e, em seguida, divida-o pela quantidade de memória que cada processo filho recebe. Para fóruns baseados em Wordpress e PHP, muitas vezes vejo cada processo filho requerendo 30-45MB. Se você estiver usando apenas um conjunto php-fpm, defina pm.max_children para esse número.
Se você tiver apenas um único pool php-fpm, verá um aumento de velocidade na configuração de pm.type = static .
Se você tem vários php-fpm piscinas, possivelmente porque você está hospedando vários aplicativos e deseja isolá-los por razões de segurança, você vai querer definir pm.type = dynamic e brincar com start_servers , min_spare_servers e max_spare_servers . Apenas certifique-se de que o max_children acumulado em todos os pools não seja maior do que o da sua caixa.
Se você tiver um grande número de aplicativos de baixo tráfego, cada um com seu próprio conjunto php-fpm, é melhor definir pm.type=ondemand para que cada aplicativo esteja apenas ocupando recursos quando estiver sendo usado. Também defina pm.max_children razoavelmente baixo para que nenhum aplicativo possa sobrecarregar completamente a caixa.
Na próxima vez que o servidor ficar lento, execute 'vmstat 1' e 'iostat 1' e, em seguida, reporte os resultados para nós.
Meu palpite é que o php5 acabou de ser atualizado com o limite de memória padrão de 128Mb e há muitas instâncias do php5 em execução (verifique pm.max_children em sua configuração do php-fpm).
O acima também aconteceu comigo, e eu tenho puxado meu cabelo tentando entender. Eu registrei um bugreport com o ubuntu, mas eu suponho que ele precisa ser corrigido pelo upstream do php-fpm - os defaults que eu consumiria seriam 6Gb RAM se pudesse. E isso com certeza fez com que meu servidor de 1Gb fosse inútil ...
Você provavelmente não tem algum cache de opcode instalado no servidor que está causando lentidão.
Além disso, como o Marco disse, você pode estar executando um grande número de instâncias do php-fpm no sistema.
Caso você suspeite de um problema de vazamento de memória, instale a extensão suhosin para php, o que evitará vazamentos de memória.
Na verdade, se é um vazamento de memória, deve ser registrado no log de erros php, php.ini tem uma opção para relatar memleaks, report_memleaks = On
Tags php nginx memory memory-leak vmware-esx