test.sh나는 다음을 수행하는 간단한 스크립트를 작성했습니다 . while true; do cp ./target-file ./target-file.tmp; done여기서는 target-filecreate를 사용 하고 출력이 dd if=/dev/urandom of=target-file bs=1M count=100있습니다 .du -h target-file101M target-file
프로세스의 디스크 IO를 측정하기 위해 htop을 사용해 보았습니다. 이 모든 열을 활성화했습니다(htop에서 사용 가능: F2-> "열" 선택 -> 오른쪽 하단으로 스크롤).
다음은 특정 시점의 샘플 출력입니다(맨 아래 행 참조).
나는 여러 매개변수를 알고 있습니다: RD_CHAR보다 큼 WR_CHAR및 RD_SYSC보다 큼 WR_SYSC. 논리적으로 작동하려면 cp먼저 파일을 읽은 다음 파일에 써야 합니다. 그래서 그것은 의미가 있습니다.
그러나 은 DISK_READ일관 0.00 B/s되고 . 분명히 이것이 프로세스가 초당 바이트를 읽지 않는다는 것을 의미한다고 가정하는 것은 잘못된 것입니다. 또는 읽는 것보다 더 많은 정보를 쓴다고 가정하는 것도 올바르지 않습니다.IO_RBYTESIO_WBYTES
질문IO_RBYTES: 보고된 매우 낮은 합계 값을 논리적으로 이해하는 방법은 무엇입니까 DISK_READ?
답변1
/proc/$pid/io다음 필드에 대한 기록을 찾을 수 있습니다.https://man7.org/linux/man-pages/man5/proc.5.html
rchar: 읽은 문자 수 이
작업으로 인해 저장소에서 읽은 바이트 수입니다. 이는 단순히 프로세스가 read(2) 및 유사한 시스템 호출로 전달한 바이트의 합계입니다. 여기에는 터미널 I/O 등이 포함되며 실제 물리적 디스크 I/O가 필요한지 여부에 영향을 받지 않습니다(읽기는 페이지 캐시에서 이미 충족되었을 수 있음).wchar: 기록된 문자 수 이
작업으로 인해 디스크에 기록되었거나 기록되어야 했던 바이트 수입니다. rchar와 유사한 경고가 여기에 적용됩니다.read_bytes: 바이트 읽기는
이 프로세스가 실제로 스토리지 계층에서 가져온 바이트 수를 계산하려고 시도합니다. 이는 블록 지원 파일 시스템의 경우 정확합니다.write_bytes: 쓴 바이트 수 이
프로세스의 결과로 스토리지 계층으로 전송된 바이트 수를 계산하려고 시도합니다.
이러한 정의에는 몇 가지 핵심적인 미묘함이 있습니다.
나는 몇 가지 매개변수를 알고 있습니다. RD_CHAR은 WR_CHAR보다 크고, RD_SYSC는 WR_SYSC보다 큽니다. 논리적으로 cp가 작동하려면 먼저 파일을 읽은 다음 파일에 써야 합니다. 그래서 그것은 의미가 있습니다.
예, 맞습니다. 하지만 더 많은 것이 있습니다. rchar메트릭에는 wcharSTDIN, STDOUT, STDERR, 네트워크 등을 포함한 모든 읽기 및 쓰기가 포함됩니다. 이제 and 를
사용하고 있는데 이는 그다지 많은 출력을 제공하지 않으므로 이 특정 시나리오에서는 큰 의미가 없어야 합니다. 차이. 그러나 이는 보다 복잡한 프로세스를 다룰 때 주의해야 할 사항입니다.cpdd
그러나 DISK_READ는 항상 0.00B/s이고 IO_RBYTES는 IO_WBYTES보다 훨씬 작습니다. 분명히 이것이 프로세스가 초당 바이트를 읽지 않는다는 것을 의미한다고 가정하는 것은 잘못된 것입니다.
이 동작을 이해하는 열쇠는 다음과 같습니다.
read_bytes: 바이트 읽기는
이 프로세스가 실제로 스토리지 계층에서 가져온 바이트 수를 계산하려고 시도합니다.
귀하의 경우 입력 데이터는 여전히 페이지 캐시에 있으므로 실제로 디스크에 액세스하는 것이 아니라 메모리에서 읽는 것입니다. 그러나 새 파일에 쓰는 중이므로 출력이 디스크에 기록됩니다.
Tl;Dr: *문자 표시에는 다음이 포함됩니다.프로세스의 모든 I/O, 디스크, TTY, 네트워크 등을 포함합니다. *바이트 측정항목만 해당물리적 디스크 I/O.