mkdir: "Pas d'espace laissé sur le périphérique" sur des dossiers spécifiques après Apache Tomcat atteint Max-file ulimit
La question:
J'ai une tomcat en cours d'exécution A Java application qui accumule parfois des poignées de prise et atteint l'ulimit que nous avons configuré (à la fois soft et dur) pour les fichiers max-ouvert, qui est 100k. Quand cela se produit, le Java semble toujours être en vie, mais nous ne pouvons plus y accéder.
Cependant, ma question concerne un phénomène bizarre qui accompagne cette situation: Je ne peux pas mkdir à l'intérieur du 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 qui résident 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 que déterminer en utilisant init 6. Toute suggestion sur la manière de résoudre le problème et de pouvoir mkdir à nouveau sans redémarrer?
Certains pointeurs et indices que j'ai rassemblés:
La configuration est CENTOS 6.5 exécutée sous AW avec ledit disque Tomcat monté à partir d'un volume EBS.
Fonctionnement df -h montre que le disque est évidemment pas complet:
[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 double montage - pas sûr 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 Net allusion à quelque chose de mauvais (et est similaire à un système sain):
[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 semble loin de la limite:
[root@server ~]# sysctl fs.file-nr
fs.file-nr = 101632 0 25087252
Fonctionnement find /proc | wc -l Retour 62497876 (62m), qui pourrait atteindre une limite de système d'exploitation; Sur un système sain similaire, il est plus comme 1800000 (1,8 m).
Le sous-dossier extrêmement occupé semble être /proc/<my-Java-pid>/task (~ 62m articles comparés à ~ 1,7 m sur le système sain). Ceci est probablement juste un reflet de ma FDS 100K (X2, pour FDS et FDInfos) sur 300 dossiers de "tâche" individuels.
Ceci apparaît à la fin de ma décharge DMESG (mon Java PID dans cet exemple est 105940) - Je ne sais pas comment cela pourrait être raconté:
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 comprendre ce comportement bizarre ferait la lumière sur la pathologie provoquant tout ce gâchis. Mais c'est juste mon espoir privé :)
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 est venu être, mais je sais assez pour éteindre une réponse.
Réponse courte: démonter le disque, exécuter chkdsk -f dessus et monter à nouveau résolvant et empêche le problème de se reproduire. Comme alternative, créant un nouveau disque (rappelez-vous que nous sommes sur AWS) et copier toutes les données sur le nouveau disque (rsync -a était ma commande de choix) et l'utiliser pour remplacer le disque d'origine résoue également et évite.
Réponse plus longue: Le système de fichiers de disque (EXT4) semble avoir atteint un état instable lorsque l'instantané du disque avait été créé à l'origine. Lorsque plus tard, l'instantané d'origine de 200 Go avait été étendu (en utilisant resize2fs) _) à 1 To, il semble que, dans un certain sens, il ne se souvenait pas de la taille initiale de 200 Go, créant toutes sortes de phénomènes étranges qui ont fini avec le système d'exploitation incapable de fermer les poignées, faisant ainsi que Tomcat atteigne sa limite de fichier, ayant ainsi tout l'enfer se déchaîner.
La réponse la plus longue, avec un peu plus des détails du travail de détective: la percée s'est produite lorsque nous avions eu cette pathologie en parallèle sur deux configurations distinctes. Vérifier tous les paramètres de ces configurations et comparer, nous avons compris que df -h sur le lecteur montrait ce résultat:
/dev/xvdc 1008G 197G 760G 19% /mnt/eternal
Maintenant, cela n'a pas attiré notre attention auparavant, car le disque a encore beaucoup d'espace. Mais c'était exactement le même usage de disque (197g) sur les deux configurations et qui n'a aucune raison de se produire. D'ici, les choses se sont rapidement déroulées. Comme mentionné précédemment, nos instances AWS ont été créées à partir d'une image qui possède un instantané de disque de 200 Go, qui est étendue sur des instances individuelles à l'aide de resize2fs - Habituellement à la taille maximale de 1 To. Nous avons finalement pu recréer un "mauvais état" en lançant une nouvelle instance, redimensionnant 1 To et créant un gros fichier de 300 Go. Lorsque cela a été fait, le système n'a pas gelé, mais il a montré le même comportement étrange:
/dev/xvdc 1008G 197G 760G 19% /mnt/eternal
Et que lorsqu'il y avait clairement plus que 197GB de données sur le disque. Nous avons donc essayé les deux méthodes mentionnées ci-dessus (Chkdsk et recréant le disque) sur deux configurations propres individuelles et sur chacun de ces comportements étranges n'apparaîtront plus.
Notre meilleure estimation est qu'à un moment donné, lorsque l'AMI a été créée, quelque chose s'est mal passé dans le processus d'instantané - probablement parce que nous avions pris un "instantané sans redémarrer" (bien que nous n'ayons généralement pas de preuve, et je n'ai aucune preuve à dos C'est là, alors j'espère que nos devops ne sont pas en colère contre moi pour la blâmer sans cause!). Dans l'ensemble, une expérience intéressante.
Dans la plupart des cas (évidemment pas dans votre cas), la raison sera que vous manquez d'inodes.
Pour vérifier cet exécution DF -I:
Filesystem Inodes IUsed IFree IUse% Mounted on
[...]
25600 25600 0 100% /foo
Ici, vous pouvez voir que l'utilisation d'inodes est de 100%.
De mauvaise nouvelle est, selon https://superuser.com/questions/585641/changeing-max-inode-count-number-in-ext3-filesystem-in-cen-os Vous devez re -Créez votre système de fichiers avec l'option -i afin d'augmenter le nombre d'inodes.