php-fpm plantage

[devildant]

Bonjour,

depuis que synology a intégré php-fpm j'ai des souci de crash  (ça fait un moment), mes site web deviennent inaccessible, et la seul solution est de restart webstation ou via ligne de commande, ça commence doucement a m'agacé. 

j'ai fait plusieurs tentative, comme désactiver opcache, augmenter le maxclients (amis google) mais rien y fait le problème réapparaît toujours.

je n'ai plus trop d'idée, je me tourne vers vous pour voir si vous avez d'autre piste.

dans mes log j'ai ceci : 

[/var/log/php-fpm.log]

ERROR: An another FPM instance seems to already listen on /run/php-fpm/php-fpm.sock
[25-Aug-2015 10:38:26] ERROR: FPM initialization failed
[25-Aug-2015 11:21:38] NOTICE: configuration file /etc/php/php-fpm.conf test is successful

 

[/var/log/httpd/user-error_log]

[Tue Aug 25 11:09:55 2015] [error] server is within MinSpareThreads of MaxClients, consider raising the MaxClients setting
[Tue Aug 25 11:10:26 2015] [error] server reached MaxClients setting, consider raising the MaxClients setting

actuellement j'ai fait un script qui check la disponibilité d'une de mes pages et en cas d'erreur, il restart le service httpd avec : 

/usr/syno/sbin/synoservicecfg --restart httpd-user

mais bon ce n'est que temporaire

 

 

Modifié le 25 août 2015 par devildant

[Fenrir]

Tu as essayé de reconfigurer ton pool fpm ?

Par défaut fpm est configuré en mode dynamic, ce qui est loin d'être le plus efficace :

• pm = dynamic
• pm.max_children = 20
• pm.start_servers = 2
• pm.min_spare_servers = 1
• pm.max_spare_servers = 3

Essaye avec ces paramètres (à la place des précédents) :

• pm = ondemand
• pm.max_children = 5
• pm.process_idle_timeout = 10s
• pm.max_requests = 200

