私は(今まで)答えられていない質問に従って理解を向上させようとしています。Fedora VMのアップグレード中にディスク、CPU、またはネットワーク以外の制限要因がある可能性がありますか?
次のテストロードを実行しましたが、完了するのに200秒かかりました。
sudo perf trace -s time perf stat dnf -y --releasever=30 --installroot=$HOME/fedora-30 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal
私はFedora Workstation 29の非常に基本的で簡単なインストールでこれを実行しています。仮想マシンではありません。カーネルバージョンは5.0.9-200.fc29.x86_64です。 IOスケジューラはmq-deadline
。
LVMとファイルシステムを使用してくださいext4
。ディスクやファイルシステムに暗号化を使用しません。ネットワークファイルシステムがまったくマウントされていないため、ネットワークファイルシステムで読み書きできません。
私は4つの「CPU」を持っています。それぞれ2つのスレッドがある2つのコアです。
/dev/sda
ディスクはSATA HDD 1つだけです。 HDDはNCQをサポートします:cat /sys/class/block/sda/device/queue_depth
ディスプレイ32
。
vmstat 5
アイドル状態ではなくCPU時間表示時々CPU1個程度まで上がるが、つまりアイドル率が75%程度と低い。
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
...
1 1 3720 1600980 392948 3669196 0 0 14 30634 8769 1876 4 3 78 15 0
1 1 3720 1600144 393128 3669884 0 0 0 3460 1406 1468 0 1 80 18 0
0 1 3720 1599424 393356 3670532 0 0 0 6830 1416 1480 0 1 73 25 0
0 1 3720 1598448 393700 3671108 0 0 0 7766 1420 1362 0 1 78 20 0
0 1 3720 1597296 393940 3671616 0 0 0 5401 1374 1367 1 2 87 11 0
0 1 3720 1596332 394312 3672416 0 0 0 1162 1647 1558 1 2 85 13 0
3 0 3720 1652064 394564 3673540 0 0 0 17897 15406 1784 1 3 74 23 0
0 0 3720 1972876 394600 3541064 0 0 0 522 8028 18327 3 3 84 10 0
1 0 3720 1974152 394600 3541108 0 0 0 9 422 879 2 1 97 0 0
0 0 3720 1974136 394600 3541120 0 0 0 0 204 455 0 0 99 0 0
(end of test)
「IO待機」時間(下の図に示すフィールドwa
)が最大25%まで増加しました。これは1つのCPUを100%意味すると思います。ただし、ここに示されているディスク使用率はこれと直接一致しません。 100%未満:cpu
vmstat
atopsar -d 5
22:46:44 disk busy read/s KB/read writ/s KB/writ avque avserv _dsk_
...
22:49:34 sda 5% 0.4 4.0 69.5 413.0 36.9 0.68 ms
22:49:39 sda 8% 0.2 60.0 120.6 30.6 18.7 0.66 ms
22:49:44 sda 8% 0.0 0.0 136.2 16.7 20.4 0.61 ms
22:49:49 sda 10% 0.0 0.0 157.1 44.2 21.4 0.65 ms
22:49:54 sda 9% 0.0 0.0 196.4 39.3 48.0 0.47 ms
22:49:59 sda 9% 0.0 0.0 148.9 36.6 32.6 0.62 ms
22:50:04 sda 10% 0.0 0.0 137.3 130.6 37.2 0.70 ms
22:50:09 sda 11% 0.0 0.0 199.6 5.4 13.5 0.55 ms
22:50:14 sda 2% 0.0 0.0 50.2 4.5 11.8 0.32 ms
22:50:19 sda 0% 0.0 0.0 0.8 11.0 13.3 0.75 ms
(end of test)
どのように「IO待機」時間がディスク使用率よりも高くなりますか?
以下は、sarのマンページからインポートされた定義です。
%io は次を待ちます:
システムに未解決のディスクI / O要求がある間に1つ以上のCPUがアイドル状態になった時間の割合。
したがって、%iowaitはCPUの観点からは実行できませんが、少なくとも1つのI / Oが進行中であることを意味します。 iowaitは単なる自由時間であり、何も予約できません。この値は、パフォーマンスの問題を示すのに役立つかもしれませんし、そうではないかもしれませんが、ユーザーはシステムがアイドル状態であり、追加の作業が必要になることを知らせます。
https://support.hpe.com/hpsc/doc/public/display?docId=c02783994
マルチ CPU システムで「IO 待機」を定義するのは難しい場合があります。バラよりCPUは、IOが保留中であるかどうかをどうやって知ることができますか?。しかし、上記の「IO待機」数に4を掛けることが間違っていると思っても、それでもディスク使用率の数よりも高いです!
atopsar -d
私は(およびatop
/ sar -d
/ /iostat -x
のディスク使用率の数値mxiostat.py
)が次のいずれかに基づいて計算されると予想しました。カーネル iostat フィールド。リンクされた文書には、「フィールド10 - I / Oの実行に費やされたミリ秒数」が記載されています。より詳細な定義がありますが、そこに記載されている機能が現在マルチキューブロックレイヤにまだ存在するかどうかはわかりません。
perf
testコマンドのおかげで、fdatasync()
dnf呼び出しが200秒の実行時の81秒を担当したことを報告することもできます。この証拠は、「IO待機」データがディスク使用率データよりも正確な印象を与えることを示唆しています。
199.440461084 seconds time elapsed
60.043226000 seconds user
11.858057000 seconds sys
60.07user 12.17system 3:19.84elapsed 36%CPU (0avgtext+0avgdata 437844maxresident)k
496inputs+2562448outputs (25major+390722minor)pagefaults 0swaps
Summary of events:
...
dnf (6177), 2438150 events, 76.0%
syscall calls total min avg max stddev
(msec) (msec) (msec) (msec) (%)
--------------- -------- --------- --------- --------- --------- ------
fdatasync 3157 81436.062 0.160 25.795 465.329 1.92%
wait4 51 43911.444 0.017 861.009 32770.388 74.93%
poll 45188 6052.070 0.001 0.134 96.764 5.58%
read 341567 2718.531 0.001 0.008 1372.100 50.63%
write 120402 1616.062 0.002 0.013 155.142 9.61%
getpid 50012 755.423 0.001 0.015 207.506 32.86%
...
答え1
「IO待機」時間が最大25%増加します。私の考えでは、100%のCPUを意味すると思います。
いいえ、基本的にここから間違って始めます。 I/O 待機には CPU コアがまったく必要ありません。 I/O 待機は、基本的に「このプロセスで CPU を無駄にしないでください。まだ外部操作が完了するのを待っています」を意味するカーネルの状態です。カーネルは、入出力操作が完了したことを確認すると、待機中のプロセスを見つけて再スケジュールします。
したがって、100 個のプロセスが I/O を待機でき、1 秒間に 100 秒の I/O レイテンシが蓄積されます。ただし、CPUが101番目のプロセスを処理している可能性があります。
また、I/O 待機をディスク使用率と比較できます。ディスクは I/O の形式ですが、唯一の形式ではありません。ネットワークソケットも待つことができます。このタイプのI / Oは、リモートファイルシステムを使用すると非表示になることがあります。