Failed to allocate ...

Depuis quelques temps je constatais un message incongru lorsque je redémarrais Apache :

"Failed to allocate directory watch: Too many open files"

Cela n'empĂȘchait pas Apache de redĂ©marrer mais cela m'intriguais un peu. AprĂšs pas mal de recherches je suis tombĂ© sur la variable vm.max_map_count qui est, selon de nombreuses sources positionnĂ©e trop bas en standard et qu'il faut augmenter sĂ©rieusement. J'utilise pourtant beaucoup de machines Linux et je n'ai jamais rencontrĂ© ce type de problĂšme ? 
La valeur indiquée couramment est 262144 que j'ai un peu réduite et utilisée avec succÚs ci dessous.

J'avais essayĂ© de "forcer" un peu les valeurs de "nofile" dans le fichier /etc/security/limits.conf 
mais sans aucun succĂšs. 
AprÚs quelques recherches j'ai trouvé la bonne (?) variable kernel, visible par la commande :

sysctl -a | grep max_map_count

qui me retournait :  vm.max_map_count = 65530

En "forçant" un peu (euphĂ©misme) cette valeur Ă  131072 le message a disparu, mais la consommation mĂ©moire semble avoir augmentĂ©, et j'ai du "forcer" un peu sur la mĂ©moire de la VM.

Il faut donc impĂ©rativement surveiller la quantitĂ© de mĂ©moire utilisĂ©e aprĂšs ce type de manipulation.

Cette variable a trĂšs souvent une valeur insuffisante, le dĂ©faut de 65000 semble "gĂȘner" beaucoup d'applications telles que Docker, des bases de donnĂ©es .... Elasticsearch ... et divers autres logiciels. 
C'est la premiÚre fois que je tombe sur ce problÚme mais il semble assez courant au vu du nombre de mentions sur le web mais cela se manifeste souvent par des messages trÚs différents de celui qui m'a fait tiquer.

Il peut aussi ĂȘtre intĂ©ressant d'augmenter les valeurs des clefs suivantes : 
fs.inotify.max_queued_events = 16384 
fs.inotify.max_user_watches = 262144 
fs.inotify.max_user_instances = 2048