1

以下は、単純なスクリプトを複数回実行したときの CPU 消費グラフをつなぎ合わせたものです。短期間の CPU 消費グラフの変動性に興味をそそられます。これらの曲線が数分以内に劇的に変化する原因が何であるかを知っている人はいますか?

ノード プロセスが一度に 1 つの CPU を占有するようにするドライバー スクリプト:

$ for (( i = 0; i < 8; ++i )) ; do echo CPU: $i; taskset -c $i node ticks_per_second.js; done

スクリプト: Node Ticks per Second Node バージョン: 0.10.8 (NVM を使用してインストール) OS: Ubuntu 12.04 ハードウェア: MacBook Pro 9,1

これは、単一の NodeJS プロセスから生成/処理できるイベントの数の理論的な制限を確認するための演習でした。

PS: NodeJS が得意なタスク (I/O) と苦手なタスク (CPU) を理解しているので、それらの側面について議論する衝動を抑えてください。NodeJS を予測どおりに実行するためのアドバイスを探しています。

nodejsの予測不可能性

4

1 に答える 1

0

Gnome System Monitor が遅れていることがわかりました!!

(注: 次のスクリーンショットでは、上のグラフは KSysGuard によって作成され、下のグラフは Gnome システム モニターから作成されたものです。)

  1. システム モニターが 1 秒ごとにグラフを移動するように、更新間隔を「10」秒に設定する必要があります。(スクリーンショット 1 を参照)

  2. 更新間隔を1秒に設定すると、グラフの動きが速すぎます!! (スクリーンショット 2 を参照)

  3. KSysGuard ははるかに応答性が高く、要求されたときに正確に 1 秒でグラフを更新します。(スクリーンショット 1 を参照)。

ありがたいことに、KSysGuard パッケージは KDE システムの残りの部分に依存していないため、インストールすると GUI と ksysguardd デーモンだけがインストールされ、不要な肥大化は発生しませんでした。

結論: Gnome System Monitor は使用せず、KSysGuard を使用してください。KSysGuard は正しいことを行い、非常に柔軟です。

Gnome システム モニターと KSysGuard の比較

1 秒更新時の Gnome システム モニター

于 2013-06-17T21:03:25.470 に答える