この記事では、618 以前の R2M (企業内部キャッシュ コンポーネント。Redisと同等と考えられます) アラームを使用し、アラームの直接的な原因と根本的な原因を浅いものから深いものまで分析し、その理由に基づいて対応するソリューションを提案します。同様の問題をトラブルシューティングするときに、対応するアイデアを提供します。
1. トラブルシューティング
1.1 電子メールアラート
ある日、618番が勤務する直前に、次のようなアラートメールが届きました。
こんにちは、R2M 監視アラームです。時間内に追跡してください。アラーム情報: アラーム ID: 6825899、アプリケーション: zr_credit_portal、担当者: zhangsan、アラームの種類: メモリ使用量、時刻: 2023-06-15 16:00:04。インスタンス: (10.0.0.0:5011-slave)、現在: 9212MB、警告値超過: 8748MB、インスタンスの最大メモリ: 10800 MB、メモリ使用量: 85%; インスタンス: (10.0.0.0:5023-master)、現在: 9087MB、警告値を超えています: 8748MB インスタンスの最大メモリ: 10800 MB、メモリ使用量: 84%; インスタンス: (10.0.0.0:5017-master)、現在: 9214MB 警告値を超えています: 8748MB インスタンスの最大メモリ: 10800 MB、メモリ使用量: 85 %;
大まかな内容は、R2Mクラスタの利用率が85%に達しており、早急に対応する必要があるというもの。
キャッシュ クラスター構成は次のとおりで、合計容量は 32,400MB、マスター 3 台、スレーブ 3 台、各マスター ノードの容量は 10,800M で、現在の最高使用量は 9,087M に達しています。R2M は展開にクラスター モードを使用します。
最初のアイデアは、主要な統計を使用して、どのキャッシュが容量を占有しているかを確認することです。重要な統計情報はスレーブ ノードからスキャンされるため、メインのオンライン プロセスへの影響を心配する必要はありません。
1.2 コード分析
大きなキーは主にxxx_data と xxx_interfacecode_01 の2 つのカテゴリに分かれており、このルールに従ってコード内でキーを格納する場所を見つけます。
String dataKey = task.getTaskNo() + "_data";
cacheClusterClient.setex(dataKey.getBytes(), EXPIRATION, DataUtil.objectToByte(paramList));
key = task.getTaskNo() + "_" + item.getInterfaceCode() + "_" + partCount;
cacheClusterClient.setex(key.getBytes(), EXPIRATION,DataUtil.objectToByte(dataList));
コードの場所を見つけたら、そのビジネス プロセスを分析します。
1.3 アラームの理由
上記の分析に基づいて、高い稼働率の理由は直接原因と根本原因に分類できます。
1.3.1 直接的な原因
操作バックエンドを確認したところ、過去 3 日間にユーザーが大量のバッチ実行タスクを作成したことが判明しました。その結果、キャッシュ内のサンプルと結果の数が増加し、過剰なキャッシュ使用量が発生しました。
1.3.2 根本原因
上記の説明に従ってコードを分析した後、キャッシュにはサンプルと結果という 2 つの主要なデータが存在します。
-
まず、サンプルをキャッシュに保存し、その後ランダムに取り出すという操作は、キャッシュ容量を占有するだけで意味がありません。
-
結果はバッチとシャードに保存されます。このステップは意味があります。これは主に、マルチタスクの並列処理中にデータがシャード化されずキャッシュに保存されない場合に、データが JVM 内で多くのスペースを占有するのを防ぐためです。 FULL GC の質問につながる可能性があります。(以前の記事で分析しました)
-
バッチ実行の完了後、中間データは通常は役に立ちませんが、ビジネス プロセスは不要なデータを積極的に削除せず、タイムアウトを待った後に自動的に削除します。この操作により、データは一定期間キャッシュに保存されます。追加の期間。
この時点で、キャッシュ使用率が高くなる理由は分析されています（実際にはまだ、直接的な原因は表面的に分析されているだけで、直接的な原因の「根本原因」はまだ結論付けられていません）。
2. 問題解決
上記では、このアラームのトラブルシューティング手順を分析しましたが、問題の解決方法を、直接原因の解決方法と根本原因の解決方法に分けて説明します。
2.1 直接的な原因
2.1.1 原因分析
618 の前夜には、システムへの操作の影響を考慮しないのが最善であるため、メモリを占有し続けてオンライン ビジネスに影響を与えることを避けるために、該当するユーザーに実行中のバッチの作成を一時的に停止するよう依頼することしか考えられません。
このとき、モニタリングチャートを観察すると、次のことがわかりました。
ユーザーは 3 日前 (キャッシュが増加し始めた時刻に相当します) からバッチ タスクの作成を開始しましたが、キャッシュは 1 日しか有効ではありません。論理的に言えば、キャッシュは翌日から大幅に減少するはずです (キャッシュが増加しているため)前日の使用期限が切れている場合)、監視グラフを見ると、過去 3 日間でキャッシュ使用率がほぼ直線的に上昇しているのはなぜですか?
ここでは、Redis の機能に関連する 30 秒について考えることができます。
以前体系的に学んだ Redis の関連機能によると、この問題に注目した後、タイムアウトを 1 日に設定しているにもかかわらず、実際にはデータが物理的に削除されていない可能性があるのではないかと考え始めました (Redis 'キャッシュ削除戦略)?
次に、R2M 関連ドキュメントを確認してください。
で：
有効期間を持つキーが多数ある場合、
0キーの有効期間が変更されてからキーが実際に削除されるまでにかなりの時間がかかる可能性があります。
これは私たちの特徴ではないでしょうか? 先ほど大きなキーを検索した図からわかるように、タイムアウトしているキーがたくさんあり、サイズも非常に大きいです。つまり、TTL が 0 になります) 。データはアクセスされていません。また、R2M プログレッシブ削除により、特定のキーはタイムアウトが経過するまで実際に物理的に削除されない場合があります。
この時点で、直接的な原因の根本原因が判明しました。
2.1.2 解決策
では、どうすれば解決できるでしょうか？有効期限が切れたキーを物理的に削除するには、次の 2 つの戦略に従います。
知らせ：
Redis は次の 2 つの方法を使用して期限切れのキーを削除します
キーにアクセスすると、プログラムはキーをチェックし、キーの有効期限が切れている場合はキーを削除します。
基盤となるシステムは、期限切れになったがアクセスされないキーを処理するために、バックグラウンドで期限切れのキーを徐々に見つけて削除します。
まず、データにアクセスしてデータを削除するのは愚かであり、不要です (アクセスでき、期限切れが近づいていることがわかっている場合は、直接削除することをお勧めします)。その後、プログレッシブ検索率を高めることを選択できます。これにより、タイムアウトしたデータが物理的に削除されます
そこで、R2M の対応する運用およびメンテナンスに連絡しました。
上記のチャット記録によると、プログレッシブ物理削除の頻度を調整するパラメータが実際にあり、キャッシュ クラスターは以前は不明な理由で 10 に調整されていました (プロジェクト チームが変更を加えました)。これは約 6 分の 1 です。この結果は次のとおりです。また、それは私たちの期待と一致しており、私たちの推測が正しいことを裏付けています。
618 の前夜だったため、このパラメータは変更しませんでしたが、618 の後、すぐにこのパラメータを変更する作業指示を提出し、パラメータを 10 から 80 に増やしました。
承認が通過した後、r2m の減少率を観察します。
6 月 20 日にパラメータを調整した後、大規模なデータ バッチが追加されなかった後、r2m 使用量の減少率が大幅に速くなったことがわかります。
この時点で、キャッシュ使用量アラームの直接の原因は解決されました。本当の理由は、有効期限が切れても多数のキーが削除されていないことであり、その後のキャッシュ使用量がそれほど高くないことが観察されています。さらに、実行中のバッチ タスクが多数ある場合、それらが同日に直接追加されなければ、通常、使用率が高くなる問題は発生しません。
2.2 根本原因
上記のパラメータを調整した後、基本的にユーザーの日常のビジネス ニーズを満たすことができますが、ユーザーが 1 日に大量のバッチ タスクを実行する必要がある場合、このソリューションでは依然として根本的な問題は解決できず、また、問題が解決されない可能性もあります。利用率が高くなりすぎる オンラインビジネスに影響を及ぼすリスク。
したがって、この問題を根本的に解決するには、バッチ プロセスを最適化する必要があります。1.2 のプロセス図と理由分析によると、次のようになります。
-
サンプルをキャッシュに保存する必要がないため、パラメーターはコードの次のステップに直接渡されます。
-
結果のシャーディングは上記の理由から確かに意味がありますが、Redis のキャッシュ領域 (つまりメモリ) は比較的貴重であり、OSS の領域コスト (ハードディスク) は比較的安価であり、ビジネス自体がオフラインであることを考慮すると、タイムリーですクエリ速度は最も重要な要素ではないため、バッチ実行結果のシャード データを OSS に保存する際には、包括的な考慮が行われます。
-
バッチ実行プロセスが完了すると、データが役に立たなくなった後もストレージ領域を占有することを防ぐために、oss 内の結果のシャード データがアクティブに削除されます。また、システムの異常によりデータが完全に削除されることを防ぐため、oss側で7日間の自動削除が設定されています。
要約すると、上記の最適化のアイデアと組み合わせて、再設計されたフローチャートは次のようになります。
この時点では、後続のユーザー データの量がどれほど大きくても、それが 1 日で作成されたか複数日で作成されたかに関係なく、キャッシュ使用量のアラームは発生せず、オンライン ビジネスの問題を引き起こす可能性があります。
2.3 最適化率
オンライン完了後のキャッシュ使用量:
ほぼ崖から落ちているのがわかります。
キャッシュ最適化率:
前者の変換
変身後
(8.35-0.17)/8.35≈97.96%
3. まとめ
この記事では、主にアラーム メールを使用して、キャッシュの問題を分析し、システム内のプロセスの最適化を浅いところから深いところまで行っています。実際の問題を解決した後は、次回の開発プロセスでそのような問題を回避できるように、全員が経験と要約を持っておく必要があります。また、自分自身を再度要約してアーカイブすることもできます。何が起こっているのかを知るためには、なぜそれが起こっているのかも知る必要があります。以下の要約は、私自身の経験を浅いところから深いところまで少しだけまとめたものです。
3.1 異なるミドルウェアは異なることを担当する必要がある
「韓信は軍隊に命令する。多ければ多いほど良い。」 優れた将軍とは、兵士がそれぞれの専門分野で任務を遂行できるように、さまざまな兵士にさまざまな責任を割り当てることができる人です。研究開発では、さまざまな機能を実行するためにさまざまなミドルウェアを選択することが、研究開発の技術レベルを反映することがあります。
この記事では、中間データを保存するために使用できるミドルウェアが多数あります。Redis や Oss に加えて、Mysql、Hive、ES、CK などもあります。対応する機能を完了するには、さまざまなビジネス ニーズに応じて異なるミドルウェアを選択する必要があります。 。この場合、データの特性が大容量で速度を必要としないのに対し、Redisのストレージの特性は少量で高速であることは明らかであり、この2つは相反するニーズやビジネスであることは明らかであるため、どちらかを選択する必要があります。ミドルウェアを選択するときに正しいものを選択してください。
3.2 技術的な詳細を学ぶことは役に立ちますか?
実際、私はこれまでに多くのテクノロジーやフレームワーク実装の詳細を学習しましたが、そのほとんどは学習後すぐに完了し、あまり演習はありませんでした。このケース分析は、私が Redis の関連詳細を学んだ直後に行われたもので、それを理論と実践の組み合わせとみなせるこの実践的なセッションに適用できるようになるまで、時間はかかりませんでした。さらに、このケースは学習への関心を大幅に高めることにもなります。
200元の罰金と100万元以上を没収 You Yuxi: 高品質の中国語文書の重要性 MuskのJDK 21用ハードコア移行サーバー Solon、仮想スレッドは信じられないほど素晴らしい！！！ TCP 輻輳制御によりインターネットが節約される OpenHarmony 用の Flutter が登場 Linux カーネルの LTS 期間が 6 年から 2 年に復元される Go 1.22 で for ループ変数エラーが修正される Svelte は「新しいホイール」を作成 - ルーン文字 Google が創立 25 周年を祝う著者: JD Technology Korea Kai
出典：JD Cloud Developer Community 転載の際は出典を明記してください