Processus PHP-FPM bloqués par des requêtes en base de données

Services Stockage/ partage de documents
1

Salut,
Depuis 2 semaines, je rencontre des problèmes sur mes instances nextcloud 27.x fonctionnant avec php-fpm 8.1 et 8.2 (et mariadb). Heureusement, je n’ai pas tout mis à jour d’un coup (juste 3).

En résumé: les processus php se coincent et ne répondent plus, mais le service systemd n’est pas marqué comme failed.

Grâce à @oiseauroch , je peux confirmer qu’il s’agit du problème décrit ici: https://github.com/nextcloud/server/issues/39063

J’ai commencé par une énorme rustine :

watch -n 40 'if [ "$(timeout 10 curl --write-out '%{http_code}' --silent --output /dev/null https://domain.tld/login)" != "200" ]; then systemctl restart php8.2-fpm ;  echo "" > mail -s "Restart Nextcloud" valentin@domain.tld ; fi'

Sauf que ça gène un peu les utilisateurices de temps en temps et j’ai eu des remontées d’instabilité (code 502 et 501).

J’ai mené plusieurs actions d’optimisation pour contourner le problème:

  • augmenté le nombre de processus (initialement max_children à 8)
pm = static
pm.max_children = 15
pm.max_requests = 500
  • timeout sur les requêtes de 5 minutes
request_terminate_timeout = 5m
  • et une optimisation sans rapport:
php_value[opcache.revalidate_freq]=60

Depuis, j’ai plus de plaintes, et sur l’instance que j’utilise personnellement, tout semble rouler.

Sauf que le contournement request_terminate_timeout = 5m limite le chargement de gros fichiers à 5 minutes.

Là, je suis parti pour essayer d’augmenter un peu request_terminate_timeout = 1h sur une instance, histoire de voir ce que ça donne sur ce champs de bataille.

Mon petit doigt me dit que je serais bientôt pas le seul à avoir ce soucis, raison pour laquelle je vous écrit, ça peut vous aider à décider si oui ou non il faut migrer vers une nouvelle version.

Bonne journée,

2 « J'aime »
3

Hello,

pm.max_children = 15 est peut-être trop bas. Tu peux essayer de le doubler pour voir. Idle, ça ne mange pas beaucoup de RAM de toutes les façons.
Ceci dit, il y a ce guide très complet, avec notamment tout ce qu’il faut pour évaluer des valeurs cohérentes.

1 « J'aime »
4

Je l’ai calculé en fonction de la ram (pour y consacrer 1GB) et de la taille moyenne des processus (63Mo)… Je pourrais mettre un peu plus en effet, (les installs où il y a beaucoup de monde j’ai pm.max_children = 100 )

5

Salut,
par curiosité, il s’agit d’environnements avec Yunohost ?

6

Oui tout à fait. J’ai pas pensé à le préciser…

7

Donc avec ce réglage en plus, ça semble fonctionner pas trop mal et personne ne s’est plein pour l’instant de ne pas réussir à charger son énorme fichier qui prend plus d’une heure à synchroniser.

Merci aux personnes qui m’ont filé un coup de main. J’ai pas encore pu intégrer le changement sur le paquet yunohost par contre.

1 « J'aime »
8

Salut,

Il se trouve que je suis justement en train d’installer un nextcloud sur ma VM perso depuis hier.

Dans la doc officielle Nextcloud, je n’ai vu aucune mention concernant une nécessité de modifier request_terminate_timeout dans php-fpm, par contre ils recommandent de modifier les directives PHP max_input_time et max_execution_time (Uploading big files > 512MB — Nextcloud latest Administration Manual latest documentation) :

php_value max_input_time 3600
php_value max_execution_time 3600

Ensuite je suis allé voir ma conf PHP-FPM (majoritairement la configuration par défaut), et il se trouve d’une part que la valeur par défaut de request_terminate_timeout est 0 (désactivé), du moins sur Debian 12. D’autre part qu’il semble que cette valeur ne soit utile que lorsque la directive PHP max_execution_time est inopérante :

; The timeout for serving a single request after which the worker process will
; be killed. This option should be used when the 'max_execution_time' ini option
; does not stop script execution for some reason. A value of '0' means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
; Default Value: 0
;request_terminate_timeout = 0

Personnellement j’ai suivi les recommandations Nextcloud, je modifierai si je constate des problèmes de performance.

Mais du coup :

  • Est-ce vraiment nécessaire de garder une limitation request_terminate_timeout ?
  • Est-ce que tu ne devrais pas revenir à la configuration recommandée (fixer max_execution_time et désactiver request_terminate_timeout) ?

Sekil

9

J’ai vérifié du coup, j’ai:

max_input_time = 60
max_execution_time = 30

Du coup, peut être que depuis le début on ne peut pas uploader ou télécharger pendant plus de 60s (mais j’en doute).

En tout cas, ces valeurs montrent qu’il y a bien besoin de request_terminate_timeout (au moins sur les installs yunohost ou du moins les miennes), puisque pour rappel, le problème initial c’est qu’avec request_terminate_timeout=1d il y a des processus php-fpm qui ne répondent plus et ne sont jamais recréés…

10

Je pense que cela dépend du mode, puisqu’en fonction de la manière dont on envoie les fichiers (HTTP, WebDAV, Nextcloud client), les fichiers ne sont pas envoyés pareil. Et à vrai dire à la relecture cela semble être une optimisation optionnelle:

Adjust these values for your needs. If you see PHP timeouts in your logfiles, increase the timeout values, which are in seconds

Effectivement. J’avais oublié ce point.

11

Houra, le bug viendrait d’être identifié et corrigé.

1 « J'aime »
12

Super, est-ce que ce merge serait pris en compte sur Yunohost avec une upgrade --force ?? ou bien il faudra attendre la prochaine version avec le tarball…

13

Pour l’instant, je pense qu’il faut attendre Nextcloud 27.1.4…

14

Une release 27.1.4 est désormais dispo sur github.

1 « J'aime »