Vous hébergez plusieurs sites Drupal sur le même serveur PHP pour mutualiser l'infrastructure. Le jour où l'un d'eux reçoit un pic de trafic, c'est parfois toute la plateforme qui ralentit, y compris les sites qui n'ont rien demandé. Sans isolation, tous les sites consomment le même bassin de processus PHP. La réponse tient dans la configuration de PHP-FPM : un pool par site, des quotas mémoire et CPU posés à deux niveaux, et une surveillance qui alerte avant la saturation. Nous détaillons ici comment construire cette isolation, étape par étape.
Pourquoi l'isolation compte sur une plateforme Drupal multisite
Sur une installation multisite, un pic de trafic sur un site, une boucle mal maîtrisée dans un module ou une fuite mémoire peuvent épuiser les processus PHP disponibles. Sans isolation, cet incident se propage aux autres sites hébergés sur le même serveur, même s'ils n'ont aucun rapport avec la cause. Isoler par pool donne à chaque site sa propre réserve de processus PHP et sa propre limite mémoire, au lieu d'un bassin commun où le site le plus gourmand prend la place des autres. L'étanchéité s'arrête là : nous détaillons plus bas ce qu'un pool ne garantit pas.
Rappel : comment Drupal multisite partage un même serveur PHP
Un codebase partagé, des risques partagés
En multisite Drupal, plusieurs sites tournent depuis un même code source. C'est ce qui permet à tous les sites de partager un seul cache d'opcode, une astuce efficace en mémoire selon la documentation officielle des cas d'usage du multisite Drupal. Mais ce partage a un revers : si les sites n'utilisent pas tous les mêmes modules, un bug dans un module propre à un seul site peut perturber l'ensemble des sites de l'installation, comme le signale la documentation sur les considérations du multisite Drupal.
Nous avions déjà vu, à propos de la montée vers PHP 8.5, que préparer un Drupal sans casse ni perte de temps demande d'anticiper. L'isolation par pool est un autre levier, complémentaire : il agit sur le partage de ressources entre sites, pas sur la version de PHP elle-même.
Des pools PHP-FPM dédiés par site
Qu'est-ce qu'un pool FPM et pourquoi en créer un par site
PHP-FPM permet de faire tourner plusieurs pools de processus, chacun avec ses propres paramètres, d'après le manuel de configuration PHP-FPM. Un pool est un ensemble de processus PHP configuré indépendamment des autres. Dédier un pool par site Drupal donne à chacun son propre espace de configuration : son utilisateur système et ses limites.
Les directives clés : user, group, listen, pm
Dans le fichier de pool, user et group fixent sous quelle identité système tournent les processus de ce site. listen définit le socket ou le port dédié à ce pool. pm (process manager) choisit le mode de gestion des processus : statique, dynamique ou à la demande. Chaque pool a son propre pm.max_children, le nombre maximal de processus fils que ce pool peut créer, qui borne directement le nombre de requêtes simultanées qu'il peut servir, précise le manuel PHP-FPM.
Le bon réglage de pm et de pm.max_children pour un site donné, nous l'avons détaillé dans un article dédié au dimensionnement d'un pool PHP-FPM. Ici, la question est différente : comment séparer les pools entre eux, pas comment calibrer un pool seul.
Limiter la mémoire et le CPU par pool
Les quotas internes à PHP-FPM
Au-delà de pm.max_children, trois leviers bornent la consommation d'un pool depuis sa propre configuration. php_admin_value[memory_limit] = 32M, par exemple, impose une limite mémoire PHP par pool : ces valeurs admin ne peuvent pas être surchargées par le script via ini_set(), précise le manuel PHP-FPM, ce qui empêche un site mal codé de contourner la limite. Le plafond mémoire réel du pool se calcule en multipliant cette valeur par pm.max_children : avec dix processus à 32 Mo, le pool peut consommer jusqu'à 320 Mo. rlimit_files borne le nombre de descripteurs de fichiers ouverts par les processus de ce pool, et rlimit_core la taille maximale des core dumps qu'ils peuvent produire, selon la documentation PHP-FPM.
Les quotas système : cgroups et cpuset
Ces trois quotas ne touchent pas directement le CPU ni les nœuds mémoire physiques. Pour cela, vous descendez au niveau du système avec les cgroups du noyau Linux : un mécanisme qui organise les processus hiérarchiquement et distribue les ressources système de façon contrôlée le long de cette hiérarchie, selon la documentation du noyau Linux sur cgroup v2. C'est le même principe qu'un immeuble qui réserverait un quota d'électricité par étage plutôt qu'un compteur unique pour tout le bâtiment. Le sous-système cpuset expose deux fichiers utiles : cpuset.cpus liste les CPU que les tâches d'un groupe peuvent utiliser, et cpuset.mems fait l'équivalent pour les nœuds mémoire NUMA, d'après la même documentation du noyau. Vous pouvez ainsi restreindre le pool d'un site critique à un sous-ensemble de cœurs via cpuset.cpus, et contraindre les autres pools sur des cœurs distincts : la contention CPU entre les sites diminue d'autant, sans que la documentation du noyau ne pose d'exclusivité au-delà de cette répartition déclarée.
Ce que les pools ne garantissent pas
Les pools séparent la configuration, pas tout le reste. Le manuel PHP est explicite : les pools ne sont pas un mécanisme de sécurité, car ils ne fournissent pas une séparation totale, par exemple tous les pools utiliseraient une seule instance OPcache. C'est d'ailleurs ce partage d'OPcache qui fait un des intérêts du multisite Drupal, une façon de réduire la consommation mémoire en évitant de dupliquer le cache d'opcode par site, comme le confirme la documentation des cas d'usage du multisite. Nous avons détaillé ailleurs les réglages OPcache qui aident Drupal : gardez cette limite en tête si vous pensiez qu'un pool par site isole tout. Isoler les pools réduit le risque de contagion entre sites ; cela ne remplace pas une isolation de type conteneur.
access.log, slowlog et le repérage par pool
Chaque pool FPM peut avoir son propre fichier access.log et son propre slowlog, avec un format de log qui peut inclure le nom du pool via %n, selon le manuel PHP-FPM. En cas d'incident, vous identifiez le site en cause sans croiser des journaux mélangés entre plusieurs sites.
Prioriser les sites critiques et gérer le back-pressure
Techniques de priorisation
Une fois les pools séparés, plusieurs leviers permettent de donner la priorité au site qui compte le plus. La directive de pool process.priority fixe la priorité nice(2) du processus de travail de ce pool, de -19 (priorité la plus élevée) à 20 (priorité la plus basse), d'après le manuel PHP-FPM. Attention : une directive globale du même nom existe aussi pour le processus principal, et non pour un pool ; les deux ne se confondent pas. Vous pouvez également différencier le pm de chaque pool, en réservant plus de processus au site prioritaire, et réserver certains cœurs via cpuset au site critique. Ces leviers relèvent de PHP-FPM et du système : aucune documentation officielle de Drupal ne décrit de mécanisme de priorisation applicative entre les sites d'une même installation multisite.
Back-pressure : request_terminate_timeout
Pour éviter qu'une requête lente ne monopolise un processus au détriment des autres visiteurs du même site, request_terminate_timeout fixe, par pool, un délai au-delà duquel la requête en cours est interrompue et son processus tué, précise le manuel PHP-FPM. C'est un filet de sécurité simple : une requête qui dépasse ce délai libère la place plutôt que de bloquer un worker indéfiniment.
Monitorer avant la saturation
Les signaux techniques à surveiller
pm.status_path active, par pool, une page de statut FPM accessible via une URI qui doit commencer par une barre oblique, selon le manuel PHP-FPM. Cette page affiche notamment le nombre de processus actifs et la longueur de la file d'attente des requêtes en attente d'un processus libre, deux indicateurs directs de la charge réelle d'un pool, précise la documentation du statut FPM. Associé au slowlog déjà mentionné, pm.status_path donne une vue pool par pool, exactement le niveau de granularité dont a besoin une plateforme multisite avant qu'un incident ne devienne visible pour les visiteurs.
Questions fréquentes
Un pool PHP-FPM par site isole-t-il complètement vos sites les uns des autres ?
Non. Un pool par site sépare la configuration, les quotas internes et les journaux, mais le manuel PHP précise que les pools ne constituent pas un mécanisme de sécurité à part entière : ils ne fournissent pas une séparation totale, et tous les pools partageraient par exemple une même instance OPcache. Pour une isolation plus stricte, il faut descendre au niveau système, avec les cgroups.
Quelle directive limite la mémoire consommée par un site sur son pool ?
php_admin_value[memory_limit], réglée dans la configuration du pool du site concerné. Une valeur admin ne peut pas être surchargée par le script via ini_set(), ce qui en fait une limite dure, pas une suggestion.
Comment repérer rapidement quel site sature le serveur ?
En activant pm.status_path sur chaque pool : la page de statut affiche le nombre de processus actifs et la file d'attente de chaque pool. Combinée aux journaux slowlog séparés par pool, elle désigne le pool en cause sans avoir à croiser les journaux.
Peut-on prioriser un site Drupal critique au niveau de Drupal lui-même ?
Pas nativement : aucune documentation officielle de Drupal ne décrit de mécanisme de priorisation entre sites d'une installation multisite. Les leviers disponibles, process.priority de pool, un pm différencié, un cpuset dédié, se posent au niveau de PHP-FPM et du système, pas dans la configuration Drupal.
Si votre plateforme Drupal multisite héberge plusieurs sites sur le même serveur PHP sans pools séparés, un incident sur l'un peut dès aujourd'hui en affecter d'autres sans que vous le voyiez venir. Demander un diagnostic reste le point de départ pour faire l'état des lieux de votre isolation actuelle et de vos quotas de ressources.