ロードアベレージが非常に高いが、無視しても良いのか知りたいです

Question

前提・実現したいこと

topコマンド実行時のロードアベレージが非常に高いが、無視しても良いのか知りたい

画像解析アプリケーションを検証しています。
画像解析アプリケーションは、姿勢推定機能を使用しており、GPUで姿勢推定や機械学習を行っています。
TOPコマンドを打った際に非常にロードアベレージが高く出ました(150くらい　40コア)。
しかしながら、どこにボトルネックがあるのか確認できていません。
現在試したこと以外で、どこにボトルネックがあるか探す方法はあるでしょうか。
また、ボトルネックが見つからなかった時に、放置しても良いようなものなのでしょうか。

発生している問題・エラーメッセージ

ロードアベレージが高すぎて問題なのではないかと考えています

top - 07:52:35 up 6 days, 19:03, 1 user, load average: 136.57, 143.51, 146.73
Tasks: 633 total, 7 running, 411 sleeping, 0 stopped, 2 zombie
%Cpu(s): 44.8 us, 43.3 sy, 0.0 ni, 11.8 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 98601792 total, 2853336 free, 72502128 used, 23246324 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 24964940 avail Mem

試したこと

以下のコマンドをインターネットで調べながら確認していきました。
ロードアベレージが高いが、CPUやメモリのリソースに余裕がある場合はI/Oがボトルネックである事が多いというようなネット記事が多かったのですが、いまいちI/Oもボトルネックではないように見えています。

top

top - 07:49:33 up 6 days, 19:00, 1 user, load average: 148.26, 146.80, 148.15
Tasks: 633 total, 6 running, 412 sleeping, 0 stopped, 2 zombie
%Cpu(s): 44.4 us, 43.2 sy, 0.0 ni, 12.2 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 98601792 total, 2821140 free, 72537224 used, 23243428 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 24929848 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11983 root 20 0 11.745g 1.234g 182496 S 218.8 1.3 1785:14 python3
13552 root 20 0 11.797g 1.207g 180996 S 211.2 1.3 1732:31 python3
12424 root 20 0 11.794g 1.210g 179468 S 210.9 1.3 1683:08 python3
11539 root 20 0 11.798g 1.220g 179900 S 210.2 1.3 1623:36 python3
12879 root 20 0 11.797g 1.210g 179968 S 201.3 1.3 1609:26 python3

～省略～

vmstat

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
184 0 0 2831028 1777096 21452184 0 0 0 20 1 1 35 40 25 0 0
139 0 0 2792812 1777100 21452200 0 0 0 80 56135 9777848 44 45 11 0 0
160 1 0 2814908 1777100 21452224 0 0 0 13728 54827 9785076 43 44 12 0 0
115 0 0 2840560 1777100 21452244 0 0 0 68 62746 9359162 44 43 13 0 0
90 0 0 2852672 1777100 21452256 0 0 0 0 65141 10166382 43 44 12 0 0
150 0 0 2790320 1777100 21452272 0 0 0 0 57738 9751493 44 44 12 0 0
187 0 0 2832980 1777104 21452280 0 0 0 124 53390 10013404 43 45 12 0 0

iostat

iostat 5
avg-cpu: %user %nice %system %iowait %steal %idle
44.42 0.00 43.45 0.00 0.00 12.13

Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn
loop0 0.00 0.00 0.00 0 0
loop1 0.00 0.00 0.00 0 0
loop2 0.00 0.00 0.00 0 0
sda 0.40 0.00 14.40 0 72
sdb 0.00 0.00 0.00 0 0

avg-cpu: %user %nice %system %iowait %steal %idle
44.30 0.00 43.83 0.00 0.00 11.87

Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn
loop0 0.00 0.00 0.00 0 0
loop1 0.00 0.00 0.00 0 0
loop2 0.00 0.00 0.00 0 0
sda 23.00 0.00 2685.60 0 13428
sdb 0.00 0.00 0.00 0 0

nvidia-smi

