解決策 1:
メモリ不足です。
<ブロック引用>12 月 18 日 23:24:59 ip-10-0-3-36 カーネル:[ 775.566936] メモリ不足 :Kill process 4973 (java) スコア 0 または犠牲の子
同じログから (ps);
<ブロック引用>[ 775.561798] [ 4973] 500 4973 4295425981 2435 71 50 0 Java
4295425.981 は約 4TB です。また、行 total-vm:17181703924kB は約 17TB を示しています。
メモリ割り当てルーチンをデバッグできますか?私の場合、あなたのアプリケーションはどこかで悪いループを取得し、利用可能なすべてのリソースと利用可能なスワップも取得する必要があります。
解決策 2:
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.214705] shmem_fallocate+0x32d/0x440
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.217182] vfs_fallocate+0x13f/0x260
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.219525] SyS_fallocate+0x43/0x80
Dec 18 23:24:59 ip-10-0-3-36 kernel: [ 775.221657] do_syscall_64+0x67/0x100
アプリケーション プロセスが fallocate を呼び出そうとしています shmem ファイルシステム上。簡単なグーグル検索では、ZGC は fallocate を使用して shm ファイルシステムから初期ヒープ メモリを取得し、fallocate を使用してヒープを拡張しているように見えます。このような fallocate syscall の使用はかなり珍しいので、これは ZGC のバグ (すでにお察しのとおり) であるか、ヒープ拡張が失敗する原因となる大量のメモリ リークが発生している可能性があります。
追加のランタイム割り当てを回避するように ZGC を構成することをお勧めします (set Xms そして Xmx 同じ値に)。無関係な原因でメモリ リークが発生した場合、これでは問題が解決しない可能性がありますが、少なくとも、本当の原因を見つける可能性は高くなります。
全体的なセットアップはやや危険であることに注意してください — ZGC は明らかに大量の連続したメモリを好むようですが、240G RAM マシンに 190G ヒープがある場合、fallocate に十分な大きさの連続領域がない可能性があります。 から。その場合、ZGC はさらに fallocate を使用して小さなメモリ領域を取得するようにフォールバックします。 呼び出し (リンクされたバグ レポートの説明を参照)、問題は再び不明瞭になります... JVM で hugepage のサポートを有効にします (通常の hugepage 、透明なヒュージページではありません !) ブート中に hugepage を事前に割り当てます (カーネル引数を使用) — いずれにせよ、ヒープ サイズには hugepage を使用することをお勧めします。