LVM을 사용하는 경우보다 랜덤 쓰기가 더 빠른 이유는 무엇입니까?


0

나는 fio를 가진 EMMC 장치의 랜덤 쓰기 속도를 측정하고있다.

여러 개의 io 크기로 여러 블록 크기를 테스트하고 있습니다.

원시 emmc 장치의 모든 테스트 케이스에 대해 여러 번 반복 한 후 전체 emmc 장치를 사용하여 논리 볼륨을 만들고 해당 볼륨에서 동일한 테스트를 실행합니다 (예 : / dev / new_vol_group / new_logical_volume).

LVM에서 약간의 성능 오버 헤드가 예상되었지만 가장 이상한 일이 발생했습니다.

크기가 작 으면 쓰기 속도가 원시와 LVM간에 매우 유사합니다. IO 크기를 늘리면 (특히 크기가 RAM의 두 배가되는 경우) 원시 장치의 임의 쓰기 속도가 상당히 느려지지만 LVM에서는 그렇지 않습니다. 파일 크기를 늘리면 LVM의 임의 쓰기 속도가 감소하지 않습니다.

따라서 LVM은 대용량 파일 시스템을위한 임의의 쓰기 액세스를위한 원시 장치보다 훨씬 빠릅니다. 이것은 임의 쓰기의 경우에만 해당됩니다. 순차적 읽기 쓰기 또는 임의 읽기 테스트로이 동작을 보지 못했습니다.

이것은 내 파일입니다.

ioengine=libaio 
direct=1 
buffered=0  
iodepth=1
numjobs=1
ramp_time=5
startdelay=5
runtime=90
time_based
refill_buffers
randrepeat=1

내가 생각할 수있는 유일한 이유는 캐싱 이었지만, io 크기가 호스트의 양 램의 두 배가 될 때 캐싱은 테스트에 큰 영향을 미치지 않습니다.

참고 : 벤치마킹에는 fio-3.1, 호스트는 Ubuntu 18.04 LTS를 사용합니다.
여러 장치에서이 동작을 감지했습니다.

편집 : 속도 차이를 나타내는 그래프를 추가했습니다.

원시 매퍼 장치에 대한 LVM 임의 쓰기 속도 LVM random write speeds againts the raw mapper device

원시 장치 임의 쓰기 속도 Raw device random write speeds


여전히 데이터의 절반을 캐싱하고 있다면, 속도는 2 ~ 6GB / s가 될 수 있으며, 디스크의 실제 속도를 평균하면 여전히 결과가 많이 증가 할 것입니다
Xen2050

그렇다면 non-lvm 파티션에도 동일한 캐싱이 적용되어야합니다. 맞습니까?
Can

1
필자는 테스트 방법에 의존한다고 생각합니다. 파일을 사용하면 어디서나 캐시 될 수 있지만 장치는 실제로 캐시되지 않습니다. 괜찮은 테스트 프로그램은 아마도 어쨌든 캐싱을 피할 것이지만, 나는 lvm의 모든 세부 사항을 확신 할 수 없다. 어쨌든 lvm 유무에 따른 실제 속도 결과는 무엇입니까? 반복 테스트를 통해 동일한 차이가 발생했는지, 아니면 "랜덤 노이즈"일까요?
Xen2050

1
흠, 파일 시스템에 대해 fio를 사용하고 있습니까? 아니면 원시 장치 매퍼 장치에 대해 직접 fio를 사용하고 있습니까? 또한 fio 작업 파일이 불완전 해 보입니다. 명령 줄에서도 작업을 지정하고 있습니까? 마지막으로 다른 실행에서 다른 fio 출력이 무엇입니까 (예 : 현재 질문에서 원시 파티션 대 LVM의 대기 시간 통계를 볼 수 없음)?
Anon

안녕하세요 @ 애논, 원시 장치와 LVM 매퍼 장치 사이의 속도 비교를위한 히스토그램 그래프를 추가했습니다. 당신도 맞습니다. 저는 명령 줄에서 물건을 지정하고 있습니다. 나는 그들이 중요하다고 생각하지 않았습니다.
Can
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.