$ nvidia-smi
Thu Sep 16 08:04:38 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.33.01 Driver Version: 440.33.01 CUDA Version: 10.2 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Quadro RTX 4000 On | 00000000:3B:00.0 Off | N/A |
| 30% 53C P0 44W / 125W | 7040MiB / 7982MiB | 16% Default |
+-------------------------------+----------------------+----------------------+
| 1 Quadro RTX 4000 On | 00000000:5E:00.0 Off | N/A |
| 30% 56C P0 55W / 125W | 6976MiB / 7982MiB | 14% Default |
+-------------------------------+----------------------+----------------------+
| 2 Quadro RTX 4000 On | 00000000:AF:00.0 Off | N/A |
| 30% 54C P0 43W / 125W | 6998MiB / 7982MiB | 19% Default |
+-------------------------------+----------------------+----------------------+
| 3 Quadro RTX 4000 On | 00000000:D8:00.0 Off | N/A |
| 30% 51C P0 37W / 125W | 6172MiB / 7982MiB | 7% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 8998 C python3 1639MiB |
| 0 8999 C python3 1625MiB |
| 0 9000 C python3 1649MiB |
| 0 10072 C python3 705MiB |
| 0 10073 C python3 705MiB |
| 0 10074 C python3 705MiB |
| 1 9041 C python3 1619MiB |
| 1 9081 C python3 1615MiB |
| 1 9082 C python3 1615MiB |
| 1 10114 C python3 705MiB |
| 1 10154 C python3 705MiB |
| 1 10194 C python3 709MiB |
| 2 9083 C python3 1617MiB |
| 2 9162 C python3 1637MiB |
| 2 9203 C python3 1615MiB |
| 2 10235 C python3 705MiB |
| 2 10236 C python3 705MiB |
| 2 10276 C python3 705MiB |
| 3 9243 C python3 1615MiB |
| 3 9267 C python3 1223MiB |
| 3 9285 C python3 1223MiB |
| 3 10392 C python3 705MiB |
| 3 10580 C python3 705MiB |
| 3 10630 C python3 689MiB |
+-----------------------------------------------------------------------------+

補足情報（スペック）

Ubuntu 18.04.5 LTS

CPU

• Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz x 2
• 物理CPU 2
• CPUコア数 10
• 論理プロセッサー数 40

GPU

• RTX4000 x 4

メモリ

• 16GB x 6

画像解析ソフトウェア

• Dockerコンテナ上で稼働
• Docker 19.03
• nvidia-container-toolkit

アドバイスいただけますと幸いです。
よろしくお願いいたします。

(END)

Answer 1

%sys が%userと同じくらいですね
発行されるシステムコールの観測ではstraceが利用できるので、-C など利用してトレースするとなにか見えるかも
load avg は定点でシステム上に存在しているプロセス数なので、高いと負荷指標にはなりますが、それ自体からなにかわかるものでも、
問題と言えるものでもないです。動作上遅延して問題と考えるなら、あとは perf つかってじりじり見ていくといいかもです

Comments

[tyamzak_]

ありがとうございます。
strace, perf　共に初めてのコマンドでした。

現在試している所です。
straceはDockerコンテナには、デフォルトでは使えず、設定変更が必要なようでした。
現在コンテナを停止できず、シルバーウィーク空けの確認となりそうです。

[tyamzak_]

### strace結果

ffmpeg
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
97.20 26.769853 2249 11902 1494 futex
1.11 0.307052 736 417 nanosleep
0.81 0.222102 5 44370 write
0.44 0.121206 4 33887 recvfrom
0.43 0.118110 3 33889 poll
0.01 0.002941 9 339 select
0.00 0.000022 11 2 sendto
0.00 0.000022 6 4 openat
0.00 0.000010 3 4 read
0.00 0.000010 10 1 restart_syscall
0.00 0.000009 2 4 close
0.00 0.000008 2 4 fcntl
------ ----------- ----------- --------- --------- ----------------
100.00 27.541345 124823 1494 total

app.py
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
42.21 265.100002 199 1330512 sched_yield
32.74 205.634972 61660 3335 select
14.98 94.096801 1747 53847 9546 futex
5.55 34.848079 2389 14586 read
3.49 21.948856 87099 252 epoll_wait
0.82 5.173953 1724651 3 2 restart_syscall
0.05 0.324977 1533 212 sendmsg
0.05 0.304617 659 462 write
0.02 0.106219 321 331 munmap
0.02 0.099491 27 3733 clock_gettime
0.01 0.089264 58 1534 stat
0.01 0.053793 18 3066 lseek
0.01 0.050567 16 3066 3066 ioctl
0.01 0.050282 33 1533 close
0.01 0.050274 914 55 madvise
0.01 0.044424 29 1533 openat
0.01 0.034989 23 1533 fstat
0.00 0.025543 139 184 mprotect
0.00 0.021227 142 150 mremap
0.00 0.017072 24 725 425 recvmsg
0.00 0.016795 70 240 mmap
0.00 0.012639 27 470 wait4
0.00 0.000013 7 2 getcwd
------ ----------- ----------- --------- --------- ----------------
100.00 628.104849 1421364 13039 total

[tyamzak_]

ご教示いただいた、straceコマンドを、システムコールを勉強しながら見ています。
処理時間の多いプロセス２つを調べ、futexやioctlというものでエラーが多いという事が確認できました。

futexのエラーは、処理待ちのconnectiontimedout、ioctlはInappropriate ioctl for deviceというもので、エラーというよりはファイルの種別判定に使っているようでした。
動作遅延はなさそうに感じていますので、とりあえずこれで問題ない事にしようと思います。
ありがとうございます。