Question mkdir: “plus d'espace disponible sur le périphérique” sur des dossiers spécifiques après qu'Apache Tomcat ait atteint ul-fichier max.


La question:

J'ai un tomcat qui exécute une application java qui accumule parfois des handles de socket et atteint le ulimit que nous avons configuré (à la fois soft et hard) pour max-open-files, soit 100K. Lorsque cela se produit, le java semble être toujours en vie, mais nous ne pouvons plus y accéder.

Cependant, ma question concerne un phénomène étrange qui accompagne cette situation: Je ne peux pas mkdir dans le dossier tomcat.

[root@server /opt/apache-tomcat-7.0.52]# mkdir some_folder
mkdir: cannot create directory `some_folder': No space left on device

En fait, je reçois la même erreur sous plusieurs dossiers différents situés sous /opt, mais pas sous /opt directement, et non - par exemple - sous /opt/apache-tomcat-7.0.52/logs.

Je ne peux pas l'expliquer pour la vie de moi, et ne peut résoudre en utilisant init 6. Toutes les suggestions sur la façon de résoudre le problème et de pouvoir mkdir encore sans redémarrage?


Quelques indications et indices que j'ai rassemblés:

La configuration est CentOS 6.5 fonctionnant sous AWS avec ledit disque tomcat monté à partir d’un volume EBS.

Fonctionnement df -h montre que le disque n'est évidemment pas plein:

[root@server ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            9.9G  3.6G  5.9G  38% /
none                  121G     0  121G   0% /dev/shm
/dev/xvdc            1008G  197G  760G  19% /mnt/eternal

Contenu de /etc/fstab (qui, pour une raison quelconque, utilise un montage double - je ne sais pas pourquoi):

/dev/xvdc       /mnt/eternal    ext4    defaults        0 0
/mnt/eternal    /opt    ext4    defaults,bind   0 0

Et des lignes appropriées de mount:

/dev/xvdc on /mnt/eternal type ext4 (rw)
/mnt/eternal on /opt type none (rw,bind)

Fonctionnement df -i ne fait pas allusion à quelque chose de mauvais (et est similaire à un système en bonne santé):

[root@server ~]# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/xvda1            655360   78245  577115   12% /
none                 31549847       1 31549846    1% /dev/shm
/dev/xvdc            67108864   12551 67096313    1% /mnt/eternal

Fonctionnement sysctl fs.file-nr donne ce résultat qui est évidemment élevé mais qui semble loin de la limite:

[root@server ~]# sysctl fs.file-nr
fs.file-nr = 101632     0       25087252

Fonctionnement find /proc | wc -l résultats 62497876 (62M), qui pourrait atteindre certaines limites de l'OS; sur un système sain similaire, il ressemble plus à 1800000 (1,8M).

Le sous-dossier très occupé semble être /proc/<my-java-pid>/task (~ 62 millions d’articles contre environ 1,7 million sur le système en bonne santé). Ceci est probablement juste le reflet de mes 100K fds (x2, pour fds et fdinfos) sur plus de 300 dossiers de "tâches" individuels.

Cela apparaît à la fin de mon fichier dmesg (mon pid java dans cet exemple est 105940) - je ne sais pas comment cela pourrait se rapporter:

INFO: task java:105940 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java          D 0000000000000008     0 105940      1 0x00000080
 ffff88161ab55c88 0000000000000082 ffff88161ab55c18 ffffffff8109be4f
 ffffffff81ed28f0 ffff881e66360ae0 ffffffff8100bb8e ffff88161ab55c88
 ffff881e66361098 ffff88161ab55fd8 000000000000fb88 ffff881e66361098
Call Trace:
 [<ffffffff8109be4f>] ? hrtimer_try_to_cancel+0x3f/0xd0
 [<ffffffff8100bb8e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff810521c9>] ? mutex_spin_on_owner+0x99/0xc0
 [<ffffffff8151636e>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff8151620b>] mutex_lock+0x2b/0x50
 [<ffffffff8111c461>] generic_file_aio_write+0x71/0x100
 [<ffffffffa0121fb1>] ext4_file_write+0x61/0x1e0 [ext4]
 [<ffffffff81180d7a>] do_sync_write+0xfa/0x140
 [<ffffffff81096ca0>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff812292ab>] ? selinux_file_permission+0xfb/0x150
 [<ffffffff8121bd26>] ? security_file_permission+0x16/0x20
 [<ffffffff81181078>] vfs_write+0xb8/0x1a0
 [<ffffffff81181971>] sys_write+0x51/0x90
 [<ffffffff81517e2e>] ? do_device_not_available+0xe/0x10
 [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b

Je serais heureux de partager / fournir toute autre conclusion suggérée.

Secrètement, j'espère que la compréhension de ce comportement étrange éclairerait la pathologie à l'origine de tout ce gâchis. Mais, ce n'est que mon espoir privé :)


5
2018-02-16 00:43


origine


Alors qu'est-ce que la sortie d'un simple df montre? - Iain
Pas une explication, mais un autre point de données: nous avions l'habitude de voir la même chose périodiquement sur Ubuntu 12.04; c'était surtout sur un ensemble de serveurs fonctionnant sous VMWare avec un réseau de stockage SAN, mais également sur un invité KVM standard et sur certains invités AWS. Un système de fichiers entier présenterait ce comportement. Il était possible de toucher un fichier, mais pas de créer un répertoire. Editer un fichier avec vi serait aléatoire. Le correctif transitoire consistait à démonter / remonter le système de fichiers. Le correctif le plus robuste consistait à effectuer la mise à niveau vers un noyau de port arrière Trusty (3.13), à partir de la version 3.2.0 fournie avec Precise. Jamais trouvé la cause. - Craig Miskell


Réponses:


J'ai trouvé la réponse à ma question de "comment résoudre ce scénario". Je ne connais pas tous les détails de la façon dont cela a été créé, mais j'en sais suffisamment pour donner une réponse.

Réponse courte: démonter le disque, en cours d'exécution chkdsk -f dessus, et le montage arrière résout et empêche le problème de se reproduire. Alternativement, créer un nouveau disque (rappelez-vous que nous sommes sur AWS) et copier toutes les données sur le nouveau disque (rsync -a était ma maitrise de choix) et son utilisation pour remplacer le disque original résout et empêche également.


Réponse plus longue: le système de fichiers du disque (ext4) semble avoir atteint un état instable lors de la création initiale de la capture instantanée du disque. Quand plus tard, l’instantané original de 200 Go avait été étendu (en utilisant resize2fs) à 1 To, il semble qu’en un sens, il se souvienne en interne de la taille originale de 200 Go, créant toutes sortes de phénomènes étranges qui aboutissent à ce que le système d’exploitation ne parvienne pas à fermer les poignées, ce qui permet à Tomcat d’atteindre sa limite de fichiers et se dégager.


Réponse la plus longue, avec un peu plus de détails sur le travail de détective: la percée a eu lieu lorsque cette pathologie s'est produite en parallèle sur deux configurations distinctes. En vérifiant tous les paramètres sur ces configurations et en comparant, nous avons réalisé que df -h sur le lecteur montrait ce résultat:

/dev/xvdc            1008G  197G  760G  19% /mnt/eternal

Cela n’a pas attiré notre attention auparavant, car le disque a encore beaucoup d’espace libre. Mais c'était exactement la même utilisation du disque (197G) sur les deux configurations, et cela n'a aucune raison de se produire. À partir de là, les choses se sont rapidement révélées. Comme mentionné précédemment, nos instances AWS ont été créées à partir d'une image avec une capture instantanée de disque de 200 Go, étendue sur des instances individuelles à l'aide de: resize2fs - généralement jusqu'à la taille maximale de 1 To. Nous avons enfin pu recréer un "mauvais état" en lançant une nouvelle instance, en le redimensionnant à 1 To et en créant un gros fichier de 300 Go. Lorsque cela a été fait, le système n'a pas gelé, mais il a présenté le même comportement étrange:

/dev/xvdc            1008G  197G  760G  19% /mnt/eternal

Et cela quand il y avait clairement plus de 197 Go de données sur le disque. Nous avons donc essayé les deux méthodes mentionnées ci-dessus (chkdsk et recréer le disque) sur deux configurations propres et sur chacune d’elles, le comportement étrange n’apparaissant plus.

Notre meilleure hypothèse est qu'à un moment donné, lors de la création de l'AMI, quelque chose n'allait pas dans le processus de capture instantanée - très probablement parce que nous avions pris une "capture instantanée sans reprise" (bien que nous ne l'ayons généralement pas, et je n'ai aucune preuve à l'appui J'espère donc que nos DevOps ne se fâchent pas contre moi pour l'avoir blâmée sans raison!). Dans l'ensemble, une expérience intéressante.


4
2018-03-10 20:57



Je peux confirmer que cela se produit même avec un instantané après le redémarrage. - Sharmila
Intéressant! Pouvez-vous décrire le processus qui vous a conduit à une pathologie similaire et quelles ont été vos découvertes? - Yonatan
En fait, j’ai trouvé que le problème était quelque chose de différent, même si j’avais eu aussi l’erreur autour du même point frontière. Le vrai problème était que le nombre d'inodes était terriblement bas comparé à ce que j'avais dans ma machine de développement. Par conséquent, lorsque le système décompressait une énorme archive contenant de nombreux fichiers, tous les inodes étaient épuisés avant même que la moitié du disque ne soit remplie. Le reformatage du disque avec la provision pour plus d'inodes a aidé. Je pense quelque chose comme mkfs.ext4 -N _number_of_inodes_needed_ /dev/_partition_name_ - Sharmila


Dans la plupart des cas (évidemment pas dans votre cas), la raison en sera que vous manquez de iNodes.

Pour vérifier cette exécution df -i:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
[...]
                       25600   25600       0  100% /foo

Ici, vous pouvez voir que l'utilisation des iNodes est de 100%.

Mauvaise nouvelle, selon https://superuser.com/questions/585641/changing-max-inode-count-number-in-ext3-filesystem-in-cent-os vous devez recréer votre système de fichiers avec l'option -i afin d'augmenter le nombre d'inodes.


4
2017-11-13 15:08



Savez-vous quelle est la raison pour laquelle les inodes sont complètement utilisés? - Bionix1441