Auteur Sujet: Problème avec Apache2 Event: les proces n'acceptent plus de nouvelles connexions  (Lu 11150 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
J'ai un petit problème avec Apache2 Event, pour un serveur miroir à forte audience (contenu statique)

C'est une question pour ceux qui connaissent bien Apache2, mais je commence par décrire un peu Apache Event pour ceux qui vont tomber sur cette discussion :

Le moteur (MPM) event est le serveur web haute performance d'Apache, concurrent de Nginx. Il implèmente un serveur hybride multi-processus et multi-threads. Contrairement aux autres serveurs web d'Apache qui imposent de réserver un couple processus enfant/thread pour attendre les données en provenance du client, Apache2 Event ne nécessite plus de thread de travail dédié pour les "Connexions asynchrones". Concrètement seule les connexions a qui le serveur envoi réellement des données utilisent couple processus enfant/thread.
Les connexions qui sont en pause (tampon d'écriture TCP plein ou connexion internet du client trop lente), celles qui Keep-alive (en attendant une autre demande sur la même connexion TCP) ou celles qui court de fermeture progressive, n'utilisent plus de thread de travail dédié.

Vous allez me dire qu'un problème peut se produire : Que se passe-t-il si un processus enfant, capable de gérer 100 connections a qui le serveur envoi réellement des données a 200 connexions en attente (Connexions asynchrones) qui se réveillent simultanèment ? Pour minimiser les effets de ce problème, le Apache2 event utilise deux méthodes :
- il limite le nombre de connexions simultanées par thread en fonction du nombre de processus inactifs;
- si tous les processus sont occupés, il ferme des connexions permanentes, même si la limite de durée de la connexion n'a pas été atteinte. Ceci autorise les clients concernés à se reconnecter à un autre processus possèdant encore des threads disponibles.

Pour limiter le nombre de connexions, c'est la Directive AsyncRequestWorkerFactor. Cette directive permet de personnaliser finement la limite du nombre de connexions par thread. Un processus n'acceptera de nouvelles connexions que si le nombre actuel de connexions (sans compter les connexions à l'état "closing") est inférieur à : ThreadsPerChild + (AsyncRequestWorkerFactor * nombre de threads inactifs)

Voici mon problème avec Apache2 event :

La configuration utilisée :

<IfModule mpm_event_module>
        StartServers             2
        ServerLimit              100
        MinSpareThreads          128
        MaxSpareThreads          512
        ThreadLimit              128
        ThreadsPerChild          100
        MaxRequestWorkers        1600
        MaxConnectionsPerChild   0
        AsyncRequestWorkerFactor 2
</IfModule>

- StartServers : Nombre de processus enfants du serveur créés au démarrage. Apache va rapidement créer d'autres processus enfants, si la demande est suffisamment forte.
- ServerLimit : Limite supérieure de la définition du nombre de processus. J'utilise la formule ServerLimit = MaxRequestWorkers / 16 pour le définir, mais je ne suis pas sur de moi (je me demande si le mettre à MaxRequestWorkers / ThreadsPerChild n'est pas suffisant.
- MinSpareThreads : Nombre minimum de threads inactifs qui seront disponibles pour pouvoir traiter les pics de requêtes
- MaxSpareThreads : Nombre maximum de threads inactifs. Permet de libérer de la RAM en réduisant les enfants inutiles, après un pic momentané de trafic.
- ThreadLimit : Max de ThreadsPerChild => Le nombre de threads maximum que l'on peut définir par processus enfant. Il est possible de modifier ThreadsPerChild par un simple reload jusqu'à ThreadLimit. Pour modifier ThreadLimit un restart est nécessaire (donc coupure des connexions en cours)
- ThreadsPerChild : Nombre de threads créés par chaque processus enfant (ThreadsPerChild est < ou = à ThreadLimit)
- MaxRequestWorkers : Nombre maximum de connexions pouvant être traitées simultanèment. Il est inutile de mettre MaxRequestWorkers > ThreadsPerChild * ServerLimit.
- MaxConnectionsPerChild : Limite le nombre de connexions qu'un processus enfant va traiter au cours de son fonctionnement. Utile en cas de fuites accidentelles de mémoire.
- AsyncRequestWorkerFactor : Permet de personnaliser finement la limite du nombre de connexions par thread. Un processus n'acceptera de nouvelles connexions que si le nombre actuel de connexions (sans compter les connexions à l'état "closing") est inférieur à: ThreadsPerChild + (AsyncRequestWorkerFactor * nombre de threads inactifs)

Cette configuration est en théorie capable de servir 1600 clients actif simultanèment et 1600 * 2 clients inactif qui attendent que le buffer se vide, soit au total 4800 connexions, sans compter les connexion en cour de fermeture, qui sont en bonus.

Mon problème avec Apache2 Event :

Quand un processus enfant (100 connexions activers par processus enfant dans mon cas) ne va plus accepter de nouvelles connexions, il lui reste de nombreux threads inactifs, c'est normal, il faut des threads inactifs en réserve, pour les connexions Connexions asynchrones qui peuvent se réveiller à n'importe quel moment.

Problème, un nouveau processus enfant n'est crée que si il y a moins de MinSpareThreads threads inactifs (128 dans mon cas).

En réalité, dès que la charge augmente, de nombreux processus enfants ne vont plus accepter de connexions, mais en additionnant les threads inactifs de tous les processus enfants, on est bien au-delà à de 128 threads inactifs, donc apache n'augmente pas le nombre d'enfants. Et il arrive un moment où tous les enfants refusent les nouvelles connexions. A ce moment là il est impossible d'établir une nouvelle connexion. Le service est indisponible.

J'ai donc tenté de jouer avec AsyncRequestWorkerFactor, j'ai passé le ratio à 1.3, ce qui limite encore plus le nb de connexion => Le blocage arrive encore plus vite.
J'ai passé le ratio à 4, cela repousse le blocage (il faut plus de charge pour arriver dans la situation de blocage où tous les process enfants n’accepte plus de nouvelles connexions)
J'ai passé le ratio à 8 et là c'est parti en vrille : il n'y a toujours pas de création de nouveaux process enfant et on a des enfants qui se retrouvent en famine : des connexions inactives basculent en active alors qu'il y a déjà 100 connexions actives servies par cet enfant.

J'ai réalisé un petit gif animé pour montrer le phénomène : (AsyncRequestWorkerFactor = 4 dans le gif ci-dessous)


- Vert = process enfant qui accepte des connexions
- Jaune = process enfant en cour de suppression (Gracefully finishing) : Il n'accepte plus de nouvelles connexions et il reste en vie jusqu'à ce que les connexions en cours se terminent, et cela peut prendre plusieurs heures, si le client à une connexion à petit débit et qu'il souhaite télécharger des gros fichiers. ici on a le PID 5972 qui a 2 connexions encore en vie.
- Rouge =  process enfant qui refuse les nouvelles connexions.

Je n'ai pas de copie d'écran avec aucun process en vert, cas dans ce cas là la page ne s'affiche pas  : ( Le cas s'est produit plusieurs fois entre les copies d'écran présentées dans le GIF.


Voici les différentes copie d'écran de ce GIF, par heure de la copie d'écran : 6h47 - 7h55 - 7h58 - 7h59 - 8h01 - 8h02 - 8h04 - 8h06 - 8h10 - 8h13 (toutes prises le 22 mars 2016)

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Pour rappel, un processus enfant n'acceptera de nouvelles connexions que si le nombre actuel de connexions (sans compter les connexions à l'état "closing") est inférieur à: ThreadsPerChild + (AsyncRequestWorkerFactor * nombre de threads inactifs)
Problème, je note que certains processus enfant restent fermés aux nouvelles connexions alors que le thereads Idl est important.
J'ai l'impression que quand un processus enfant se ferme aux nouvelles connexions, c'est pour un bon moment, et qu'il ne ré-ouvre pas quelques centaines de ms plus tard, quand il a moins de connexions actives.

