Como parar uma rampa aleatória nos processos FCGI Matar o servidor

Question

Então, recebi o abaixo, mais cedo, para o dia ...

Por volta dessa hora, os registros mostram uma rampa nos processos (600) e na memória associada (1,2g), média de carga de uso da CPU (80) até que o servidor forneceu.

O servidor precisava ser reiniciado por host, pois não havia acesso ao painel ssh ou plesk.

O Fast CGI é configurado conforme abaixo e é configurado para um site de alta utilização. Pelo que entendi, o FcgidMaxProcesses 20 deve proteger contra o que aconteceu, mas não o fez.

Eu li muitos fóruns com diferentes respostas e referências a muitas diretivas fcgi diferentes, mas não encontrei nada conclusivo. Alguém tem algumas respostas definitivas sobre como parar esse tipo de sobrecarga do processo do servidor e a subsequente falha do servidor?

Se precisar de mais informações, me avise.

Felicidades Andy

 /var/log/apache2/error_log
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17651 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17650 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17649 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17644 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17643 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17638 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17633 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17627 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:47 2012] [warn] mod_fcgid: process 17622 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17674 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17673 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17672 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17667 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17666 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17665 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17664 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17659 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17658 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17657 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17656 graceful kill fail, sending SIGKILL
[Thu May 17 07:40:51 2012] [warn] mod_fcgid: process 17651 graceful kill fail, sending SIGKILL

link link link link

<IfModule mod_fcgid.c>

<IfModule !mod_fastcgi.c>
    AddHandler fcgid-script fcg fcgi fpl
</IfModule>
  FcgidIPCDir /var/lib/apache2/fcgid/sock
  FcgidProcessTableFile /var/lib/apache2/fcgid/shm

  FcgidIdleTimeout 40
  FcgidProcessLifeTime 30
  FcgidMaxProcesses 20
  FcgidMaxProcessesPerClass 20
  FcgidMinProcessesPerClass 0
  FcgidConnectTimeout 30
  FcgidIOTimeout 120
  FcgidInitialEnv RAILS_ENV production
  FcgidIdleScanInterval 10
  FcgidMaxRequestLen 1073741824
</IfModule>

    

Answer 1

Houve um bug no Debian (pelo menos) que tornou o limite inútil para hosts virtuais. Está consertado agora.

link

    

Answer 2

Isso geralmente é causado por um script CGI setuid que trava; excede o IOtimeout, e o apache tenta matá-lo, mas é incapaz por causa da mudança no uid, resultando no erro.

Você pode querer aumentar o FcgidIOTimeout ou FcgidProcessLifetime para permitir que o thread tenha mais tempo para concluir.

Outra solução é fazer com que o servidor Apache seja executado sob o mesmo UID para o qual o script setuid está sendo executado. Isso permite que ele mate o processo, embora possa não ser aconselhável por razões de segurança. Da mesma forma, executar o apache como root também é uma solução alternativa, mas não muito segura. Se você fizer isso, observe que o diretório fcgi sock (em / var / lib / apache2 / fcgid / sock ou similar) e o arquivo da tabela de processos precisam ser graváveis pelo proprietário do processo apache.

A causa principal, no entanto, é o próprio script CGI demorando muito. A causa disso depende do código CGI que eu não tenho visibilidade.