mkdir：Apache Tomcatがmax-file ulimitに達した後、特定のフォルダーで「デバイスにスペースが残っていません」
質問：
Javaアプリケーションを実行するTomcatがあり、ソケットハンドルが時々蓄積され、max-open-filesに対して（ソフトとハードの両方で）構成したulimit（100K）に達します。これが発生すると、 Javaはまだ生存しているようですが、アクセスできなくなりました。
しかし私の質問は、この状況に伴う奇妙な現象についてです：Tomcatフォルダー内ではmkdirできません。
[root@server /opt/Apache-Tomcat-7.0.52]# mkdir some_folder
mkdir: cannot create directory `some_folder': No space left on device
実際、/optの下にある複数の異なるフォルダーで同じエラーが発生しますが、/optの下では直接発生しません。たとえば、/opt/Apache-Tomcat-7.0.52/logsの下では発生しません。
私の人生ではそれを説明することはできません。解決できるのはinit 6のみです。問題を修正し、再起動せずに再度mkdirを使用できるようにするための提案はありますか？
私が集めたいくつかの指針と手がかり：
セットアップは、EBSボリュームからマウントされたTomcatディスクを使用してAWSで実行されているCentOS 6.5です。
df -hを実行すると、ディスクが明らかにいっぱいでないことがわかります。
[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
/etc/fstabの内容（これは、何らかの理由で、二重マウントを使用しています-理由は不明です）：
/dev/xvdc /mnt/eternal ext4 defaults 0 0
/mnt/eternal /opt ext4 defaults,bind 0 0
mountからの適切な行：
/dev/xvdc on /mnt/eternal type ext4 (rw)
/mnt/eternal on /opt type none (rw,bind)
df -iを実行しても、何か悪いことを示唆することはありません（健全なシステムに似ています）。
[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
sysctl fs.file-nrを実行すると、明らかに高い結果が得られますが、制限から離れているようです。
[root@server ~]# sysctl fs.file-nr
fs.file-nr = 101632 0 25087252
find /proc | wc -lを実行すると62497876（62M）が返され、OSの制限に達する可能性があります。同様の正常なシステムでは、1800000（180万）に近くなります。
非常に占有されているサブフォルダは/proc/<my-Java-pid>/taskのようです（正常なシステムでは約170万個に対し、約62万個のアイテム）。これはおそらく、300個を超える「タスク」フォルダを超える私の100K fds（x2、fdsとfdinfosの両方）を反映しているだけです。
これは私のdmesgダンプの最後に表示されます（この例のmy Java pidは105940です）-これがどのように関係しているのかわかりません：
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
他の提案された調査結果を共有/提供させていただきます。
ひそかに私はこの奇妙な行動を理解することがこの全体の混乱を引き起こしている病理に光を当てることを望みます。しかし、それは私の私的な希望です:)
「このシナリオを修正する方法」という私の質問に対する答えを見つけました。これがどのようになってきたのか詳細はわかりませんが、答えを出すには十分です。
短い答え：ディスクのマウントを解除し、chkdsk -fを実行し、再度マウントすると、問題が解決し、問題の再発を防ぎます。別の方法として、新しいディスクを作成し（AWSを使用していることを忘れないでください）、すべてのデータを新しいディスクにコピーし（rsync -aは私の選択したコマンドです）、それを使用して元のディスクを交換することも解決および防止します。
より長い答え：ディスクのスナップショットが最初に作成されたときに、ディスクファイルシステム（ext4）が不安定な状態に達したようです。後で200GBの元のスナップショットが（resize2fsを使用して）1TBに拡張されたとき、何らかの意味で200GBの元のサイズを内部的に記憶し続け、OSができなくなったあらゆる種類の奇妙な現象を作成したようですハンドルを閉じて、Tomcatをファイルの制限に到達させ、すべての問題を解き放ちます。
最長の回答。探偵の仕事の詳細が少し追加されています。この病理が2つの別々のセットアップで並行して発生したときに画期的な出来事が起こりました。これらのセットアップのすべてのパラメーターをチェックして比較すると、ドライブのdf -hがこの結果を示していることがわかりました。
/dev/xvdc 1008G 197G 760G 19% /mnt/eternal
ディスクにはまだ十分なスペースが残っているため、これは以前は私たちの注意を引くことはありませんでした。しかし、両方のセットアップでまったく同じディスク使用量（197G）であり、それが発生する理由はありません。ここから物事はすぐに展開しました。前述のとおり、AWSインスタンスは200GBのディスクスナップショットを持つイメージから作成され、resize2fsを使用して個々のインスタンスで拡張されます-通常、最大サイズは1TBです。新しいインスタンスを起動し、1 TBにサイズ変更して、300 GBの大きなファイルを作成することで、最終的に「不良状態」を再現することができました。これが行われたとき、システムはフリーズしませんでしたが、同じ奇妙な動作を示しました：
/dev/xvdc 1008G 197G 760G 19% /mnt/eternal
そして、ディスク上に197GB以上のデータが明らかにあったとき。そのため、上記の2つの方法（chkdskとディスクの再作成）を2つの個別のクリーンセットアップで試したところ、それぞれに奇妙な動作は見られなくなりました。
私たちの推測では、AMIが作成されたときに、スナップショットプロセスで問題が発生した可能性があります。「再起動せずにスナップショット」を作成したことが原因である可能性があります（通常、再起動せず、バックアップする証拠がありません）これで、私はDevOpsが原因なしに彼女を責めたことで私を怒らせないことを願っています！）全体として、興味深い経験です。
ほとんどの場合（明らかにあなたのケースではありません）、理由はiNodeが不足していることです。
これを確認するには、df -iを実行します。
Filesystem Inodes IUsed IFree IUse% Mounted on
[...]
25600 25600 0 100% /foo
ここでは、iNodeの使用が100％であることがわかります。
悪いニュースは https://superuser.com/questions/585641/changing-max-inode-count-number-in-ext3-filesystem-in-cent-os によると、 -iノードの数を増やすには、-iオプションを使用してファイルシステムを作成します。