IO レイテンシがディスク使用率より高い。これは不可能ではありませんか？ [コピー]

私は（今まで）答えられていない質問に従って理解を向上させようとしています。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％未満：cpuvmstatatopsar -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の実行に費やされたミリ秒数」が記載されています。より詳細な定義がありますが、そこに記載されている機能が現在マルチキューブロックレイヤにまだ存在するかどうかはわかりません。

perftestコマンドのおかげで、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%
...