Les scripts PHP se chargent soudainement très lentement sur Apache.

Il peut y avoir plusieurs raisons à ce comportement :

1. Si ce serveur web traite des requêtes provenant du réseau externe, alors avec l'augmentation du trafic, la charge pourrait augmenter, ce qui a conduit à une augmentation du temps de réponse du serveur.
2. Si vos scripts utilisent des appels à des ressources externes, alors dans ce cas, le temps de réponse de votre serveur peut augmenter en raison de la faible vitesse de réponse de la ressource externe.

Message de journal :

[30-Sep-2021 03:36:46] AVERTISSEMENT : [pool www] le serveur a atteint le réglage pm.max_children (5), envisagez de l'augmenter

n'est qu'une preuve de l'augmentation de la charge.

Dans les deux cas, vous devriez déterminer les raisons de la charge en analysant le nombre de requêtes vers les scripts, et s'il y a des appels à des ressources externes, assurez-vous qu'ils fonctionnent correctement.

Comme vous pouvez le constater dans votre sortie de statut vous avez une tâche en attente de démarrage (5 actives, 0 inactives, 6 tâches). Comme vous l'avez mentionné dans votre propre réponse (et je suis content que cela ait fonctionné) augmenter le nombre d'enfants autorisés peut être une bonne solution - mais il y a beaucoup de paramètres à prendre en compte pour optimiser php-fpm, et certainement plus de réflexion doit être accordée à l'ensemble du système avant d'apporter ces modifications de configuration.

Un guide solide se trouve ici.

Mais quoi qu'il en soit, vous devez savoir lorsque vous utilisez des valeurs statiques:
si (utilisation mémoire du processus * max_children > RAM)
{ [plantage d'apache] }

si (exigences de traitement * start_servers > CPU)
{ [plantage d'apache] }

Et toujours connaître votre matériel avant de régler ces paramètres, surtout en dynamique/sur demande (à mon avis, plus facile de faire des erreurs).

Si vous faites cela pour un serveur web d'entreprise critique, je vous conseille d'arrondir les estimations puis de les doubler. Par exemple, si le plus gros processus qui peut être appelé utilise 178 Mo, alors 200 Mo, et votre VM actuelle chez [fournisseur d'hébergement/chez vous-même] a seulement 1 Go de RAM - je fixerais max_children à 2 -- puis lorsque vous mettez à niveau votre VM (que faites-vous avec 1 Go en 2021 ??) et que vous disposez de 8 Go de RAM sur votre serveur, vous pouvez utiliser max_children = 18 Remarquez dans les deux exemples que l'arrondi favorise des ressources supplémentaires, et après avoir doublé à des fins de fpm, laisse derrière lui une partie de la mémoire pour que le système d'exploitation et d'autres processus en arrière-plan puissent l'utiliser.

Ajuster ces paramètres peut être extrêmement utile, et toute personne utilisant apache devrait savoir comment - juste assurez-vous que votre matériel peut gérer la configuration logicielle que vous avez mise en place.

Nous avons eu presque exactement le même problème l'année dernière.

Augmenter le nombre maximum d'enfants ne fera que repousser le problème à une date ultérieure.

Il s'est avéré que c'était une base de données MySQL lente hébergée sur un serveur dédié sur notre réseau pour un blog.

Notre PHP était configuré pour essayer de se connecter pendant 30 secondes et chaque fois que cette base de données décidait de poser problème, elle consommait 100 enfants PHP.

Nous l'avons réduit à 1 seconde et le problème a disparu. Je ne me rappelle pas si le problème de la base de données était lié au réseau ou si nous avons dû optimiser la base de données elle-même.

Vous devriez vérifier votre journal d'accès Apache pour cette période de 2h30 à 3h30 et déterminer s'il s'agit de pages qui se connectent à une base de données. Vérifiez le journal pour les erreurs 500 qui précèdent l'effondrement du serveur.