Node サービスのローカル環境と運用環境でメモリの変化を監視するにはどうすればよいですか?

実稼働環境でサーバー言語として Node を使用する場合、過剰な同時実行性またはコードの問題により OOM (メモリ不足) が発生するか、CPU がフル稼働します。これらはサーバーによくある問題ですが、現時点では、ログやリリースと組み合わせて CPU とメモリを監視することで、問題を簡単に発見できます。

#[ビデオ チュートリアルの推奨:

node js チュートリアル]

この章では、ローカル環境と運用環境でメモリの変更を監視する方法を紹介します

ノード アプリケーション インスタンス

では、ノード プロセスのメモリ変更を動的に監視するにはどうすればよいでしょうか?

以下はノード サーバーの例です。これはメモリ リークの問題を伴う例であり、Shanyue が運用環境で長い間指摘してきた問題の合理化されたバージョンです。

そのメモリ リークの問題では、単一コンテナ内のメモリが元の 400M から 700M に急増しました。800M のコンテナ リソース制限下では、OOM が発生し、再起動が発生することがありました。しばらく問題が見つからなかった（問題の発見が遅すぎて、半月前の時系列データを飲み込んでしまったため、Release が見つからなかった）ため、リソース制限が 1000M に引き上げられました。その後、データベースに大きなフィールドをマウントする ctx.request が原因であることが判明しました。

const Koa = require('koa')
const app = new Koa()

function getData () {
  return Array.from(Array(1000)).map(x => 10086)
}

app.use(async (ctx, next) => {
  ctx.data = getData()
  await next()
})

app.use(ctx => {
  ctx.body = 'hello, world'
})

app.listen(3200, () => console.log('Port: 3200'))

プロセス メモリの監視

いくつかの問題は、時間内に解決する必要があります。実稼働環境への大きな影響を回避するため、ローカル環境とテスト環境。次に、メモリをローカルで監視する方法を理解することが重要です。

pidstat は、Linux パフォーマンス デバッグ ツールの sysstat シリーズのパッケージです。メモリ、ネットワーク、IO、CPU などの Linux パフォーマンスの問題をデバッグするために実際に使用されます。 、など。

これは node で試行されるだけでなく、python、java、 を含むすべてのプロセスにも適用されます。 go

# -r: 指输出内存指标
# -p: 指定 pid
# 1: 每一秒输出一次
# 100: 输出100次
$ pidstat -r -p pid 1 100

pidstat を使用する前に、プロセスの PID を見つける必要があります pid

方法ノード プロセスの PID を確認するには

node では、process を通じてプロセスの pid<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false">&gt; process.pid 16425</pre><div class="contentsignin">ログイン後にコピー</div></div> を見つけることができます。 .pid

を記述することによってコードは

pid を見つけることができますが、煩雑であまり実用的ではありません。では、非侵襲的な手段で pid を見つけるにはどうすればよいでしょうか?方法は 2 つあります。

冗長パラメータと組み合わせる
1. psプロセスを見つける
ポート番号と組み合わせる
2. lsofプロセスを見つける

$ node index.js shanyue

# 第一种方法：通过多余的参数快速定位 pid
$ ps -ef | grep shanyue
root     31796 23839  1 16:38 pts/5    00:00:00 node index.js shanyue

# 第二种方法：通过端口号定位 pid
lsof -i:3200
COMMAND   PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
node    31796 root   20u  IPv6 235987334      0t0  TCP *:tick-port (LISTEN)

pidstat を使用してメモリを監視する

上記のコードから、ノード サービスの pid が

31796 、メモリの動的な変化を観察するために、ストレス テストを適用します

$ ab -c 10000 -n 1000000 http://localhost:3200/

# -r: 指输出内存指标
# -p: 指定 pid
# 1: 每一秒输出一次
# 100: 输出100次
$ pidstat -r -p 31796 1 100
Linux 3.10.0-957.21.3.el7.x86_64 (shuifeng)     2020年07月02日  _x86_64_        (2 CPU)

             UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
19时20分39秒     0     11401      0.00      0.00  566768  19800   0.12  node
19时20分40秒     0     11401      0.00      0.00  566768  19800   0.12  node
19时20分41秒     0     11401   9667.00      0.00  579024  37792   0.23  node
19时20分42秒     0     11401  11311.00      0.00  600716  59988   0.37  node
19时20分43秒     0     11401   5417.82      0.00  611420  70900   0.44  node
19时20分44秒     0     11401   3901.00      0.00  627292  85928   0.53  node
19时20分45秒     0     11401   1560.00      0.00  621660  81208   0.50  node
19时20分46秒     0     11401   2390.00      0.00  623964  83696   0.51  node
19时20分47秒     0     11401   1764.00      0.00  625500  85204   0.52  node

出力インジケーターの意味は次のとおりです

RSS
• : 常駐セット サイズ (常駐メモリ セット) はメモリとして理解できます。これは監視する必要があるメモリ インジケータです。
VSZ
• : 仮想サイズ、仮想メモリ
出力からわかるように、

ストレス テストの適用後、メモリは 19M から 85M に増加しました。

top を使用してメモリを監視する

pidstat

は sysstat にある Linux パフォーマンス ツールですが、Mac でメモリを見つける方法バラエティ？

top/htop

<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false">$ htop -p 31796</pre><div class="contentsignin">ログイン後にコピー</div></div><p><img src="https://img.php.cn/upload/image/488/272/209/1598581094937067.png" title="1598581094937067.png" alt="Node サービスのローカル環境と運用環境でメモリの変化を監視するにはどうすればよいですか?">運用環境のメモリ監視</p> <h2 id="item-5">現在の運用環境のほとんどは、 </h2>k8s<p> にデプロイされた環境 <code>したがって、運用環境における特定のアプリケーションのメモリ監視は、本質的には、k8s による特定の ワークロード/デプロイメントのメモリ監視になります。メモリ監視metric のデータ フローの方向は大まかに次のとおりです:

k8s

-> metric server -> prometheus -> grafanaアーキテクチャ図は次のとおりです:

##上の写真は次の記事から引用しています

Prometheus を使用した Kubernetes 監視

• ##Kubernetes 監視アーキテクチャ
• ##ついに #grafana で収集されたアプリケーションのメモリ監視のリアルタイム グラフができるようになりました:

この部分には設計内容が多すぎるため、次の章で紹介します

これはノード サービスに適用されるだけでなく、すべての k8s ワークロードにも適用されます

概要

この章では、ローカル環境および運用環境におけるノード サービス メモリの監視について紹介します

1. ローカル使用htop/ top または pidstat プロセス メモリの監視

2. 本番環境での使用k8s/metric-server/prometheus/grafana ノード アプリケーション全体のメモリの監視

特定のサービスでメモリリークが検出された場合、問題を解決するにはどうすればよいですか?したがって、次の記事では、

1. 実稼働環境がアプリケーション全体のメモリを監視する方法

2. 実稼働環境で OOM が発生した場合に、迅速にその場所を特定する方法について説明します。

3. 実際の運用環境における OOM の位置付けのいくつかの例
プログラミング関連の知識の詳細については、

プログラミング入門をご覧ください。 ！

以上がNode サービスのローカル環境と運用環境でメモリの変化を監視するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。