iostat에서 관찰 된 iops와 fio에서 관찰 된 iops가 다른 이유는 무엇입니까?

Question

최근에 fio를 사용하여 디스크를 테스트하려고합니다. 다음과 같이 FIO의 내 구성은 다음과 같습니다

[global] 
invalidate=0 # mandatory 
direct=1 
#sync=1 
fdatasync=1 
thread=1 
norandommap=1 
runtime=10000 
time_based=1 

[write4k-rand] 
stonewall 
group_reporting 
bs=4k 
size=1g 
rw=randwrite 
numjobs=1 
iodepth=1 

를이 구성에서, 당신은 내가 직접 IO를 사용하여 임의 쓰기를 할 FIO를 구성했는지 알 수 있습니다. 테스트가 실행되는 동안 iostat를 사용하여 I/O 성능을 모니터링했습니다. 그리고 나는 그것을 찾았습니다 : fdatasync를 1로 설정하면 fio로 관찰 한 iops는 약 64이고 iostat에서 관찰 한 iops는 약 170입니다. 왜 이것이 다른가요? 그리고 "fdatasync"를 구성하지 않으면 두 iops는 거의 같지만 450 정도가 훨씬 더 높습니다. 왜? 내가 아는 한, direct io는 페이지 캐시를 통과하지 못한다. 내 의견으로는 fdatasync가 사용되는지 여부와 상관없이 거의 같은 시간이 걸릴 것이라는 의미이다.

그리고 어떤 경우에는 iostat가 잘못된 통계를 나타낼 수 있다고 들었습니다. 진짜야? 정확히 어떤 상황으로 인해 iostat가 잘못 될 수 있습니까? I/O 성능을 모니터링하는 데 사용할 수있는 다른 도구가 있습니까?

Answer 1

작업 파일을 보면 블록 장치에 대한 I/O가 아니라 파일 시스템 내의 파일에 대한 I/O를 수행하고있는 것처럼 보입니다. 따라서 파일 시스템에 "해당 위치의이 데이터를 그 파일에 저장"할 것을 요청할 수도 있지만 파일 시스템은 해당 파일과 관련된 메타 데이터 (예 : 저널, 파일 타임 스탬프, 쓰기시 복사 등)를 업데이트해야하기 때문에 여러 블록 장치 요청으로 바뀔 수 있습니다.) 너무. 따라서 요청이 디스크 (iostat로 측정하고있는 것)로 전송되면 원래 요청이 증폭됩니다.

Linux에서 디스크에 대한 ioscheduler가있을 수 있음을 명심해야합니다. 이렇게하면 디스크에 제출하기 전에 요청을 재 배열, 분할 및 병합/스택에서 더 위로 반환 할 수 있습니다. 병합/재배치를 피하는 방법에 대해서는 nomerges의 다른 매개 변수 https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt을 참조하십시오. 그러나 너무 큰 요청의 분할은 제어 할 수 없으므로 (파일 시스템이 지나치게 큰 요청을하지는 않음) 유의하십시오.

(추 신 : iostat이 "잘못되었습니다"라는 것을 알지 못 했으므로 직접 말한 사람들에게 무엇을 의미하는지 물어봐야 할 수도 있음)