2017-01-12 7 views
9

J'utilise/server-status pour surveiller les processus Apache. Lors du démarrage, ils ressemblent à ceci:Pour de nombreux processus Apache en cours d'exécution en état READ sans demandes après un certain temps

_____W_K__K____________C_K________C_____________W_.............. 
................................................................ 
................................................................ 

Mais après quelques heures de regarder courir comme ceci:

R_KCR___KR__RKRR_RRRKRRRRRRKRR_RRCK____R_RRRR_RRRKRRRKRRRRRRRRR_ 
R_RRRR_R.RR.R_R.R_R..CKRRRRW.K_RCRKRR_R_.._R._.RK_KRK_.RRR.KK_.R 
..RR............................................................ 

Il y a trop de « lecture » (R), qui a pris beaucoup de temps et je ne Je ne sais pas ce qu'ils font, car ils n'ont même pas de demandes. (Mentionner qu'il ya des statuts supplémentaires que j'ai sauté dans l'exemple ci-dessus, au total, j'ai 2000 postes disponibles « ».) Dans la liste des processus que j'ai environ 40 processus « R » comme celui-ci:

Srv PID Acc  M CPU SS Req Conn Child Slot Client  VHost Request 
15-2 21291 0/37/11158 R 0.03 7468 2 0.0 1.93 198.35 82.78.95.105 

le regard d'en-tête du rapport comme celui-ci:

Server Version: Apache/2.4.10 (Debian) mod_fcgid/2.3.9 OpenSSL/1.0.1t 
Server MPM: prefork 
Server Built: Sep 15 2016 20:44:43 
Current Time: Thursday, 12-Jan-2017 08:38:46 EET 
Restart Time: Wednesday, 11-Jan-2017 00:51:18 EET 
Parent Server Config. Generation: 3 
Parent Server MPM Generation: 2 
Server uptime: 1 day 7 hours 47 minutes 27 seconds 
Server load: 0.34 0.35 0.39 
Total accesses: 1599556 - Total Traffic: 29.9 GB 
CPU Usage: u18.87 s6.81 cu0 cs0 - .0224% CPU load 
14 requests/sec - 274.0 kB/second - 19.6 kB/request 
90 requests currently being processed, 27 idle workers 

J'ai un serveur privé avec: 4X3.6GHZ processeur Xeon, 2x512 Go SSD, 32 Go de mémoire, Debian 3.16.36-1, Apache 2.4.10, PHP 5.6. 29, mod_fcgid, php-fpm, php5-cgi, préforc.

Certains de mes paramètres de apache2.conf:

Timeout 14400 
KeepAlive On 
MaxKeepAliveRequests 1000 
KeepAliveTimeout 3 
HostnameLookups Off 

Mes paramètres de mpm_prefork.conf:

<IfModule mpm_prefork_module> 
    StartServers 50 
    MinSpareServers 25 
    MaxSpareServers 50 
    ServerLimit 2000 
    MaxRequestWorkers 2000 
    MaxConnectionsPerChild 1000 
</IfModule> 

Certains de mes paramètres de fcgid.conf:

FcgidMaxRequestLen 1073741824 
FcgidOutputBufferSize 1073741824 
FcgidMaxProcesses 200 
FcgidMaxProcessesPerClass 100 
FcgidMinProcessesPerClass 0 
FcgidProcessLifeTime 30 
FcgidConnectTimeout 30 
FcgidIOTimeout 14400 
FcgidBusyTimeout 14400 
FcgidIdleTimeout 3 
FcgidIdleScanInterval 1 

J'ai quelques cronjobs de longue durée dans les serveurs, c'est pourquoi j'ai besoin de ce grand délai de "14400" (= 4 heures) sur les processus Apache et PHP.

Questions:

  1. Pourquoi il y a tant de statuts "R" sans demandes?
  2. Qu'est-ce qu'ils font, comment puis-je savoir?
  3. Pourquoi ils fonctionnent si longtemps?

