ホームページ > 記事 > ウェブフロントエンド > Node サービスのローカル環境と運用環境でメモリの変化を監視するにはどうすればよいですか?
Node サービスのローカル環境と運用環境でメモリの変化を監視するにはどうすればよいですか?
- 青灯夜游転載
- 2020-08-28 10:21:522274ブラウズ
実稼働環境でサーバー言語として 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<pre class="brush:js;toolbar:false">> process.pid
16425</pre> を見つけることができます。 .pid
pid を見つけることができますが、煩雑であまり実用的ではありません。では、非侵襲的な手段で pid を見つけるにはどうすればよいでしょうか?方法は 2 つあります。
- 冗長パラメータと組み合わせる
- ps
プロセスを見つけるポート番号と組み合わせる - 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 を使用してメモリを監視する
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 - :
仮想サイズ、仮想メモリ 出力からわかるように、
top を使用してメモリを監視する
pidstat は sysstat にある Linux パフォーマンス ツールですが、Mac でメモリを見つける方法バラエティ？
<pre class="brush:js;toolbar:false">$ htop -p 31796</pre>
運用環境のメモリ監視
現在の運用環境のほとんどは、
k8s にデプロイされた環境 したがって、運用環境における特定のアプリケーションのメモリ監視は、本質的には、k8s による特定の ワークロード/デプロイメントのメモリ監視になります。メモリ監視metric のデータ フローの方向は大まかに次のとおりです:
-> 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 サイトの他の関連記事を参照してください。