Pour la seconde erreur, ça vient d'apache, mais c'est probablement lié à la première erreur (fpm ne répond pas=>les requêtes en attente s'accumulent dans apache), ou alors tu as beaucoup de visiteurs, dans ce cas il faut faire du tuning (optimisation des sites, reverse px, cache, ...)

[devildant]

Tu as essayé de reconfigurer ton pool fpm ?

Par défaut fpm est configuré en mode dynamic, ce qui est loin d'être le plus efficace :

• pm = dynamic
• pm.max_children = 20
• pm.start_servers = 2
• pm.min_spare_servers = 1
• pm.max_spare_servers = 3

Essaye avec ces paramètres (à la place des précédents) :

• pm = ondemand
• pm.max_children = 5
• pm.process_idle_timeout = 10s
• pm.max_requests = 200

Pour la seconde erreur, ça vient d'apache, mais c'est probablement lié à la première erreur (fpm ne répond pas=>les requêtes en attente s'accumulent dans apache), ou alors tu as beaucoup de visiteurs, dans ce cas il faut faire du tuning (optimisation des sites, reverse px, cache, ...)

merci,

pas bête, je vais tester ça, je mettrai a jour le message si ça s'améliore.

pour info je n'ai pas beaucoup de trafic, mais j'ai un projet avec une config assez particulière, j'ai dev en php un outil qui me permet de télécharger a partir d'un autre FTP sur mon syno, et pour faire cela et pour pouvoir faire certain traitement async j'ai des pages php (script qui en appel d'autre via http, c'est pas forcement la meilleur solution mais elle répond bien a mon besoin).

a cause du ftp j'ai certain script php qui sont long a s’exécute mais je les lancent via des exec en background.

j'ai déjà fait une passe de nettoyage en vérifiant bien que les sessions sont close le plus rapidement possible ainsi que la bdd. 

j'ai fait des tests de charge avec plusieurs jours de dl  en continue et ça ne bronche pas et puis quelque temps après (ça peux être plusieurs semaine) alors qu'il n'y a pas plus de stress que d’habitude d'un coup il y a une saturation et tout crash.

j'ai activé server-status de apache mais même en utilisant mon module ça ne bouge quasiment pas 2 ou 3 W mais pas plus.

bon j'ai également un reverse proxy en amont avec haproxy (via docker) mais bon je n'ai théoriquement pas de retry comment peux le faire nginx. 

concernant le module qui se charge du dl c'est lftp, wget ou encore rsync qui sont lancé en ssh via la lib phpseclib.

[Fenrir]

Si tu utilises docker, je te recommande de migrer ton appli dans un conteneur :

• ça évitera de devoir tuner le syno
• tu seras plus libre d'ajouter des dépendances/logiciels tiers, comme nginx
• relancer le conteneur (quelques secondes) sera bien plus rapide que de relancer le syno
• en cas de changement de syno, tu n’auras qu'à exporter/importer ton conteneur
• et ça sera plus sécurisé (faire des appels système en php via le serveur web, c'est mal)

Sinon je te suggère de repenser ton système, plutôt que d'appeler tes scripts via php-apache-php, enregistre les "taches" dans un fichier ou une base et créé un script lancé en crontab qui traite ces taches.

[devildant]

Si tu utilises docker, je te recommande de migrer ton appli dans un conteneur :

• ça évitera de devoir tuner le syno
• tu seras plus libre d'ajouter des dépendances/logiciels tiers, comme nginx
• relancer le conteneur (quelques secondes) sera bien plus rapide que de relancer le syno
• en cas de changement de syno, tu n’auras qu'à exporter/importer ton conteneur
• et ça sera plus sécurisé (faire des appels système en php via le serveur web, c'est mal)

Sinon je te suggère de repenser ton système, plutôt que d'appeler tes scripts via php-apache-php, enregistre les "taches" dans un fichier ou une base et créé un script lancé en crontab qui traite ces taches.

pour docker j'y est pensé mais sa veux dire encore un nouveau port et par conséquent encore un sous domaine pour le passé par le port   , après j'ai mappé tout mon site web pour qu'il centralise les authentification DSM et photostation (api) et compagnie et j'ai aussi mon propre videostation  du coup ça me ferai faire beaucoup de modification mais a voir je prends note.

concernant l'idée du cron c'est pas bête, mais j'avais fait ça pour parallélisé certaine tache car les fork ou thread en php c'était pas sa la dernière fois que j'ai regardé maiss je sais que c'est mal

je maintient ce projet depuis que j'ai un syno dsm 2.3   j'ai un peux debuté le web avec.

l'idée du container me semble bien mais ça fait beaucoup de modif ^^

[Fenrir]

Je ne sais pas exactement ce que fait ton "site", mais le passer dans un container ne devrait pas être si compliqué (surtout que tu devrais pouvoir le faire en parallèle de l'existant sans conflit).

Pour la parallélisation des taches, je ne vois pas ce que tu peux faire en php via des call http que tu ne puisse faire avec des scripts (qui peuvent être en php) et cron.

On verra déjà ce que ça donne avec les réglages de php-fpm

[devildant]

Je ne sais pas exactement ce que fait ton "site", mais le passer dans un container ne devrait pas être si compliqué (surtout que tu devrais pouvoir le faire en parallèle de l'existant sans conflit).

Pour la parallélisation des taches, je ne vois pas ce que tu peux faire en php via des call http que tu ne puisse faire avec des scripts (qui peuvent être en php) et cron.

On verra déjà ce que ça donne avec les réglages de php-fpm

oui j'ai déjà changé la conf, pour le moment ça bronche pas.

mon "site" fait beaucoup de chose, et surtout j'ai des interconnexions importantes avec certaines méthodes du syno (comme le system de blocage d'ip que j'utilise soit via les api syno ou soit la ligne de commande), du coup en passant par un container je suis obligé de faire des bidouilles pour les utiliser. j'utilise aussi certain package comme svn...

en tout cas merci de ton aide

Modifié le 27 août 2015 par devildant

[devildant]

Bon je viens de me rendre compte que la conf que je modifiais dans /etc/php/php-fpm.conf était réécrite a chaque fois que je restart le service web.

Une idée ou se trouve la conf php-fpm ? 

[Fenrir]

Je ne joue jamais avec les dossiers/fichiers système par défaut des mes syno.

Tu peux créer une conf custo dans /etc/php/fpm.d/ (include=/etc/php/fpm.d/*.conf), elle sera persistante.

Normalement les paramètres écraseront ceux de la conf par défaut

 

[devildant]

merci Fenrir,

conf appliqué depuis hier ça tiens pour le moment 

 

[devildant]

ça ne bronche pas, j’espère que sa va continuer

 

[devildant]

bon le problème est toujours la, j'ai l'impression que seul mon module ftp est en cause, il y a beaucoup d'ajax dessus ( toute les 1 ou 2 seconde), je dois faire tomber mon serveur web tout seul.

peux être devrais je utiliser des webSocket pour voir, si vous avez d'autre idée je suis preneur

[Fenrir]

comme je ne sais toujours pas ce que fait ton dev, difficile de te répondre comme ça

Encore une fois, regarde dans les logs (regarde aussi la taille de ces logs)

[devildant]

comme je ne sais toujours pas ce que fait ton dev, difficile de te répondre comme ça

Encore une fois, regarde dans les logs (regarde aussi la taille de ces logs)

oki alors : 

la page en question se connecte a un ftp et affiche le contenue (dossier fichier), l'utilisateur peux se baladé dans l’arborescence et telecharger sur le syno des dossiers ou des fichiers de ce ftp. 

pour télécharger le fichier j'utilise soit wget, rsync, ou lftp. une fois que le transfère commencer j'ai un page ajax qui se charge de parsé les logs des diff programme de téléchargement pour afficher dans ma page principale le nombre de téléchargement effectuer, la vitesse le temps restant ....

 

pour un Téléchargement voila comment ça se passe niveau code :

index.php => ajxftp (page qui récupéré en poste la liste des fichier ou dossier a dl) => deamonTranf.php (ce php lui est appeler en ligne de commande et se charge d'executé un a un les dl) => deamonDownload.php (execute le programme de dl que j'ai choisi wget, rsync....)

 

a coté de ça j'ai une autre page qui est lancé en cron et verifie qu'un telechargement n'est pas bloquer ou autre. et j'ai egalement mi en place un systeme d'attente qui permet de de ne lancé qu'un seul dl a la fois pas user.

[devildant]

j'ai fait 2 3 tests et je pense que mon souci viens de l'ajax, j'ai l'impression que par moment les requête s'empile et que je me fait moi même un déni de service.

pour mon test je n'ai lancé aucun transfère, j'ai juste ouvert plusieurs instance de ma page et au bout d'un moment ca crash 

j'ai une configuration un peux particulière, car j'ai beaucoup de mes user qui sont sur un reseau bridé (port  et 443 seulement) du coup j'ai un reverse proxy en place avec haproxy.

du coup j'ai cette config : 

haproxy => nginx (syno) => apache

[Fenrir]

C'est effectivement un problème de code, de plus je suppose que tu rafraichi les infos rapidement.

Comme tu es capable de reproduire le crash, fais ceci :

• ouvre plusieurs consoles ssh :
  • surveille les logs : tail -f sur tous les logs que tu parse et sur ceux de ton appli (donc php+apache+nginx+haproxy)
  • avant de lancer le test : ps | sort > /tmp/1
  • au moment du crash : ps | sort > /tmp/2
  • diff /tmp/1 /tmp/2

Les ps devraient te permettre d'identifier le process qui crash et le tail devrait d'indiquer la cause

edit : en complément : DSM->Resource Monitor->Settings : Enable usage history

 

Modifié le 5 septembre 2015 par Fenrir

[devildant]

Oki je vais essayer.

j'ai rajouter les log de haproxy.

je vais aussi voir si le probleme se produit sans haproxy (conf standard webstation du syno)

je me rends compte que mes ennui on du arrivé avec la maj qui a apporter nginx.

[devildant]

Bonjour,

 

après plusieurs moi de galère, de recherche et d'aide de synology il semblerai que le problème soit du a un problème de configuration de php-fpm avec la rotation des logs (qui empêche dans certain cas le reload auto de php-fpm et qui par conséquent cause une erreur et stop php)

cela a été corrigé en DSM 6, et j'ai pu bénéficier d'un patch du support sous dsm 5.2, car j'attends d’être en vacance pour faire la maj DSM 6.

 

depuis plusieurs semaine le problème ne c'est pas reproduit, j'espere que cela va continuer

Modifié le 27 avril 2016 par devildant

[Fenrir]

Bonne nouvelles, merci pour le retour.

[devildant]

il y a une heure, Fenrir a dit :

Bonne nouvelles, merci pour le retour.

merci a toi pour tes conseils et ton aide