Tomcatを停止した後SSHが応答しない、多くのksoftirqdCPU使用率
奇妙な問題があります。 Tomcatを停止するたびに、SSHは非常に遅くなり、ほとんど完全に応答しなくなります。 SSHがコマンドを受け入れるまでに1分以上かかります。ようやくTomcatを再起動すると、すべてが正常に戻ります。
これは非常にビジーなサーバーで発生しています。問題は、アプリケーションのアップグレードのために、Tomcatを頻繁に停止する必要があることです。通常、アップグレードには数秒かかりますが、ここでは約10分かかります。そのため、不要なダウンタイムが発生しています。
Tomcatを停止すると、topは100％CPUで多くの_ksoftirqd/X_プロセスを表示します。これが問題でしょうか？
カーネルバージョンは次のとおりです：_2.6.18-308.11.1.el5_
Red Hatのバージョンは次のとおりです：Red Hat Enterprise Linux Server release 5.9 (Tikanga)
なぜこれが起こっているのか考えはありますか？
遅いssh接続/ sshラグは、高負荷の症状です。高負荷は、多くの場合、スワッピングによって引き起こされるioブロッキングによって引き起こされます。
負荷を確認するには、uptimeまたはtopを実行します。sshが応答しない場合、おそらく負荷数が10を超えます。通常の使用では、おそらく2未満でホバリングします。
freeまたはtopを実行してメモリ使用量を確認すると、おそらく多くのスワップが表示されます。
根本的な症状を見つけたら、「シャットダウン時のTomcatスワッピング」または「Tomcat高負荷」の理由を検索できます。これはおそらく、キャッシュに保存されているものを書き込んだり、ディスクにスワップしたりしようとしているためです。 Tomcat jvmの最大ヒープサイズは、使用しているメモリの量よりも大きくなっていますか？
Webアプリに接続しているものがダウンすると、DoSシナリオの作成を常に再試行する可能性があります。
これはすべてWebアプリに固有である可能性があるため、一般的な用語を使用してください。
これが「ベストプラクティス」ではないことはわかっていますが、sshを介してTomcatをリモートでリセットし、出力をnullに設定することをお勧めします。
ssh your_server '/etc/init.d/Tomcat restart > /dev/null 2>&1'
（上記のコマンドを、Tomcatの再起動に使用するものに置き換えることができます）。
これは回避策であり、解決策ではありません。他のsshセッションに接続しているときにこれを試して、問題が引き続き発生し、すべてのセッションに影響するかどうかを確認できますか？