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

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

青灯夜游

リリース： 2022-09-15 19:46:25

転載

3781 人が閲覧しました

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

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

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

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

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

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

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

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

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

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

コマンド 1:

top

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

[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 プロファイラーの生成

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