今夜、95台のTomcatサーバーが構成された最大スレッドの約XNUMX％を使用しているというアラートを受け取りました。
prod443のhttp-4のTomcatプロセスでは、最大構成スレッドの96.2％がビジー状態になっています。
これらはSMSアラートでした。これは、必要に応じて誰かを起こすことを保証するために、利用可能なスレッドを使い果たすのに十分近いためです。
私たちが受け取ったもうXNUMXつのアラートは、次のグラフに示すように、Tomcatがリクエストの処理に異常な時間を費やしていることでした。
通常、リクエストは約7ミリ秒で処理されるため、40ミリ秒は大幅な低下です。
明らかに問題はありませんでした。内部メトリックは、システムがこれ以上データフィードを処理しておらず、異常な数のリクエストも、ディスクやCPUが通常よりも多く使用されていないことを示していました。
しかし、あらゆる種類の指標の傾向を把握していると、警告が表示されていなくても、XNUMXつは飛び出しました。
このデータセンターとアップストリームISPの一部の顧客との間でわずかなパケット損失が発生したことが判明しました。 ネットワークアラームをトリガーするのに十分なものはありません。 ホストやネットワークでの損失や廃棄はありません。 しかし、Tomcatへの一部の接続が失われるほど、再送信が発生しました。つまり、接続の完了に通常よりも時間がかかり、サーバーはより多くの同時接続を同時に処理する必要があり、不足する危険がありました。 。
したがって、簡単な修正：Tomcatでサポートされる最大接続数を増やします。 利用できるリソースはたくさんあります。 長いセッションに対処するために最大スレッドが16:48に増加し、少し余裕ができたことがわかります。 （徹底的にテストされていなかったため、控えめな増加でした。スペースを増やすために、すぐに大きな最大制限をテストして展開する予定です。）
これにより、Tomcatはアラートや接続を拒否する危険性を取り除くのに十分なスペアスレッドを使用でき、すぐにアップストリームISPが損失の問題を解決したため、このサーバーのセッション応答時間、つまりアクティブなスレッドが通常に低下しました。
LogicMonitorが自分のサーバーを監視していなければ、Tomcatが利用可能な最大スレッドを使い果たしそうになることを知らなかったでしょうし、まったく警告も受けていなかったでしょう。 これは、より平和なクリスマスイブにつながった可能性がありますが、監視にアクセスできなかったため、または事後にデータのギャップを報告できなかったため、怒った顧客につながった可能性があります。それを防ぐ方法。 問題が発生している間に顧客から警告を受けていたとしても、TCPの再送信によって根本的な原因が何であるかが示されることなく、私たちはまだ暗闇の中にいました。
LogicMonitorを呼び出す理由のほんの一例 破壊的な InTエリジェンス。 LogicMonitorを使用すると、停止を回避し、数分以内に問題を診断するための情報を入手できたため、家族の時間に戻ることができました。 それは破壊的です–最善の方法で。
ハッピーホリデー。