ノードサービスの CPU が高すぎる場合はどうすればよいですか?トラブルシューティングのアイデアについて話しましょう

nodeサービス CPU が高すぎる場合はどうすればよいですか?確認方法は？次の記事では、ノード サービスの CPU が高すぎる場合のトラブルシューティングのアイデアを整理して共有します。

CPU 過剰の問題について同僚が調べるのを手伝ってください。

• CPU が増加した後は、それを下げることができません。ついに同僚は気づきました。メジャー バージョンの後、デフォルトのパブリック Redis 構成はオフラインになりました (プロジェクトは古く、長い間誰もそれに触っていません) が、ビジネス側は次の方法で Redis サービスを構成してシャットダウンする必要があります。コードの中に自分自身を含めます。ビジネス側には情報のギャップがあるため、redis を閉じることができず、オンラインになった後も redis への接続を再試行し続けます (もう 1 回のリクエストは、もう 1 回の再試行を意味します)

最後に、トラブルシューティングのアイデアを次のようにまとめました。

トラブルシューティングのアイデアを追加してください

0。インスタンスを再起動します

一部の問題は、インスタンスを再起動することで解決できます。

最初にインスタンスを再起動します。これは、最初にサービスを利用可能にするために必要な手順です。後続の CPU のサージが依然として速すぎる場合は、最初にコードをロールバックすることを検討する必要があるかもしれません。サージが速くない場合は、ロールバックしてできるだけ早く問題のトラブルシューティングを行う必要はありません

#1. Linux シェル ノード プロセスが原因かどうかを確認します

コマンド 1:

top

ノードプロセスが主に CPU を占有していることがわかります。 [関連チュートリアルの推奨事項:
• nodejs ビデオ チュートリアル ]

  [root@*** ~]# top
  
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                     
  680 root      20   0 2290976 168176  34976 S  30.3  2.0 103:42.59 node                                                                                                                        
  687 root      20   0 2290544 166920  34984 R  26.3  2.0  96:26.42 node                                                                                                                        
   52 root      20   0 1057412  23972  15188 S   1.7  0.3  11:25.97 ****                                                                                                           
  185 root      20   0  130216  41432  25436 S   0.3  0.5   1:03.44 ****                                                                                                         
  ...

コマンド 2:

vmstat

vmstat 2 を初めて見てみるcommand 、2 秒ごとに収集されることを示します

[root@*** ~]# vmstat 2
procs -----------memory---------------- ---swap-- -----io---- --system-- -----cpu-----
 r  b      swpd  free   buff   cache      si   so    bi    bo   in cs   us sy id wa st
 0  0      0 233481328 758304 20795516    0    0     0     1    0    0  0  0 100  0  0
 0  0      0 233480800 758304 20795520    0    0     0     0  951 1519  0  0 100  0  0
 0  0      0 233481056 758304 20795520    0    0     0     0  867 1460  0  0 100  0  0
 0  0      0 233481408 758304 20795520    0    0     0    20  910 1520  0  0 100  0  0
 0  0      0 233481680 758304 20795520    0    0     0     0  911 1491  0  0 100  0  0
 0  0      0 233481920 758304 20795520    0    0     0     0  889 1530  0  0 100  0  0

• procs
  r #実行中のキュー (つまり、実際に割り当てられているプロセスの数) を表します。この値が CPU の数を超えると、CPU ボトルネックが発生します。これはトップの負荷にも関係しており、一般的に負荷が3を超えると比較的高負荷、5を超えると高負荷、10を超えると異常、サーバーの状態が非常に危険です。 。トップの負荷は、1 秒あたりの実行キューと同様です。実行キューが大きすぎる場合は、CPU が非常にビジーであることを意味し、一般に CPU 使用率が高くなります。
  b #ブロックされたプロセス、リソースを待っているプロセスを示します。これについては多くは言いませんが、プロセスがブロックされていることは誰もが知っています。

• memory
  swpd #使用されている仮想メモリのサイズ。0 より大きい場合は、マシンの物理メモリが不足していることを意味します。プログラムのメモリ リークの原因が判明した場合は、メモリをアップグレードするか、メモリを消費するタスクを他のマシンに移行する必要があります。
  free # 空き物理メモリのサイズ
  buff #Linux/Unix システムは、ディレクトリの内容、権限などを保存するために使用されます
  cache #cache Itは、開いているファイルを記憶し、ファイルをバッファリングし、プログラム実行のパフォーマンスを向上させるために、空き物理メモリの一部をファイルとディレクトリのキャッシュに使用するために直接使用されます。プログラムがメモリを使用する場合、バッファ/キャッシュは非常に高速になります。 . 土地が使われています。

• swap
  si #1 秒あたりにディスクから読み取られる仮想メモリのサイズ。この値が 0 より大きい場合、物理メモリが存在しないことを意味します。十分でない場合はメモリがリークしています。メモリを消費するプロセスを解決する必要があります。私のマシンには十分なメモリがあり、すべてが正常に動作します。
  so #1 秒あたりにディスクに書き込まれる仮想メモリのサイズ (この値が 0 より大きい場合、上記と同様)。

