約1週間ほど、Ubuntu 16.04サーバーのスワップスペースがいっぱいになったり空になったりして、サーバーに別のカスケード問題が発生しました。つまり、Solrを実行しているTomcatインスタンスは定期的に失敗します。
サーバーは、16g
RAMと16g
スワップを備えたクアッドコア仮想マシンです。現在swappiness
の値はです60
。
私たちは、画像処理などのためにローカルサーバーへの内部HTTP呼び出しをたくさんしながら、サーバーを非常に懸命に運営しており、ほとんどはApacheを通じて行われます。スワップスペースがゆっくり満たされて空にならない問題があったため、目立つ効果なく他の領域を簡素化しました。再起動すると、正常に戻るまで問題を解決できます。
スワップドロップのチャート番号を添付できますが、どのように役立つかはわかりません(nmonを使用して追跡しました)。たとえば、昨日の再起動後、free -m
出力は次のようになります。
total used free shared buff/cache available
Mem: 16047 4888 7621 32 3536 10729
Swap: 16380 0 16380
ご覧のとおり、0
交換に使用されます。ただし、まだ確認されていない理由でシステムがダウンした場合、実際には修復されず、次の中断が発生します。
午後1時30分ごろ、床が届くまで数日をスキップしてください。
どんな提案がありますか?それとも調査を続ける方法について提案がありますか?
質問の更新
コメントのフィードバックに基づいて質問を少し更新してください。
Tomcatのヒープサイズではないようです。現在、TomcatのJVM設定では、JAVA_OPTS=' -Xms4096m -Xmx4096m'
そのサイズを大幅に増やしました(通常2g程度実行)。トム猫はcatalina.out
私たちに言いますNative memory allocation (mmap) failed to map 2863661056 bytes for committing reserved memory.
答え1
これはおそらくsolrでメモリリークが発生したか、JVMパラメータを誤って設定したようです。私はこれが仮想マシンなので、solrだけを実行すると思います。
メモリ関連のJVMパラメータを確認したい場合があります。
-Xms
-Xmx
-Xmx
最大ヒープサイズが指定されています。
"-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/some/path/filename"
JVMパラメータを追加して、OOMEでヒープダンプを生成するようにJVMを設定することもできます。ファイルがかなり大きいので、少なくとも32GBのディスク容量が必要になることがあります!
これを知ったら、漏れが発生する場所を確認できます。
更新:JVMではないようで、すべてのプロセスを見てください。
これを実行すると、どのプロセスが最も多くのスワップスペースを使用しているかがわかります。
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r
からインポートhttps://www.cyberciti.biz/faq/linux-which-process-is-using-swap/