Un exemple concret : on a 1344 connexions simultanées au serveur Apache (155 actives et 1189 inactives) et AsyncRequestWorkerFactor = 4
- PID 643 est fermé alors qu'il 243 connexions (3 actives et 240 inactives, dont 40 en cours de fermeture)
- PID 5973 est en cours de fermeture Gracefully finishing, il ne compte plus, il faut ignorer sa présence.
- PID 28062 est fermé alors qu'il 213 connexions (0 active et 213 inactives, dont 27 en cours de fermeture)
- PID 29225 accepte les connexion et il a encore pas mal de place : il a 87 connexions (0 active et 87 inactives, dont 8 en cours de fermeture)
- PID 25231 accepte les connexion mais il est bien rempli : il a 218 connexions (0 active et 218 inactives, dont 36 en cours de fermeture)
- PID 25232 est fermé alors qu'il 172 connexions (46 actives et 126 inactives, dont 24 en cours de fermeture)
- PID 28165 est fermé alors qu'il 209 connexions (24 actives et 185 inactives, dont 40 en cours de fermeture)
- PID 952 est fermé à juste titre car il ne lui reste que 18 Threads disponible : il a 200 connexions (82 actives et 118 inactives, dont 32 en cours de fermeture)

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Le contournement que j'ai trouvé :

