VFS: file-max limite 1231582 atteint
Je suis actuellement sous Linux 2.6.36 noyau, et je vois quelques erreurs aléatoires. Des choses comme
ls: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 23
Oui, mon système ne peut pas constamment exécuter un 'ls' de la commande. 🙁
Je note plusieurs erreurs dans mon dmesg:
# dmesg | tail
[2808967.543203] EXT4-fs (sda3): re-mounted. Opts: (null)
[2837776.220605] xv[14450] general protection ip:7f20c20c6ac6 sp:7fff3641b368 error:0 in libpng14.so.14.4.0[7f20c20a9000+29000]
[4931344.685302] EXT4-fs (md16): re-mounted. Opts: (null)
[4982666.631444] VFS: file-max limit 1231582 reached
[4982666.764240] VFS: file-max limit 1231582 reached
[4982767.360574] VFS: file-max limit 1231582 reached
[4982901.904628] VFS: file-max limit 1231582 reached
[4982964.930556] VFS: file-max limit 1231582 reached
[4982966.352170] VFS: file-max limit 1231582 reached
[4982966.649195] top[31095]: segfault at 14 ip 00007fd6ace42700 sp 00007fff20746530 error 6 in libproc-3.2.8.so[7fd6ace3b000+e000]
Évidemment, le fichier-max erreurs de l'air suspect, être groupés ensemble et récente.
# cat /proc/sys/fs/file-max
1231582
# cat /proc/sys/fs/file-nr
1231712 0 1231582
Qui semble aussi un peu bizarre pour moi, mais la chose est, il n'ya aucun moyen que j'ai de 1,2 million de fichiers ouverts sur ce système. Je suis le seul à l'utiliser, et il n'est pas visible à quiconque à l'extérieur du réseau local.
# lsof | wc
16046 148253 1882901
# ps -ef | wc
574 6104 44260
J'ai vu une partie de la documentation en disant:
fichier-max & file-nr:
Le noyau alloue les descripteurs de manière dynamique, mais il ne les libère pas.
La valeur dans le fichier de max indique le nombre maximal de fichiers gère que le noyau Linux va allouer. Lorsque vous obtenez beaucoup de messages d'erreur sur l'exécution de descripteurs de fichiers, vous pouvez augmenter cette limite.
Historiquement, les trois valeurs dans le fichier-nr indiqué le nombre de descripteurs de fichiers, le nombre de allouées, mais non utilisées des descripteurs de fichier, et le nombre maximum de descripteurs de fichiers. Linux 2.6 signale toujours 0 comme le nombre de descripteurs de fichiers -- ce n'est pas une erreur, cela signifie simplement que le nombre de descripteurs de fichiers correspond exactement au nombre de descripteurs de fichiers.
Tente d'allouer plus de descripteurs de fichiers que fichier-max sont rapportés avec printk, regarder "VFS: file-max limite atteinte".
Ma première lecture de ceci est que le noyau a un haut-le descripteur de fichier de fuite, mais je trouve cela très difficile à croire. Cela impliquerait que tout système en cours d'utilisation doit être réinitialisé chaque tellement souvent pour libérer les descripteurs de fichier. Comme je l'ai dit, je ne crois pas que ce serait vrai, car il est normal pour moi d'avoir des systèmes Linux rester en place pendant des mois (voire des années) à la fois. D'autre part, je ne peux pas croire que mon presque-système inactif est tenue de plus d'un million de fichiers ouverts.
Quelqu'un a une idée, que ce soit pour des corrections ou diagnostic supplémentaire? Je pourrais, bien sûr, il suffit de redémarrer le système, mais je ne veux pas que ce soit un problème récurrent à toutes les quelques semaines. Comme une mesure provisoire, que j'ai quitté Firefox, qui a été représentant près de 2000 lignes de lsof de sortie (!) même si je n'avais qu'une fenêtre est ouverte, et maintenant je peux exécuter la commande 'ls' de nouveau, mais je doute que ce sera corrigé le problème pour longtemps. (edit: Oups, a parlé trop tôt. Par le temps que j'ai terminé la saisie de cette question, le symptôme était/est de retour)
Merci d'avance pour toute aide.
Hm, je ne connaissais pas celui-là. Merci pour le pointeur, je vais poster là-bas à la place.
Que la documentation ne semble pas exacte, linux/fs/file_table.c les deux alloue et libère des descripteurs de fichier. Il ne vous ressemble a une fuite quelque part, et je ne suis pas sûr de la façon de mieux le repérer.
Avez-vous des "bizarre" trucs en cours avec le noyau? c'est à dire exécutez-vous une expérience ou inhabituelle modules, ou tout ce qui peut être à l'origine du noyau lui-même pour ouvrir (et erroniously pas fermer) handles de fichiers?
ext4 est horriblement peu fiables par rapport aux versions précédentes de ext. Juste revenir à l'ext3...
OriginalL'auteur Rick Koshi | 2011-02-13
Vous devez vous connecter pour publier un commentaire.
Je déteste laisser une question ouverte, de sorte qu'un résumé pour ceux qui la découvre.
J'ai reposter la question sur serverfault au lieu (cet article)
Ils n'étaient pas en mesure de trouver quoi que ce soit, en fait, mais j'ai fait un peu plus d'enquête et a finalement trouvé que c'est un véritable bug avec NFSv4, plus précisément du côté serveur, le code de verrouillage. J'ai eu un client NFS qui était en cours d'exécution d'un script de surveillance toutes les 5 secondes, à l'aide de rrdtool enregistrer certaines données à une monté en NFS fichier. Chaque fois qu'il courait, il verrouillé le fichier pour l'écriture, et le alloués par le serveur (mais à tort, n'a jamais publié) un descripteur de fichier ouvert. Ce script (plus un autre qui courait moins souvent) a permis à environ 900 ouvrir les fichiers consommée par heure, et deux mois plus tard, il a frappé à la limite.
Plusieurs solutions sont possibles:
1) l'Utilisation de NFSv3 à la place.
2) Arrêter l'exécution du script de surveillance.
3) Stocker les résultats de la surveillance en local au lieu de sur NFS.
4) Attendez que le patch à NFSv4 qui résout ce (Bruce disciplines qui m'ont envoyé un patch pour essayer, mais je n'ai pas eu le temps)
Je suis sûr que vous pouvez penser à d'autres solutions possibles.
Merci d'essayer.
Pouvez-vous détailler un peu comment vous troubleshooted ce problème? Comment avez-vous trouver le "coupable"?
OriginalL'auteur Rick Koshi