Il s'agissait d'un bogue dans apache pour mpm-event et mpm-worker, que vous rencontrez peut-être encore :
https://bz.apache.org/bugzilla/show_bug.cgi?id=53555
Le bogue se situe au niveau de l'augmentation et de la diminution du nombre de processus du serveur.
Le véritable "correctif" est en place dans les versions plus récentes, je pense, mais vous pouvez facilement contourner ce problème en suivant les conseils de ScottE dans le commentaire 12 du rapport de bugzilla. Dans ce commentaire, il dit "...Si nous fixons MinSpareThreads et MaxSpareThreads à MaxRequestWorkers (pour qu'Apache n'essaie pas de réduire les processus), le problème disparaît (comme prévu, mais valide (peut-être ?) que cela a à voir avec la réduction d'échelle d'Apache). ..."
(c'est moi qui souligne)
J'ai réussi à résoudre ce problème en réglant MaxSpareThreads = MaxRequestWorkers. ET en comprenant la relation entre les travailleurs, les threads, les serveurs, etc. Ce dernier point est très important. Les directives de base nécessaires pour le MPM d'événements sont simples. La façon de faire évoluer votre service est de fixer les deux valeurs ci-dessus au nombre de connexions de clients que vous voulez supporter. Tout le reste fonctionnera. Voir : http://httpd.apache.org/docs/2.2/mod/worker.html
IMHO : Si votre objectif est de permettre à Apache d'adapter le nombre de processus "serveur" en fonction des besoins, vous ne devriez peut-être pas utiliser les modèles d'événement ou de travailleur. Calculez le nombre de connexions clients que vous souhaitez autoriser, puis configurez-les pour qu'elles soient toujours disponibles. Sinon, mettez à jour votre apache, ou configurez la solution de contournement décrite ci-dessus et contentez-vous en.
Bonne chance !
