☰

I/O 비효율성의 원인은 무엇입니까?

tag-icon • tag-icon rsync performance file-copy io
I/O 비효율성의 원인은 무엇입니까?

저는 rsync대용량 폴더를 외부 3.5" 드라이브에서 내부 3.5" 드라이브로 옮기고 있습니다. 둘 다 5.400rpm입니다. 이를 사용하여 dstat현재 처리량을 볼 때 다음과 같은 패턴이 자주 나타납니다.

--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 20   6  34  40   0|  98M   90M|1272B 3652B|   0     0 |1702  4455 
 21   6  37  37   0| 121M   90M|1646B 4678B|   0     0 |2057  6488 
 17  24  29  30   0|  77M   95M| 630B 2416B|   0     0 |1581  4644 
 20   5  33  43   0|  86M   84M|1372B 2980B|   0     0 |1560  4146 
 20   6  30  44   0|  80M   75M| 700B 2722B|   0     0 |1484  3942 
 11   2  47  39   0|  39M   65M| 642B 1332B|   0     0 | 765  1507 
  0   0  50  50   0|   0    91M|  70B  354B|   0     0 | 136    70 
  0   0  50  49   0|   0    71M| 306B  346B|   0     0 | 146   119 
  0   0  50  50   0|   0    83M|  70B  346B|   0     0 | 145    60 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  36    84 
  0   0  50  50   0|   0     0 | 164B  646B|   0     0 |  35    71 
  0   0  50  50   0|   0     0 | 140B  802B|   0     0 |  30    64 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  27    68 
  0   0  50  50   0|   0    34M| 134B  346B|   0     0 |  86    68 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  30    71 
  0   0  50  50   0|   0     0 |2320B  346B|   0     0 |  40    76 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  29    71 
  0   0  50  50   0|   0     0 |  70B  346B|   0     0 |  25    50 
 -----------------------------[snip]------------------------------
  0   0  50  50   0|   0     0 |2230B  346B|   0     0 |  35    61 
  0   0  50  50   0|   0    60M|  70B  346B|   0     0 | 118    83 
  1   7  42  50   0| 256k  104M| 230B  500B|   0     0 | 281   480 
 21   5  31  42   0| 117M   76M|1120B 3392B|   0     0 |1849  4309 
 23   5  36  36   0| 137M   56M|1202B 3958B|   0     0 |2149  5782 
 24   5  36  35   0| 138M  100M|1284B 4112B|   0     0 |2174  6021

예를 들어 몇 초에서 1분 내에 읽기 및 쓰기 처리량이 모두 0으로 떨어졌습니다. 여기서 병목 현상은 무엇입니까?

내 말은 두 드라이브의 속도가 거의 같기 때문에 어느 쪽도 너무 오랫동안 유휴 상태로 있어서는 안 된다는 것입니다. 한 단계 더 나아가, 적어도 하나의 드라이브는 항상 읽거나 쓸 수 있어야 합니다. 시스템은 무엇을 기다리고 있나요?

시스템은 유휴 상태이고 CPU를 사용하는 유일한 것은 rsync작업입니다. 메모리는 8GB, CPU는 7세대 i5 쿼드코어다. 내장 하드 드라이브는 SATA를 통해 마더보드(Gigabyte G170X-Ultra Gaming)에 연결됩니다. 두 경우 모두 파일 시스템은 내부(쓰기) 측에서 dmcrypt/LUKS를 사용하여 암호화된 ext4입니다. 이것이 이유일까요? 그렇다면 dmcrypt의 성능을 어떻게 확인할 수 있나요? 전송 손실이 발생하면 CPU는 50% 유휴 상태이고 50% 대기 상태인 것을 알 수 있습니다. 이것으로부터 나는 어떤 결론을 내릴 수 있습니까?

커널 버전을 갖춘 최신 Archlinux입니다 4.13.11-1-ARCH. 주의가 필요한 것이 있나요? 미리 감사드립니다.

고쳐 쓰다: iotop보다 더 정확한 것으로 지적됐다 dstat. 불행하게도 처리량이 0으로 떨어지면 처리량 iotop도 0으로 표시됩니다. dstat내가 하나 만들었어스크린캐스트그것을 보여주기 위해.

