サーバー障害インスタンスの分析-安全性-php.cn

サーバー障害インスタンスの分析

王林

リリース： 2023-06-02 15:12:05

転載

1276 人が閲覧しました

1. 問題が発生しました

私たちはIT業界にいるので、毎日障害や問題に対処する必要があり、問題解決のために走り回っている消防士とも言えます。ただし、今回の障害の範囲は少し広く、ホストマシンを開くことができません。

幸いなことに、監視システムはいくつかの証拠を残しました。

マシンの CPU、メモリ、およびファイルハンドルがビジネスの成長に伴って増加し続け、監視が情報を収集できなくなるまで増加し続けたという証拠が見つかりました。

恐ろしいのは、これらのホストに多数の Java プロセスがデプロイされていることです。コスト削減以外の理由で、アプリケーションは混在していました。ホストに全体的な異常が見られる場合、原因を見つけるのが難しい場合があります。

リモートログインの有効期限が切れているため、せっかちな運用および保守担当者は、マシンを再起動し、再起動後にアプリケーションを再起動することしか選択できません。長い待機の後、すべてのプロセスは通常の動作に戻りましたが、ほんの短い時間の後、ホストマシンが突然クラッシュしました。

ビジネスは衰退傾向にあり、本当に迷惑です。それは人々を不安にもさせます。数回の試行の後、運用と保守が崩壊し、緊急計画が開始されました。ロールバック!

最近のオンライン記録が大量にあり、一部の開発者がオンラインになって非公開でデプロイしたため、運用と保守が混乱しました。幸いなことに、誰かが素晴らしいアイデアを思いつき、 find コマンドがあることを思い出し、最近更新されたすべての jar パッケージを見つけてロールバックしました。

find /apps/deploy -mtime +3 | grep jar$

ログイン後にコピー

find コマンドを知らないと、本当に大変なことになります。幸いにも誰かが知っています。

十数個の jar パッケージをロールバックしましたが、幸いなことにデータベーススキーマの変更は発生せず、最終的にシステムは正常に動作しました。

2. 理由を見つけます

他に方法はなく、ログを確認してコードレビューを実施します。

コードの品質を確保するには、コードレビューの範囲を過去 1 週間または 2 週間のコード変更に限定する必要があります。これは、一部の機能コードは完成するまでにある程度の時間を必要とするためです。オンラインで輝きます。

画面いっぱいに表示された提出記録「OK」を見て、技術部長の顔が青くなった。

「xjjdog さんは、「プログラマーの 80% はコミットレコードを書けない」と言っていますが、皆さんの 100% はコミットレコードを書けないと思います。」

誰もが静かに痛みに耐えながら歴史の変遷を確認していました。全員のたゆまぬ努力の結果、ついにたわごとの山の中から問題のあるコードがいくつか見つかりました。 CxO 自身が作ったグループで、問題を引き起こす可能性のあるコードを全員がそこに投げ込みます。

「システムサービスは 1 時間近く中断され、影響は非常に悪かった。」CxO は、「問題は完全に解決する必要があります。投資家はこの問題を非常に懸念しています。」!

okokok, with Nail ネイルのおかげで、みんなのしぐさが均一になりました。

3. スレッドプールのパラメーター

コードはたくさんあり、問題のあるコードについてみんなで長い間議論しています。この文は次のように書き換えることができます。スレッドプールの使用に特に注意を払い、並列ストリームを使用し、ラムダ式内でネストされたいくつかの複雑なコードを調べました。

最終的に、全員がスレッドプールのコードをもう一度検討することにしました。その一節にこんなことが書かれています。

RejectedExecutionHandler handler = new ThreadPoolExecutor.DiscardOldestPolicy(); ThreadPoolExecutor executor = new ThreadPoolExecutor(100,200,                 60000,                 TimeUnit.MILLISECONDS,                 new LinkedBlockingDeque(10),                 handler);

ログイン後にコピー

言うまでもなく、パラメータはまともであり、拒否戦略も考慮されています。

Java のスレッドプールを使用すると、プログラミングが非常に簡単になります。上の図に示すように、これらのパラメーターを 1 つずつ確認しないと確認できません。

corePoolSize: コアスレッドの数。コアスレッドは作成後も存続します。
maxPoolSize: スレッドの最大数
keepAliveTime: スレッドのアイドル時間
workQueue: ブロックキュー
threadFactory: スレッド作成ファクトリー
ハンドラー: 拒否戦略

両者の関係を以下に紹介します。

スレッドの数がコアスレッドの数より少なく、新しいタスクが到着した場合、システムはタスクを処理するための新しいスレッドを作成します。現在のスレッド数がコアスレッドの数を超えており、ブロッキングキューがいっぱいでない場合、タスクはブロッキングキューに配置されます。スレッドの数がコアスレッドの数より大きく、ブロッキングキューがいっぱいの場合、スレッドの数が maxPoolSize サイズに達するまで、新しいスレッドが作成されて処理されます。この時点で、新しいタスクがある場合、拒否ポリシーがトリガーされます。

拒否戦略について話しましょう。 JDK には 4 つの組み込みポリシーがあり、そのデフォルトは AbortPolicy で、直接例外をスローします。他にもいくつか紹介します。

DiscardPolicy は、abort よりも根本的なものです。例外情報も含めずにタスクを直接破棄します。
タスクの処理は、呼び出し元のスレッドによって実行されます。これが CallerRunsPolicy の実装方法です。 Web アプリケーションのスレッドプールリソースがいっぱいになると、新しいタスクが Tomcat スレッドに割り当てられて実行されます。場合によっては、このメソッドは一部のタスクの実行圧力を軽減できますが、多くの場合はメインスレッドの実行を直接ブロックします
DiscardOldestPolicy はキューの先頭のタスクを破棄しますを実行してから、再度タスクを実行してみてください。

このスレッドプールのコードは新たに追加されたもので、パラメーターの設定も適切で、大きな問題はありません。 DiscardOldestPolicy 拒否ポリシーを使用することが唯一の可能性のあるリスクです。タスクが大量にある場合、この拒否ポリシーによりタスクがキューに入れられ、リクエストがタイムアウトになります。

もちろん、このリスクを手放すことはできませんが、正直に言うと、これはこれまでに見つかった中で最も可能性の高いリスクコードです。

"把DiscardOldestPolicy 改成預設的AbortPolicy吧，重新打包上線一下試試「。技術大牛在群組裡說。