おっと、CPU が 100% になっています!この非常に厄介な問題を解決する方法

序文

CPU使用率100%の問題は非常に厄介な問題です。この種の問題には多くの原因があるため、最も重要なことはそれが避けられないことではないということです。システムが一定期間稼働した後、ある時点で突然問題が発生する可能性があります。

今日は、同僚と私が以前遭遇した CPU 使用率 100% の問題を特別にまとめ、困っている友人のためにパラメータを提供します。

1. 一度に取得されるデータが多すぎる

私は以前、ケータリング関連の業務システムの開発に携わったことがあり、当時の私のチームは料理の下流業務を担当していました。

当時、フードシステム内の料理が更新されると、Kafka メッセージが送信されていました。私たちのシステムはトピックを購読し、最新の更新された料理データを取得することができました。

料理データを同期する機能は1年以上オンライン化されており、問題は発生していません。

しかしある日の午後、CPU 100% の警告メールを大量に受け取りました。

原因を調査した結果、食器システムにバグがあることが判明しました。毎回、増分データではなく、料理データの全量を取得しました。

一度に取得されたデータが多すぎます。

料理は比較的頻繁に変更されるため、システムは大量のデータを頻繁に読み取って解析することになり、CPU の使用率が上昇し続けます。

根本的な原因は頻繁なフル GC です。

2. Kafkaの自動確認

以前は、ケータリング サブシステムはメッセージ ミドルウェアである Kafka を介して通信していました。

上流システムでデータが生成され、データベースに書き込まれた後、関連するビジネス ドキュメントの ID が Kafka メッセージを介してブローカーに送信されます。

下流システムは、関連トピックのメッセージをサブスクライブし、ビジネス ドキュメントの ID を取得してから、上流システムのビジネス クエリ インターフェイスを呼び出して、関連するビジネス データを取得します。

当初は、利便性のため、注文メッセージを使用するときに、Kafka の確認メカニズムで自動確認が使用されていました (つまり、記述するコードが少なくて済みました)。

最初は大きな問題ではありませんでした。

ビジネスが発展するにつれて、ユーザー数が増加し、毎日生成される Kafka メッセージの数も増加します。

ついにCPU使用率が100%になるという問題が発生し始めました。

その後、Kafka のコンシューマーをメッセージの消費後に手動で確認するように変更し、CPU 使用率 100% の問題は解決しました。

3. デッドループ

実際の作業では、すべての開発者が無限ループを引き起こすコードを書いたことがあるかもしれません。

無限ループには 2 つの種類があります。

• while、for、forEach ループ内の無限ループ。
• 無限再帰。

どちらの場合も、プログラムは継続的に実行され、レジスタを使用してループの数や再帰の深さを保存し、CPU を常に占有するため、CPU 使用率が急上昇します。

JDK1.7 を使用すると、デッド ループがまだいくつか存在します。たとえば、マルチスレッド環境では、データを HashMap に格納すると、リンク リストでデッド ループが発生する可能性があります。

これにより、CPU は引き続き急上昇します。

4. マルチスレッドデータインポート

以前、私たちのグループの同僚がサプライヤーの Excel データのインポート機能を開発しました。

この機能が開始された後、Excel にもう少しデータがあると、インポート時間が非常に長くなることがわかりました。

サプライヤーのインポートに関連するビジネス ロジックは複数のテーブルが関係しており、やや複雑であるため、単一のスレッドで 1 つずつ順番にインポートされます。

データのインポートのパフォーマンスを向上させるために、同僚はシングルスレッドのインポートを、スレッド プールを使用したマルチスレッドのインポートに変更しました。

この変換後、Excel データのインポート速度は確かに大幅に向上しました。

しかし、オンラインになった後、CPU 使用率が急上昇するという別の問題が発生しました。

複数のスレッドを介してデータをインポートする場合、スレッドの数が多いと、スレッドのコンテキスト切り替えプロセスの数が多くなり、CPU リソースが大量に消費されます。

5. 多数のファイルを同期する

以前、ゲームプラットフォームの開発に携わっていました。

ゲームメーカーは自社のゲームを当社のプラットフォームに接続し、当社はそのプロモーションを支援し、利益を分配します。

