FIO 사용

FIO 사용

LUKS 암호화 파티션 위에 ZFS를 사용하는 것과 ZFS의 기본 데이터 세트별 암호화를 사용하는 것에 대한 논의가 있었습니다. 그러나 항상 둘 중 하나 또는 둘 중 하나의 방식으로 표시됩니다.

제 질문은 LUKS 파티션을 생성한 다음 이를 zpool 컨테이너로 사용한 다음 해당 zpool에 ZFS 암호화 데이터 세트를 생성하는 두 가지 방법을 모두 사용하는 것에 관한 것입니다. 이는 메타데이터 유출 없이 저장 시 암호화를 제공하는 동시에 zfs send암호화된 데이터 세트를 신뢰할 수 없는 백업 저장소에 저장하는 것과 같은 몇 가지 깔끔한 트릭을 허용해야 합니다.

이 경우 이 "이중 암호화"는 ZFS 기본 암호화와 비교하여 성능에 어떤 영향을 미치나요?

답변1

이에 대해 몇 가지 테스트를 수행했으므로 여기에 몇 가지 숫자가 있습니다. 이것은 내가 생각할 수 있는 첫 번째 측면에서 측정된다는 점을 명심하세요. 더 자세한 내용이 포함된 다른 답변을 원합니다.

모든 테스트는 32G RAM, 스왑 없음, 최소 ARC 크기 1G, 최대 ARC 크기 3G(영향을 받는 경우)를 사용하여 수행되었습니다.

FIO 사용

나는 이것을 시도했고 fio --refill_buffers --rw=randrw --name=test --size=5G --numjobs=5보고된 헤더 번호는 다음과 같습니다:

ZFS 기본 데이터세트 암호화만 가능

   READ: bw=25.6MiB/s (26.9MB/s), 5252KiB/s-5325KiB/s (5378kB/s-5453kB/s), io=12.5GiB (13.4GB), run=492550-499123msec
  WRITE: bw=25.7MiB/s (26.9MB/s), 5252KiB/s-5320KiB/s (5378kB/s-5447kB/s), io=12.5GiB (13.4GB), run=492550-499123msec

LUKS 암호화 zpool의 ZFS 기본 데이터 세트 암호화

   READ: bw=17.5MiB/s (18.4MB/s), 3589KiB/s-3619KiB/s (3676kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec
  WRITE: bw=17.6MiB/s (18.4MB/s), 3596KiB/s-3619KiB/s (3682kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec

따라서 FIO는 상당한 대역폭 차이를 보여줍니다. 하지만 실제 사용에 더 가까운 것을 시도하고 싶어서 소스에서 Glasgow Haskell Compiler 9.8.2 및 LLVM 0e5a53cc01e406436cb7c703c84598e474d635de를 컴파일해 보았습니다.

GHC 9.8.2 컴파일

Hadrian의 내장 프로파일링 도구를 사용하여 기본 설정과 32개의 스레드를 사용하여 새로운 빌드를 실행했습니다.

ZFS 전용

빌드 시간: 직렬 3시간 30분, 병렬 25분 21초. 가장 긴 단일 빌드 규칙 GHC/Hs/Instances.p_o은 1분 23초입니다.

ZFS가 LUKS보다 낫습니다.

빌드 시간: 직렬 3시간 34분, 병렬 25분 16초. 가장 긴 단일 빌드 규칙 GHC/Hs/Instances.p_o은 1분 23초입니다.

LLVM 컴파일

기본 플래그를 사용하여 Ninja 빌더는 18개의 컴파일 스레드와 2개의 링커 스레드를 사용합니다(메모리 부족을 방지하기 위해). Ninja에 프로파일링 지원이 있는지 모르므로 그냥 time.

ZFS 전용

real    61m40.229s
user    542m57.056s
sys     49m29.346s

ZFS가 LUKS보다 낫습니다.

real    61m25.019s
user    542m51.777s
sys     48m58.462s

일부 무작위 SQLite 벤치마크

ZFS 전용

fillseq      :      38.833 micros/op;                 
fillseqsync  :    1391.493 micros/op;               
fillseqbatch :       1.954 micros/op;                 
fillrandom   :      62.420 micros/op;                 
fillrandsync :    1406.985 micros/op;               
fillrandbatch :      36.149 micros/op;                
overwrite    :      84.639 micros/op;    1.3 MB/s     
overwritebatch :      68.687 micros/op;               
readrandom   :      58.584 micros/op;                 
readseq      :      42.483 micros/op;                 
fillrand100K :     867.440 micros/op;  1           
fillseq100K  :     851.599 micros/op;  11          
readseq      :       0.461 micros/op;                 
readrand100K :      99.846 micros/op;              

ZFS가 LUKS보다 낫습니다.

fillseq      :      38.453 micros/op;                 
fillseqsync  :    1454.040 micros/op;               
fillseqbatch :       2.035 micros/op;                 
fillrandom   :      63.107 micros/op;                 
fillrandsync :    1531.823 micros/op;               
fillrandbatch :      36.717 micros/op;                
overwrite    :      82.490 micros/op;    1.3 MB/s     
overwritebatch :      68.175 micros/op;               
readrandom   :      46.421 micros/op;                 
readseq      :      42.086 micros/op;                 
fillrand100K :     849.366 micros/op;  11          
fillseq100K  :     837.989 micros/op;  11          
readseq      :       0.461 micros/op;                 
readrand100K :      98.598 micros/op;              

요컨대

FIO의 원시 IO 성능만 보면 상당한 격차가 있음을 알 수 있습니다. 읽기 및 쓰기 대역폭 모두 약 30% 감소한 것으로 보입니다. 그러나 인터리브된 IO 및 계산이 많이 포함되는 실제 사용에서는 차이가 본질적으로 사라집니다.

관련 정보