昨日、私たちのサーバーの1つで奇妙な動作が発生しました。ps
、pgrep
非常にhtop
遅い(開始時)。 )が一部のプロセスで数秒かかることをstrace ps
示します。read('/proc/$pid/cmdline
なぜこれが起こるのですか?
いくつかの観察:
- プロセス実行可能ファイルはNFSにあります。
- プロセス(約20個以上)もNFSでファイルを並列に実行
unlink
および運営しています。symlink
- 同じ親プロセスから分岐しました。
- 使用可能なRAMは80GB(ほとんどのキャッシュ)ですが、スワップ領域(4GBのみ)は完全に使用されます。
- はいの場合は実行して
while true; do cat /proc/$pid/status; sleep .1; done
すぐcat
に返しますが、はいの場合は数秒かかりました。State
S
R
State
D
私はインターネットを検索し、State
yesのときにD
読み取りが/proc/$pid/cmdline
停止するという答えを見つけました。本当に?どのように動作しますか?/proc/$pid/cmdline
プログラムの開始前に設定された内容がプログラムの開始後に実行された操作の影響を受けるのはなぜですか。
答え1
また、ここで特別な$ pidを得るために/ proc / $ pid / cmdlineを読むことは、StateがRの場合でも非常に遅いです。 NUMAに関連する可能性があることを指摘した上記のリンクのおかげで、numadがプロセスをノードからノードに移動して発生したことがわかりました。これは/var/log/numad.logからのものです。
Thu Jul 18 20:06:41 2019: Advising pid 9565 ($name) move from nodes (0-1) to nodes (1)
Thu Jul 18 20:06:45 2019: PID 9565 moved to node(s) 1 in 3.91 seconds
Thu Jul 18 20:11:50 2019: Advising pid 9565 ($name) move from nodes (1) to nodes (1)
Thu Jul 18 20:12:00 2019: PID 9565 moved to node(s) 1 in 9.72 seconds
Thu Jul 18 20:17:05 2019: Advising pid 9565 ($name) move from nodes (1) to nodes (1)
Thu Jul 18 20:17:23 2019: PID 9565 moved to node(s) 1 in 17.85 seconds
Thu Jul 18 20:22:28 2019: Advising pid 9565 ($name) move from nodes (1) to nodes (1)
Thu Jul 18 20:22:51 2019: PID 9565 moved to node(s) 1 in 22.73 seconds
Thu Jul 18 20:27:56 2019: Advising pid 9565 ($name) move from nodes (1) to nodes (1)
Thu Jul 18 20:28:23 2019: PID 9565 moved to node(s) 1 in 26.88 seconds
Thu Jul 18 20:33:28 2019: Advising pid 9565 ($name) move from nodes (1) to nodes (1)
Thu Jul 18 20:33:44 2019: PID 9565 moved to node(s) 1 in 15.49 seconds
プロセスを移動すると、cmdlineを読み取るのが遅くなります。なぜなら、cmdlineはユーザースペースから取得され、カーネルはページをロックして読む必要があるからです。
プロセス9565はノード1にあるがリモートメモリを使用できるので、後で同じノード1からノード1に移動する必要があるように思われる。
% numactl -s
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
cpubind: 0 1
nodebind: 0 1
membind: 0 1
ありがとうございます。