답변1

일부 블록 수준 장치 통계를 얻을 수 있는 두 가지 도구 세트가 있습니다. 첫 번째는지연브렌든 그레그에서성능 도구. 이는 디스크 작업 대기 시간에 대한 간단한 히스토그램을 생성합니다. 예를 들면 다음과 같습니다.

>=(ms) .. <(ms)   : I/O      |Distribution                          |
     0 -> 1       : 1913     |######################################|
     1 -> 2       : 438      |#########                             |
     2 -> 4       : 100      |##                                    |
     4 -> 8       : 145      |###                                   |
     8 -> 16      : 43       |#                                     |
    16 -> 32      : 43       |#                                     |
    32 -> 64      : 1        |#                                     |

도구 세트의 또 다른 스크립트는 iosnoop명령과 해당 작업을 표시합니다. 예를 들면 다음과 같습니다.

COMM         PID    TYPE DEV      BLOCK        BYTES     LATms
/usr/bin/mon 31456  R    8,0      9741888      4096       2.14
/usr/bin/mon 31456  R    8,0      9751408      4096       0.16
/usr/bin/mon 31456  R    8,0      20022728     4096       1.44
/usr/bin/mon 31456  R    8,0      19851752     4096       0.26
jbd2/sda3-41 416    WS   8,0      130618232    65536      1.89
jbd2/sda3-41 416    WS   8,0      209996928    65536      1.92
jbd2/sda3-41 416    WS   8,0      210006528    8192       1.94

이후블록 추적패키지는 낮은 수준의 블록 작업을 기록한 다음 다음 blktrace의 blkparse간단한 요약을 포함하여 다양한 정보와 기타 많은 명령을 표시합니다.bttpdf 사용자 가이드):

$ sudo blktrace /dev/sda  # ^C to stop
=== sda ===
  CPU  0:                  180 events,        9 KiB data
  CPU  1:                 1958 events,       92 KiB data
  Total:                  2138 events (dropped 0),      101 KiB data
$ ls -ltra # one file per cpu
-rw-r--r--    1 root   root       8640 Nov  5 10:16 sda.blktrace.0
-rw-r--r--    1 root   root      93992 Nov  5 10:16 sda.blktrace.1
$ blkparse -O -d combined.output  sda.blktrace.*  # combine cpus
$ btt -i combined.output 
    ALL           MIN           AVG           MAX           N
Q2Q               0.000001053   0.106888548   6.376503027         253
Q2G               0.000000795   0.000002266   0.000011060         184
G2I               0.000000874   0.000979485   0.002588781         328
Q2M               0.000000331   0.000000599   0.000002716          70
I2D               0.000000393   0.000480112   0.002435491         328
M2D               0.000002044   0.000028418   0.000126845          70
D2C               0.000080986   0.001925224   0.010111418         254
Q2C               0.000087025   0.002603157   0.010120629         254
...

예를 들어 D2C는 하드웨어 장치가 작업을 수행하는 데 걸리는 시간입니다.

sudo smartctl -a /dev/sda각 디스크에서 실행하여 결함이 있는지 확인할 수도 있습니다.

답변2

나는 이것이 dstat응용 프로그램 호출에 대한 파일 설명자 수준 I/O 통계를 사용하고 write()시스템 dstat호출이 반환되면 데이터가 증가하는 것을 볼 것이라고 추측합니다.

하지만 그렇다고 해서 데이터가 실제로 기록되었다는 의미는 아닙니다. 일시 정지된 것처럼 보이는 이러한 단계는 버퍼가 블록 장치에 기록되는 단계인 것으로 추측됩니다. 이는 이 시간 동안 I/O 대기 값 dstat이 데이터 전송이 측정되는 단계보다 훨씬 높다는 점에서 의미가 있습니다.

iotop디스크와 캐시에 대한 쓰기와 읽기를 구별합니다. 어쩌면 이 도구는 흥미로운 추가 정보를 제공할 수도 있습니다.

관련 정보