各ゲームには、ドメイン名、画像、スタイルが異なるカスタマイズされた公式 Web サイトがあります。

パフォーマンス上の理由から、FreeMarker テンプレート エンジンを使用して、各ゲーム専用の HTML 静的公式 Web サイトを生成しました。

当時、ゲーム運営者が選択できる 12 種類以上のテンプレートが提供されていました。

もともと問題はありませんでした。

しかし、お祭りイベントがあったので、お祭りの要素を加えるために、各テンプレート ファイルにいくつかのスタイルが追加されました。

これには、新しいテンプレートを使用してすべてのゲームの公式 Web サイトを再生成する必要があります。

生成が完了したら、すべての HTML ファイルを Web サーバーの指定されたディレクトリに一度に同期する必要があります。

大量のファイルが同期されるため、ファイルを保存するアプリケーション サーバーの CPU 使用率が急上昇します。

6. デッドロック

同時シナリオで複数のスレッドが共通リソースを変更することによって発生するデータ異常を防止します。

コード内では synchronized または Lock を頻繁に使用します。

このように、複数のスレッドが重要なメソッドまたはコード セグメントに入ると、オブジェクトまたはクラスのロックを求めて競合する必要があります。対応するロックを取得することによってのみ、重要なリソースにアクセスできます。他のスレッドは、次回ロックを競い続けるために、ロックを所有するスレッドがロックを解放するまで待機する必要があります。

一部のビジネス シナリオでは、特定のコード セクションでは、ビジネス ロジックを完了するためにスレッドが複数のロックを取得する必要があります。

ただし、コードのバグやロック解除の順序が正しくない場合、デッドロックの問題が発生する可能性があります。

例えば：

 "pool-4-thread-1" prio=10 tid=0x00007f27bc11a000 nid=0x2ae9 waiting on condition [0x00007f2768ef9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0000000090e1d048> (a java.util.concurrent.locks.ReentrantLock$FairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

たとえば、スレッド a はロック c を所有しており、ビジネス ロジックを完了するにはロック d を取得する必要があります。

この時点で、スレッド b はロック d を所有しており、ビジネス ロジックを完了するにはロック c を取得する必要があります。

スレッド a はスレッド b がロックを解除するのを待機し、スレッド b はスレッド a がロックを解除するのを待機します。両方のスレッドが他方のスレッドに必要なロックを保持しており、それを積極的に解放できないため、デッドロックの問題が発生します。

デッドロックにより CPU 使用率が急上昇する可能性があります。

7. 正規表現マッチング

正規表現を使ったことがありますか?

場合によっては、ユーザーが入力した携帯電話番号、メールアドレス、ID 番号、または Web アドレスが合法であるかどうかを確認する必要があります。

通常は、次のような正規表現が使用されます。

 ^([hH][tT]{2}[pP]://|[hH][tT]{2}[pP][sS]://)(([A-Za-z0-9-~]+).)+([A-Za-z0-9-~/])+$

この正規表現は 3 つの部分に分けられます。

• 最初の部分は、http プロトコルと https プロトコルの両方に一致します。
• 2 番目の部分は www と一致します。文字。
• 3 番目の部分はその数の文字と一致します。

正規表現が適切に記述されていないと、CPU 使用率が急上昇する可能性があります。

実際、ここで CPU 使用率が高くなる主な理由は、Java 正規表現で使用されるエンジン実装が NFA オートマトンであり、この正規表現エンジンが文字の一致時にバックトラックを行うことです。

バックトラッキングが発生すると、バックトラッキングの数と複雑さに応じて、数分から数時間という長い時間がかかります。

記述する正規表現では、バックトラックを最小限に抑える必要があります。

8. 時間のかかる計算

場合によっては、ビジネス システムでデータをリアルタイムで計算する必要があります。たとえば、電子商取引システムでは、割引後の最終価格をリアルタイムで計算する必要があります。

あるいは、コード内の大量のデータから必要なデータを要約する必要があります。

このリアルタイム計算またはリアルタイム統計シナリオは非常に時間のかかる操作であり、このシナリオでの同時要求の数が少なくありません。

これにより、CPU 使用率が急上昇する可能性があります。

リアルタイム計算には CPU リソースが必要なので、計算を継続的に実行すると CPU リソースが継続的に消費されます。