• io
  bi #ブロック デバイスが 1 秒あたりに受信したブロックの数。ここでのブロック デバイスとは、システム上のすべてのディスクと他のブロック デバイスを指します。デフォルトのブロック サイズは 1024 バイトです
  bo #ブロック デバイスによって 1 秒あたりに送信されるブロックの数たとえば、ファイルを読み取る場合、bo は 0 より大きい必要があります。 Bi と bo は通常 0 に近く、そうでない場合は IO の頻度が高すぎるため、調整する必要があります。

• system
  in #時間割り込みを含む 1 秒あたりの CPU 割り込みの数
  cs #1 秒あたりのコンテキスト スイッチの数など, システム関数を呼び出す際には、コンテキスト切り替え、スレッド切り替え、プロセスのコンテキスト切り替えを行う必要があります。値は小さいほど良いです。大きすぎる場合は、スレッドまたはプロセスの数を減らすことを検討してください

• cpu
  us #ユーザー CPU 時間。頻繁に暗号化と復号化を行うサーバー上にありました。100 に近く、r 実行キューが 80 に達していることがわかりました (マシンストレステストを行っていましたが、パフォーマンスは低かったです）。
  sy #システム CPU 時間が高すぎる場合は、頻繁な IO 操作など、システム呼び出し時間が長いことを意味します。
  id ​​#アイドル CPU 時間、一般的に言えば、id us sy = 100、一般的に、id はアイドル CPU 使用率、us はユーザー CPU 使用率、sy はシステム CPU 使用率だと思います。
  wt #IO CPU 時間を待機しています。 ＃＃＃＃＃＃＃＃＃＃＃＃練習する＃＃＃

  procs r: 多くのプロセスが実行されており、システムが非常にビジーです
  bi/bo: ディスクに書き込まれるデータ量は若干多くなりますが、大きなファイルの場合は 10M 以内になるはずです。基本的に心配する必要はありません 小さなファイルであれば 2M 以内です 基本的に正常です
  cpu us: 継続的に 50% を超えており、サービスピーク期間中は許容されます。長い間 50 を使用すると、最適化を検討できます。
  cpu sy: 実際のカーネル プロセスの割合。ここでの us sy の基準値は 80% です。us sy が 80% を超える場合、CPU が不足している可能性があります。 。
  cpu wa: 列は、IO 待機によって占有される CPU 時間の割合を示します。ここでの wa の基準値は 30% です。wa が 30% を超える場合は、ディスクへの大量のランダム アクセスが原因であるか、帯域幅のボトルネックが原因である可能性があります。ディスクまたはディスク アクセス コントローラー (主にブロック操作)

参考リンク: https://www.cnblogs.com/zsql/p/11643750.html

2.コード diff

を確認します。インスタンスを再起動しても問題が解決せず、問題がノード プロセスにあると判断される場合は、

オンライン コミットを確認し、コードの差分を確認し、問題が見つかるかどうかを確認します。

3 をクリックして、ランタイム CPU プロファイラーを開きます

この操作方法は私の他の記事と同じですSSR サーバーのメモリ リークをすばやく特定する方法質問 は、

• ノードを使用する - と似ています。 -inspect サービスを開始します

• オンライン環境のローカル シミュレーション、ビルドを使用しますコードの後に​​、直接ビルドは使用できない場合があります。環境変数は適切に制御する必要があります

  • たとえば、パッケージはローカルで CDN にアップロードされないため、一部の環境変数 (CDN ドメイン名など) がローカルを指すようにします。
• #CPU プロファイラーの生成

オンライン環境をシミュレートできない場合はどうすればよいですか地元で？

たとえば、ダウンストリーム RPC がローカルから分離されている場合、プロファイルを作成するためのコードのみを追加できます

nodejs.org/docs/latest…

プロファイル ファイルを取得したら、chrome devtool で開きます

#4. CPU プロファイラーを分析します

• プロファイラとコードの差分を組み合わせて原因を特定します

プロファイル ファイルを
• www にアップロードすることもできます.speedscope.app/

  (ファイルのアップロード)、CPU プロファイルのフレーム グラフを取得できます (詳細な使用方法の紹介: www.npmjs.com/package/spe…

#5. ストレス テストの検証

ab またはその他のストレス テスト ツールを使用できます

概要

#インスタンスを再起動します

• #ノード プロセスが原因であることを確認します

• #コードの差分を確認します

#ランタイム CPU プロファイラーを生成

• ##プロファイラーとコードの差分を組み合わせて原因を特定します

• ##ストレス テストの検証

• ノード関連の知識については、

  nodejs チュートリアル

  !
を参照してください。

以上がノードサービスの CPU が高すぎる場合はどうすればよいですか?トラブルシューティングのアイデアについて話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。