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 하나뿐입니다 . HDD는 NCQ를 지원합니다: cat /sys/class/block/sda/device/queue_depth디스플레이 32.

vmstat 5유휴 상태가 아닌 CPU 시간 표시때때로CPU 1개 정도까지 올라가는데, 즉 유휴율이 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%까지 증가했습니다. 이것은 하나의 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 요청이 있는 동안 하나 이상의 CPU가 유휴 상태였던 시간의 비율입니다.

따라서 %iowait는 CPU 관점에서 실행할 작업이 없지만 적어도 하나의 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%
...