☰

버스트 순차 쓰기를 위한 ZFS 조정

tag-icon • tag-icon performance zfs openzfs
버스트 순차 쓰기를 위한 ZFS 조정

이는 다음에 대한 후속 조치입니다.대용량 스토리지로 고속 네트워크 쓰기. 설정이 눈에 띄게 바뀌었습니다.

raid-z26개의 드라이브가 있는 단일 풀이 있고 모두 Exos X18 CMR 드라이브입니다. 사용 fio및 수동 테스트를 통해 어레이가 평균적으로 약 800MB/s 순차 쓰기를 유지할 수 있다는 것을 알고 있습니다. 이는 양호하며 이 어레이의 예상 성능과 일치합니다. 이 머신은 32G ECC RAM, NVMe 부팅/시스템 드라이브 및 2x10Gbps 이더넷 포트(Intel x550-T2)를 갖춘 Ryzen5 Pro 2400 GE(4C/8T, 3.8GHz 부스트)입니다. 저는 zfs 2.1.2-1을 사용하여 최신 Arch 시스템을 실행하고 있습니다.

내 사용 사례는 대부분 대용량(~30G) 한 번 쓰고 한 번 읽고 압축된 비디오의 비디오 아카이브입니다. atime, set recordsize=1M, set 을 비활성화했고 데이터가 실제로 압축 불가능하고 테스트 결과 인터넷에서 말한 것보다 성능이 더 나빴고 compressios=off설계 상 중복 데이터가 없었습니다. 이 풀은 Samba를 통해 네트워크에서 공유됩니다. Windows 시스템의 NVMe NTFS에서 NVMe ext4로 전송하는 속도가 1GB/s에 도달할 정도로 네트워크와 Samba를 조정했습니다. 즉, 9K 점보 프레임으로 10Gbps 링크를 포화시키는 데 합리적으로 가깝습니다.dedup=offcompression=lz4off

여기서 문제가 발생합니다. 30G 비디오 아카이브 하나 전체를 1GB/s 속도로 raid-z2800MB/s 순차 쓰기만 지원할 수 있는 어레이 로 전송할 수 있기를 원합니다 . 내 계획은 RAM 기반 더티 페이지를 사용하여 유출을 흡수하고 클라이언트 측에서 전송이 "완료"된 후 디스크에 플러시되도록 하는 것입니다. 나는 (1024-800)*30~=7G전송이 완료된 후 ~10초에 걸쳐 디스크로 플러시될 수 있는 RAM의 더티 페이지 만 필요하다고 생각했습니다 . 나는 이것이 데이터 무결성에 미치는 영향을 이해하며 정전으로 인해 파일이 손실되거나 불완전해지는 경우 최대 한 달 동안 나중에 파일을 언제든지 다시 전송할 수 있으므로 위험은 허용됩니다.

그러나 ZFS가 예상한 대로 작동하도록 할 수 없습니다. /etc/modprobe.d/zfs.conf파일을 다음과 같이 편집했습니다.

options zfs zfs_dirty_data_max_max=25769803776
options zfs zfs_dirty_data_max_max_percent=50
options zfs zfs_dirty_data_max=25769803776
options zfs zfs_dirty_data_max_percent=50
options zfs zfs_delay_min_dirty_percent=80

initramfs를 새로 고치기 위해 적절한 mkinitcpio -P명령을 실행하고 재부팅 후 설정이 적용되었는지 확인했습니다.

# arc_summary | grep dirty_data
        zfs_dirty_data_max                                   25769803776
        zfs_dirty_data_max_max                               25769803776
        zfs_dirty_data_max_max_percent                                50
        zfs_dirty_data_max_percent                                    50
        zfs_dirty_data_sync_percent                                   20

즉, 최대 더티 페이지를 필요한 7G보다 훨씬 많은 24G로 설정하고 이 중 80%가 사용될 때까지 쓰기 지연을 시작합니다. 내가 아는 한, 풀은 대기 시간이 있는 클라이언트(Samba)의 쓰기를 푸시백하기 시작하기 전에 19G를 RAM에 흡수할 수 있어야 합니다.

그러나 Windows 클라이언트에서 글을 쓰는 것을 관찰한 것은 ~1GB/s 쓰기 속도에서 약 16초 후에 쓰기 성능이 절벽에서 떨어지는 것입니다( iostat여전히 디스크가 데이터를 플러시하기 위해 열심히 노력하고 있음을 보여줌). 이는 푸시백이라고만 가정할 수 있습니다. ZFS의 쓰기 제한 메커니즘입니다. 그러나 이는 최소한 16초 동안 아무것도 플러시되지 않았더라도 3초 후에 설정되어야 하므로 의미가 없습니다. 게다가 마지막에 다시 한 번 떨어집니다. 그림을 참조하세요: [ 여기에 이미지 설명을 입력하세요][https://i.stack.imgur.com/Yd9WH.png]

zfs_dirty_data_sync_percent더티 페이지 버퍼가 기본값보다 훨씬 크기 때문에 더 일찍 쓰기를 시작하도록 조정하려고 시도했으며 zfs_vdev_async_write_active_{min,max}_dirty_percent더 일찍 시작하기 위해 활성 IO 스케일링을 조정하여 쓰기 속도를 더 빠르게 얻으려고 시도했습니다. 큰 더티 버퍼. 이 두 가지 모두 절벽의 위치를 ​​약간만 이동시켰을 뿐이고 내가 기대했던 것과는 전혀 가깝지 않았습니다.

질문:

  1. 쓰기 제한 지연이 어떻게 작동하는지 잘못 이해했나요?
  2. 내가 하려는 일이 가능한 일인가?
  3. 그렇다면 내가 뭘 잘못하고 있는 걸까?

예, 알아요. 저는 문자 그대로 몇 초를 쫓고 있으며 이를 달성하는 데 들인 노력을 결코 회복하지 못할 것입니다. 괜찮습니다. 현재로서는 나와 ZFS 사이의 개인적인 문제이며 원칙의 문제입니다. ;)

답변1

또한 매개변수를 현재 기본값인 5초에서 7G/0.2G/s = 35초로 늘려야 하므로 zfs_txg_timeout40초로 설정하면 충분합니다.

귀하의 /etc/modprobe.d/zfs.conf:

options zfs zfs_txg_timeout=40

ARC는 정확히 쓰기 캐시에 관여하지 않는 "읽기" 캐시이므로 블록 쓰기 캐시가 30GB 쓰기 스트림당 흡수해야 하는 추가 7G 이상의 데이터를 소비하도록 ARC가 설정되지 않았는지 확인하세요. ZFS용 쓰기 캐시는 다른 단순 블록 쓰기 캐시(예: commitext4 파일 시스템의 매개변수)와 유사하므로 모든 전송 시나리오 중에 RAM이 부족하지 않도록 비프로덕션에서 테스트해야 합니다.

답변2

zfs Primarycache = all(기본값)인 경우 쓰기마다 ARC가 업데이트됩니다. 현재 쓰고 있는 데이터에 대해 읽기 대기 시간이 중요하지 않다면 zfs Primarycache=meta를 설정하는 것이 좋습니다.

답변3

현재 원하는 항목에 필요한 RAM이나 스토리지 리소스가 충분하지 않습니다.

원하는 I/O 처리량 수준과 최악의 성능을 고려하여 설계하세요.

설명 중인 데이터 작업 세트에 대한 모든 조건에서 1GB/s의 처리량이 필요한 경우 디스크 스핀들 수 또는 인터페이스 처리량이 이를 지원할 수 있는지 확인하십시오.

관련 정보