Mise à jour 1:

A ont modifié les délais d'attente de 7200 (= 2 heures), c'est le minimum pour moi peut exécuter mes tâches cron. Cependant, je n'ai pas eu de problèmes avec mes cronjobs.

FcgidIOTimeout 7200 
FcgidBusyTimeout 7200 

également pour Apache:

Timeout 7200 

Basé sur PHP and mod_fcgid: ap_pass_brigade failed in handle_request_ipc function Je l'ai fait:

FcgidOutputBufferSize 0 

Basé sur mod_fcgid: ap_pass_brigade failed in handle_request function Je l'ai fait:

FcgidMaxRequestsPerProcess 500 

Après quelques heures le serveur a cessé de répondre:

Service indisponible: Le serveur est temporairement incapable de réparer votre demande en raison de problèmes d'indisponibilité maintanance ou de capacité. Veuillez essayer de nouveau plus tard.

Dans les journaux, j'ai trouvé quelques erros comme ces deux:

[fcgid:warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function 
[fcgid:warn] (32)Broken pipe: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function 

Et un tas de comme ça (peut-être pour chaque demande):

[fcgid:warn] mod_fcgid: too much processes, please increase FCGID_MAX_APPLICATION 

Questions 2:

  1. Que signifient ces erreurs? Comment puis-je les corriger?
  2. Pourquoi le serveur ne répond plus? Probablement à cause d'erreurs ...
  3. Les modules mod_fcgid, php-fpm, php5-cgi, prefork sont-ils entièrement compatibles et efficaces? C'était les configurations par défaut quand j'ai eu le nouveau serveur.
+2

La clé ici est votre commentaire "J'ai des cronjobs à long terme dans les serveurs, c'est pourquoi j'ai besoin de ce gros délai de" 14400 "(= 4 heures) sur les processus Apache et PHP." Arrêtez-les, le problème persiste? Des commandes comme lsof vous montreront des connexions actives pour ces enfants. Et sur une autre note, si vous avez mod_fcgid, vous n'avez pas besoin de prefork et vous pouvez passer à un événement mpm threadé qui sera beaucoup plus évolutif. Les emplacements ouverts reflètent les directives de vos serveurs de rechange. Les requêtes OPTIONS proviennent de quelque chose, apache ne fait pas de ping lui-même. –

+1

dans tous les cas, essayez de réduire vos délais à des valeurs normales et vous verrez ce comportement s'arrête. –

+1

Vos scripts PHP sont suspendus là pour toujours car pour une raison quelconque, mod_fcgid ne peut pas générer plus de processus, car ce que je lis "FCGID_MAX_APPLICATION" est une table interne qui peut simplement être modifiée sur la source et recompiler. Quelle version de mod_fcgid utilisez-vous? Si ce n'est pas le dernier peut-être que vous devriez mettre à jour. Ma recommandation? Migrer vers mod_proxy_fcgi -> php-fpm, cela vous permettra d'avoir apache avec mpm_event et php-fpm est assez polyvalent et vous permet des configurations très différentes. –

Répondre

5

Problème résolu.

La solution était de réduire Timeout valeur de l'Apache à un certain nombre comme 15. Comme je l'ai réalisé pour l'exécution d'un script PHP longue (même pendant des heures) ne doivent pas nécessairement ce délai d'attente pour être Hight, il est enought que max_execution_time de PHP être assez grand.

Mise à jour

J'ai également mis à niveau vers PHP 7.1 avec FastCGI en PHP-FPM, et je l'ai changé le mode de l'Apache MPM à l'événement comme esra-s suggéré, et il fonctionne comme l'enfer. Merci beaucoup!

+0

Pouvez-vous élaborer là-dessus? Êtes-vous en train de dire que PHP 7.1 peut maintenant fonctionner sous Apache mpm event, et est thread-safe? –