J'ai trouvé une solution provisoire : demander à Apache2 d'avoir beaucoup de connexions en réserve.

J'ai fait passer MinSpareThreads de 25 à 800 : Cela oblige Apache2 à avoir un minimum de 800 threads inactifs. Avec ça, je n'ai aucun problème. J'ai toujours des processus enfant qui se ferment aux nouvelles connexions, mais il y a du stock de processus enfant pour prendre la relève.

La modification m'a oblige à modifier MaxSpareThreads, qui passe de 75 à 1200.

J'ai remis AsyncRequestWorkerFactor = 2, sa valeur recommandée (cela me semble pertinent après mes expérimentations)

Voici ce que cela donne au niveau des stats Munin :
   

On remarque que à certains moment, il n'y a pas 1600 MaxRequestWorkers : C'est à cause de process enfant en Gracefully finishing : Il bloquent un processus enfant tant qu'au moins une connexion est active. C'est le cas la nuit lors du reload du serveur pour la rotation des logs et aussi à 15h00, juste après un pic qui avait obligé a créer 1300 connexions (la preuve que MinSpareThreads fonctionne bien : quand j'ai moins de 800 threads inactifs, il en crée de nouveaux.

Si MaxSpareThreads est trop proche de MinSpareThreads, on va créer / killer des process enfant régulièrement, avec le risque de rendre inutilisable de process enfant plusieurs heures, car il reste une connexion active a faible débit.

L'erreur dans les log Apache2 dans le cas où des connexions bloquent des process en Gracefully finishing est :
AH00485: scoreboard is full, not at MaxRequestWorkers
=> Il faut donc augmenter MaxSpareThreads ou changer l'heure ou est réalisé le changement de log avec un reload.

L'erreur quand tous les process apache sont utilisés est :
AH00484: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
=> Il suffit d'augmenter MaxRequestWorkers avec éventuellement les autres paramètres qui vont avec (ServerLimit / ThreadsPerChild / ThreadLimit).


J'ai réalisé un petit gif animé avec MinSpareThreads = 800 et AsyncRequestWorkerFactor = 2 :


J'ai mis en rouge les process enfant qui refuse les nouvelles connexions
J'ai aussi mis en rouge les threads avec moins de 40 idle : cela signifie qu'ils ont beaucoup de connexions actives et peu de place si beaucoup se réveillent simultanèment.

Voici les différentes copie d'écran de ce GIF, par heure de la copie d'écran : 7h43 - 7h46 - 7h47 - 7h49 - 7h50 - 7h52 (toutes prises le 30 mars 2016)


Bref, si vous avez une solution autre que MinSpareThreads = 800, je suis preneur !

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Bref, si vous avez une solution autre que MinSpareThreads = 800, je suis preneur !

nginx ?  ;D

(désolé c’était trop tentant)

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
J'ai même hésité, mais là cela ressemble plus à un pb de configuration que je n'ai pas compris.

Je trouve très étonnant que les sites officiels ne donnent pas d'information de configuration recommandée pour les serveurs à forte charge, devant gérer des milliers de connexions simultanées.

J'ai regardés sur Internet, et certains mettent n'importe quoi dans leur configuration. Je n'ai toujours pas encore bien compris comment déterminer la bonne taille pour ServerLimit pour le MPM Event : ServerLimit = MaxRequestWorkers / 16 ou ServerLimit = MaxRequestWorkers / ThreadsPerChild ? (dans mon cas ThreadsPerChild = 100 donc ça change pas mal les choses)

Il y a étalement quelques optimisations à faire sur un linux récent :

La directive ListenBackLog est par défaut à 511 ce qui me semble pertinent. (File d'attente, quand la limite MaxRequestWorkers est atteinte, toute tentative de connexion sera normalement mise dans une file d'attente, et ceci jusqu'à un certain nombre dépendant de la directive ListenBacklog.)
Problème, Linux bride ListenBackLog à 128 :

$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128

Je conseille mettre au moins 512, ce qui permet que ce soit Apache2 qui dépasse la limite : c'est visible de manière claire dans les log et cela évite d'impacter tout le système d'exploitation, si il y a d'autres serveurs qui tournent.

Il faut également modifier SOMAXCONN : Limit of socket listen() backlog, known in userspace as SOMAXCONN. Defaults to 128. The value should be raised substantially to support bursts of request.

cat /proc/sys/net/core/somaxconn
128


Il faut donc rajouter ces deux lignes dans le fichier /etc/sysctl.conf :
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 512

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Dans le même style que kgersen: utilise mpm-worker
Même résultat que l'event, mais beaucoup plus robuste / testé / utilisé / etc

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Je trouve très étonnant que les sites officiels ne donnent pas d'information de configuration recommandée pour les serveurs à forte charge, devant gérer des milliers de connexions simultanées.

parce que, peut-être, personne n'utilise "ca" a forte charge pour de vrai ?
T'as un exemple de site connu et a forte charge qui utilise MPM-Event ?

Et si on va dans cette direction:

Repense le probleme: c'est pour un miroir de contenu statique ? ... Apache n'a rien à  faire en frontal de toute façon... met un nginx (ou un Varnish ou un ATS) devant ton serveur Apache.

nginx devant Apache c'est très fréquent comme combo.
nginx en frontal pour le contenu statique, la répartition de charge, le cryptage, etc et un ou des Apache en backend pour le dynamique.

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Le MPM Event est effectivement le dernier MPM développé par Apache. Il est stable depuis Apache 2.4 (sortie en 2012) et il a été conçu pour répondre aux besoins adressés jusque-là par nginx (Nginx a de meilleurs performances que Apache2 MPM prefork ou Apache2 MPM worker)

C'est le MPM par défaut (en cas d'installation d'Apache2 sans PHP) depuis Ubuntu 13.10

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Je n'ai pas suivit vos idées de changer de MPM ou de serveur web et je me suis mis en-tête de comprendre où est le pb dans ma conf.

Je n'ai pas terminé tous mes tests (je ferais un tutoriel), mais je vois que j'ai dit beaucoup de choses fausses, comme celle-ci :
Quand un processus enfant (100 connexions activers par processus enfant dans mon cas) ne va plus accepter de nouvelles connexions, il lui reste de nombreux threads inactifs, c'est normal, il faut des threads inactifs en réserve, pour les connexions Connexions asynchrones qui peuvent se réveiller à n'importe quel moment.

Problème, un nouveau processus enfant n'est crée que si il y a moins de MinSpareThreads threads inactifs (128 dans mon cas).

En réalité, dès que la charge augmente, de nombreux processus enfants ne vont plus accepter de connexions, mais en additionnant les threads inactifs de tous les processus enfants, on est bien au-delà à de 128 threads inactifs, donc apache n'augmente pas le nombre d'enfants. Et il arrive un moment où tous les enfants refusent les nouvelles connexions. A ce moment là il est impossible d'établir une nouvelle connexion. Le service est indisponible.

C'est faux : j'ai fini par comprendre que le serveur Apache ne répondait plus, alors qu'il lui restait des serveurs qui acceptait des connexions.

Voici la preuve que les connexions idle des processus enfant qui n'acceptent plus de connexions ne sont plus comptées : j'ai fait une copie d'écran ce matin à 7h55 et 7secondes puis à 7h55 et 26 secondes. Configuration : MinSpareThreads = 200  /  MaxSpareThreads = 500  /  ThreadsPerChild = 50  /  ServerLimit = 100  /  MaxRequestWorkers = 3000

Ici on note que à gauche il y a 316 idle en comptant les processus enfant qui n'acceptent plus de connexions, mais seulement 212 (47+23+43+36+42+21) si on compte uniquement les processus enfant qui acceptent des connexions.
On remarque sur la droite que quelques secondes après, Apache à crée un nouveau processus enfant, que j'ai mis en jaune => cette création est liée au fait que MinSpareThreads est passé < 200, donc seul processus enfant qui acceptent de connexions sont comptés.



Mettre MinSpareThreads à 800 permettait de réduire très fortement le pb de non réponse, mais c'est un effet de bord.

J'ai acquis la certitude que les pb de non réponse sont lié à ThreadsPerChild : On peut être tenté d’augmenter ce paramètre pour augmenter la capacité du serveur mais j'ai testé sur plusieurs jours les valeurs ThreadsPerChild = 150 ; ThreadsPerChild = 100 ; ThreadsPerChild = 50 et plus il est élevé, plus les occurrences se présentent.

Le pb de non réponse ne sont pas pendant les pic de trafic en connexions, ni pendant les pic de trafic en débit, ni pendant les pic de connexions actives simultanées : non, j'ai fini par comprendre que Apache ne répond plus quand le ratio entre les connexions totales et les connexions actives augment fortement.

A gauche le ratio est de 1,69 et à droite le ratio est de 5,13 pour une même configuration (MinSpareThreads = 800  /  MaxSpareThreads = 1300  /  ThreadsPerChild = 150  /  ServerLimit = 100  /  MaxRequestWorkers = 3000)
Il n'est pas possible de faire de copie d'écran quand Apache ne répond pas, mais je pense que le ratio dépasse 6.


Je teste actuellement ThreadsPerChild = 25, la valeur par défaut qui je suppose doit ne surtout pas être augmentée et qu'il faut au contraire incrèmenter fortement ServerLimit pour un serveur avec forte charge - sa configuration par défaut est seulement de 16.

Cela génère beaucoup de processus enfant qui n'acceptent plus de connexions, mais Apache répond (MinSpareThreads = 100  /  MaxSpareThreads = 300  /  ThreadsPerChild = 25  /  ServerLimit = 100  /  MaxRequestWorkers = 2500)


- Vert = process enfant qui accepte des connexions
- Jaune = process enfant en cour de suppression (Gracefully finishing) : Il n'accepte plus de nouvelles connexions et il reste en vie jusqu'à ce que les connexions en cours se terminent, et cela peut prendre plusieurs heures, si le client à une connexion à petit débit et qu'il souhaite télécharger des gros fichiers.
- Rouge =  process enfant qui refuse les nouvelles connexions.

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Avez-vous une idée pour :
- Suivre la taille de la pile sous Linux
- Résoudre le problème de “Resource temporarily unavailable” lors de la création d'un thread ?



Baisser le ThreadsPerChild à 25 est un petit contournement et comme j'ai eu de nouveau des absence de réponse, j'ai upgardé vers Apache 2.4.18.

Et je pense qu'il ont corrigé le bug qui faisait que mon problème n'écrivait rien dans les log, car maintenant mes log Apache décrivent le pb rencontré :

$ tail /var/log/apache2/error.log
[Wed May 18 10:51:01.755101 2016] [mpm_event:alert] [pid 1205:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:53:05.855464 2016] [mpm_event:alert] [pid 1234:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:53:29.879633 2016] [mpm_event:alert] [pid 1265:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:53:55.904627 2016] [mpm_event:alert] [pid 1295:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:53:57.906764 2016] [mpm_event:alert] [pid 1338:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:54:09.926505 2016] [mpm_event:alert] [pid 1364:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:54:26.934650 2016] [mpm_event:alert] [pid 1391:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:55:03.971183 2016] [mpm_event:alert] [pid 1561:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:56:16.042420 2016] [mpm_event:alert] [pid 1620:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread
[Wed May 18 10:56:21.048176 2016] [mpm_event:alert] [pid 1660:tid 140255563212544] (11)Resource temporarily unavailable: apr_thread_create: unable to create worker thread

C'est clairement Resource temporarily unavailable: apr_thread_create: unable to create worker thread qui crée des indisponibilités sur mon serveur.

Le nombre de threads en cours d'exécution :
$ ps -elfT | wc -l
656


La limite du nombre de threads en cours d'exécution :
$ ulimit -u
63676

$ cat /proc/sys/kernel/threads-max
127353


Donc la cause semble ailleurs.

Voici les autres limites :
$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63676
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 63676
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

$ cat /proc/sys/vm/max_map_count
65530

$ cat /proc/sys/kernel/pid_max
32768

$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog
1024

$ cat /proc/sys/net/core/somaxconn
512


Il y a de la mémoire : 16  Go de ram et Apache est seul sur le PC (en plus des services de base)
$ free -m
      total  utilisé  libre partagé tamp/cache disponible
Mem:  16015      359     90       4      15566      15521
Swap:  7628        9   7619


La configuration de Apache/2.4.18 utilisé avec le MPM: event :
$ cat /etc/apache2/mods-enabled/mpm_event.conf

<IfModule mpm_event_module>
   StartServers       9
        ServerLimit              150
   MinSpareThreads       145
   MaxSpareThreads       435
   ThreadLimit       25
   ThreadsPerChild       25
   MaxRequestWorkers    2500
   MaxConnectionsPerChild   0
   AsyncRequestWorkerFactor 2
</IfModule>


Sur Unix & Linux Stack Exchange, j'ai cherché ce qui pouvait provoquer “Resource temporarily unavailable” lors de la création d'un thread.

Faute de trouver, je me demande si ce n'est pas la pile, qui a une taille Max de 8 Mb :
$ ulimit -s
8192


Si vous avez des idées, je suis preneur !

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
Comme le dit ton lien, tu n'utilises pas systemd, par hasard ?

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Bien vu, j'avais zappé les réponses et c'est une nouveauté introduite récemment dans systemd qui limite le nombre maximum de tâches qui peuvent être créés dans l'unité à 512 par défaut.
Pour Ubuntu, c'est introduit à partir d'Ubuntu 16.04

Le man :
TasksMax=N
Specify the maximum number of tasks that may be created in the unit. This ensures that the number of tasks accounted for the unit (see above) stays below a specific limit. If assigned the special value "infinity", no tasks limit is applied. This controls the "pids.max" control group attribute. For details about this control group attribute, see pids.txt[4].

Implies "TasksAccounting=true". The system default for this setting may be controlled with DefaultTasksMax= in systemd-system.conf.


Pour ne plus avoir cette limitation, il suffit d'éditer /etc/systemd/system.conf et de remplacer #DefaultTasksMax=512 par DefaultTasksMax=infinity

Ce que donne systemctl status apache2 avant la modification :


$ systemctl status apache2
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: active (running) since mer. 2016-05-18 06:22:18 CEST; 6h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 16760 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
  Process: 1148 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
    Tasks: 487 (limit: 512)
   CGroup: /system.slice/apache2.service
           ├─  481 /usr/sbin/apache2 -k start
           ├─  863 /usr/sbin/apache2 -k start
           ├─ 1221 /usr/sbin/apache2 -k start
           ├─ 1226 /usr/sbin/apache2 -k start
           ├─ 1373 /usr/sbin/apache2 -k start
           ├─ 1734 /usr/sbin/apache2 -k start
           ├─ 3180 /usr/sbin/apache2 -k start
           ├─ 6791 /usr/sbin/apache2 -k start
           ├─ 7611 /usr/sbin/apache2 -k start
           ├─10271 /usr/sbin/apache2 -k start
           ├─16813 /usr/sbin/apache2 -k start
           ├─16818 /usr/sbin/apache2 -k start
           ├─16920 /usr/sbin/apache2 -k start
           ├─17925 /usr/sbin/apache2 -k start
           ├─20430 /usr/sbin/apache2 -k start
           ├─22225 /usr/sbin/apache2 -k start
           ├─24790 /usr/sbin/apache2 -k start
           ├─31388 /usr/sbin/apache2 -k start
           └─31576 /usr/sbin/apache2 -k start

mai 18 06:22:15 ubuntu systemd[1]: Starting LSB: Apache2 web server...
mai 18 06:22:15 ubuntu apache2[1148]:  * Starting Apache httpd web server apache2
mai 18 06:22:18 ubuntu apache2[1148]:  *
mai 18 06:22:18 ubuntu systemd[1]: Started LSB: Apache2 web server.
mai 18 10:05:15 ubuntu systemd[1]: Reloading LSB: Apache2 web server.
mai 18 10:05:15 ubuntu apache2[16760]:  * Reloading Apache httpd web server apache2
mai 18 10:05:15 ubuntu apache2[16760]:  *
mai 18 10:05:15 ubuntu systemd[1]: Reloaded LSB: Apache2 web server.


Après la modification, (limit: 512) n’apparaît plus.