TL;DR: Ça grandit trop vite. Le Diable est dans les détails. Être vigilant pendant les migrations.

Depuis toujours, je suis confronté à des effets de seuil. Ça a d'abord été le nombre de serveurs maximum supporté par un switch simple (non configuré, sans vlan). Il a fallut passer aux switchs manageables, aux vlans (Merci Manu).

Puis, ça a été le nombre de connexions simultanées vers les serveurs de fichiers, puis le nombre de jobs gérable en trente secondes (oui, oui...)...

Dernièrement, le système complexe qu'est le centre de calcul et ses clusters a (re)commencé à diverger. On a ajouté beaucoup de noeuds de calcul (600 -> 900), donc beaucoup de coeurs (8000 -> 18 000), et la semaine dernière, dès que j'ajoutais un nouveau serveur de fichier, tout se cassais la gueule. Je le débranchais, ça revenait péniblement dans l'ordre. Au snif, un effet de seuil, quelque part autour de 1 000.

Les automounts se cassaient la gueule, sans raison apparente, un peu aléatoirement. Ou bien il n'était plus possible d'authentifier personne sur une machine en particulier... l'IDmap partait en charpie sur un autre fileserver... Les jobs plantaient parce que User does not exist...

Assez rapidement, localement sur chaque machine, j'avais trois coupables, mais pas toujours en même temps : unscd (le caching), nslcd (l'auth) et autofs (les automounts). Les trois pointant vers le serveur LDAP.

Serveur LDAP que je galère à stabiliser depuis quelques mois années. Du point de vue de la métrologie, il ne se passe jamais rien sur ce serveur. Calme plat. Et pourtant, j'ai toujours la désagréable impression qu'il répond mal, trop lentement, aux requêtes. Et tous les services qui en dépendent paraissent... congestionnés.

Après avoir cherché du côté du réseau, du recycle (sysctl) et ouvert plein de shakras, pas ça.

La SizeLimit du LDAP ? Pas suffisant.

Ulimits ? Ouvert en grand, et depuis longtemps...

Oh attends ?!

Que vois-je dans le log, furtivement : Too many open files. Mais je viens de vérifier mes ulimits !?! (Poukram! dirais-je, même, emporté par la fièvre)

Cette VM a migrée de Debian 7, 8, 9 puis 10. Y'aurait-il quelque chose que j'eusse loupé ?

Regardons-les, ces limites :

1
2
3
4
5
6
7

/etc/security/limits.conf
[...]
*  -     nofile   524288
*  -     nproc    65536
[...]
root  -  nofile   524288
root  -  nproc    65536

Okéé, ouvert en grand, disais-je. Côté système ? :

1
2

sysctl fs.file-max
fs.file-max = 1048576

Pas ça. Les connexions ouvertes :

1
2

netstat -a | grep ESTABLISHED | wc -l
1009

Autour de 1000, Ok. Ça matche avec les sockets :

1
2

ls -lh /proc/3135/fd | wc -l
1012

Et les limits du process, alors ? (par acquis de conscience) :

1
2
3
4

less /proc/3135/limits
[...]
Max open files            1024               1024               files
[...]

Mais ?! Je... ?! Gogole ? Gooogooole ?!

Au détour d'une longue perdition dans des articles sur OpenLDAP, cgroups et systemd, je trouve une perle (offline depuis). Dans les transitions à systemd, les limits sont passés d'un mode général (limits.conf et /limits.d/) à chacun son réglage, comme pour cgroups. Et mon OpenLDAP est revenu à "1024 Max open files", probablement lors de la dernière mise à jour majeure.

Autour de 1 000...

On ajoute le fichier kivabien à systemd :

1
2
3
4
5

/etc/systemd/system/slapd.service.d/override.conf
# override limits.conf et sysctl
[Service]
LimitNOFILE=262144
LimitNPROC=65536

On relance le service :

1
2
3
4
5
6

systemctl daemon-reload
systemctl restart slapd.service
less /proc/25894/limits
[...]
Max open files          262144             262144               files
[...]

Much better! Ça ronronne de nouveau, je peux ajouter mon nouveau serveur de fichiers.

Conclusion: Faut toujours chercher la p'tite bête. Il faut savoir poser les bonnes questions pour obtenir les bonnes réponses.