ZFS ARC 튜닝: 상한값, 제한값 및 측정 항목

ZFS는 기본적으로 시스템 RAM의 약 절반을 읽기 캐시로 조용히 할당하며, 부적절한 서버 환경에서는 스왑 활동, OOM(메모리 부족)에 의한 프로세스 강제 종료, 또는 데이터베이스와 파일 시스템 간의 메모리 경쟁이 발생할 수 있습니다. ZFS ARC 튜닝은 ARC가 실제로 유지할 수 있는 RAM 용량을 결정하고, 한도를 설정하기 위해 무엇을 포기할지 결정하는 과정입니다. 이 글에서는 ARC가 메모리를 사용하는 방식, 설정을 변경하기 전에 측정해야 할 사항, 변경할 가치가 있는 몇 가지 조정 매개변수, 그리고 파일 서버, 하이퍼바이저, 데이터베이스, 백업 대상에 대한 합리적인 시작점을 다룹니다. ZFS 스냅샷에 대해서는 ZFS 스냅샷 가이드를 참조하십시오.

설정을 조정하기 전에 ARC를 측정하십시오

일반적인 피크 시간대의 기준 수치를 확보하기 전까지는 어떤 조정 가능한 항목도 변경하지 마십시오. 사용량이 적은 시간대의 스냅샷은 잘못된 방향으로 이끌 수 있습니다. 야간 백업, 주간 보고서, 배치 작업은 대개 ARC 동작이 흥미롭게 나타나는 부분이기 때문에, 며칠에 걸쳐 데이터를 수집하십시오.

다음 세 가지 도구만으로도 필요한 대부분의 기능을 다룰 수 있습니다:

• arcstat 1 히트 및 미스 카운터, 수요 대 프리페치 활동, 현재 ARC 크기를 실시간으로 스크롤하며 확인할 수 있습니다. 부하 테스트 및 백업 시간대에 이 도구를 사용하십시오.
• arc_summary 단일 스냅샷을 출력합니다: ARC 크기와 목표값, MFU/MRU 분할, 메타데이터 비율, 활성 튜너블 등. arc_summary -s arc 명령어를 실행하면 ARC 섹션만 확인할 수 있습니다.
• 원시 카운터는 /proc/spl/kstat/zfs/arcstats 에 있으며, kstat.zfs.misc 및 vfs.zfs sysctl 트리 아래에 위치합니다. 포맷된 출력을 파싱하기보다는 모니터링에서 이 카운터 값을 직접 추출하십시오.

변경 전 기록해 둘 가치가 있는 카운터:

이 부분에서 사람들이 흔히 혼동하는 두 가지가 있습니다. ‘사용 가능한 메모리’를 확인해야지, ‘여유 메모리’를 확인해서는 안 됩니다. 리눅스는 여유 RAM이 적은 상태를 정상 상태로 보고하지만, 그 자체만으로는 문제가 되지 않습니다. 중요한 신호는 사용 가능 메모리가 0에 가까우면서 스왑 활동이 지속적으로 발생하는 경우입니다(이유는 리눅스 메모리 관리 입문서에서 다룹니다). 또한 히트 비율은 목표치가 아니라 추세로 간주해야 합니다. 스왑이 발생하는 시스템에서 99%의 히트 비율은 튜닝의 성공이 아니라 실패입니다.

중요한 4가지 ARC 조정 항목

대부분의 운영 환경 튜닝은 네 가지 설정으로 귀결됩니다. 설정을 베이스라인에서 실제로 측정된 부하에 맞춰 조정하십시오. 스왑 활동은 zfs_arc_max로 변경하십시오. 핫 캐시를 계속 지우는 이탈 현상을 해결하려면 zfs_arc_min로 설정하십시오. 디렉터리 탐색 속도가 느린 경우 메타데이터 제한을 확인하십시오.

눈에 띄는 부하 문제를 해결할 수 있는 최소한의 변경 사항부터 시작하십시오. zfs_arc_max, 적절한 상한값은 워크로드에 따라 달라집니다(다음 섹션에서 다룹니다). zfs_arc_min의 경우, 하한값은 zfs_arc_max 25%에서 50% 사이를 하한으로 설정하는 것이 합리적인 시작점입니다(하한 설정이 필요한 경우). 메타데이터의 경우, 최근 OpenZFS 기본 설정은 이미 zfs_arc_meta_limit_percent, 이는 대부분의 워크로드에 대해 넉넉한 수준입니다. 메타데이터 미스 현상이 arcstat.

Linux 및 FreeBSD에서 변경 사항 적용

리눅스에서는 sysfs 매개변수 파일에 값을 기록하여 실행 중에 변경 사항을 테스트할 수 있습니다. 재부팅은 필요하지 않습니다:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

이렇게 하면 zfs_arc_max 를 즉시 16 GiB로 설정합니다. 재부팅 후에도 변경 사항이 유지되도록 하려면 다음 파일에 추가하십시오. /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

FreeBSD에서는 런타임 변경에 sysctl:

sysctl vfs.zfs.arc_max=17179869184

다음에 동일한 값을 영구적으로 저장합니다 /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

한 번에 하나의 설정만 변경하고, 전체 RAM의 약 10% 정도씩 소폭씩 단계적으로 조정하십시오. 문제 발생 창을 주시하십시오. 스왑이 0으로 유지되고 지연 시간이 안정적인 경우에만 변경 사항을 유지하십시오. 런타임 테스트를 통과한 후에만 변경 사항을 영구적으로 적용하십시오.

워크로드에 따른 ARC 조정

전체 RAM 용량부터 고려하는 것은 잘못된 접근 방식입니다. ARC 규모 결정은 해당 시스템의 워크로드 구성에 따라 결정되어야 합니다.

VM 호스트는 게스트와 메모리를 공유해야 하므로, 30%~40%의 상한선은 안전한 기본값이며, 대부분의 빌드에서 50%는 이미 너무 높은 수준입니다. PostgreSQL 및 MySQL과 같은 데이터베이스는 자체 버퍼 캐시를 관리하므로, 먼저 엔진에 메모리를 할당하고 남은 메모리를 ARC에 할당합니다. 백업 대상은 다음과 같은 이점을 얻습니다. primarycache=metadata 읽어온 데이터는 다시 필요할 일이 거의 없으며, 야간 백업이 전체 풀을 훑어가며 진행 과정에서 나머지 캐시를 비우는 것을 원치 않기 때문입니다. 모든 워크로드에 걸쳐, ARC가 고정된 상태에서 스왑 활동이 발생한다면 zfs_arc_max 상태일 때 발생하는 스왑 활동은 상한값이 너무 높다는 것을 의미하며, 이 규칙은 변하지 않습니다.

문제 진단 및 중단 시점 파악

ARC 크기가 너무 작으면 시스템에 여유 RAM이 남아 있음에도 높은 읽기 IOPS, 낮은 수요 적중률, 느린 디렉터리 탐색이 나타납니다. ARC 크기가 너무 큰 경우는 덜 뚜렷합니다. 적중률은 정상으로 보이지만, 시스템에서 스와핑이 시작되고, 부하 평균이 상승하며, 커널이 필요에 따라 ARC 페이지를 회수하는 동안 프로세스가 D 상태에 갇히게 되며, 최악의 경우 OOM 킬러가 희생 대상을 선택하기 시작합니다. 캐시는 정상으로 보이지만 서버 성능은 극도로 저하됩니다.

메타데이터 부하는 demand_metadata_bytes 보다 훨씬 높은 수준에 있을 때 나타납니다 demand_data_bytes 보다 훨씬 높게 나타날 때 발생합니다 arc_summary보다 훨씬 높게 나타날 때 발생합니다. 이는 메타데이터가 데이터와 공간을 놓고 경쟁하고 있는 상황이며, 이때 메타데이터 비율 제한을 높이는 것이 좋습니다.

현재 상황을 확인한 후, 가장 먼저 점검해야 할 설정은 다음과 같습니다:

L2ARC는 무료가 아닙니다. L2ARC 항목에 대한 인덱스는 1차 ARC에 상주하며, 이 오버헤드가 전체 ARC 용량의 약 3분의 1을 초과하면 보조 캐시는 이점보다 해를 더 많이 끼칩니다. 작업 세트가 RAM보다 크지만 여전히 고속 NVMe 장치에 모두 들어갈 수 있을 때, 그리고 주 ARC의 히트 비율이 이미 양호한 경우에만 L2ARC를 활용하십시오.

튜닝을 중단해야 할 적절한 시점은 지연 시간이 안정적으로 유지되고, 원래 문제를 일으켰던 것과 동일한 부하 기간 동안 스왑이 0을 유지하며, 추가적인 변경 사항이 더 이상 어떤 개선 효과도 가져오지 않을 때입니다. 서버가 스왑을 하고 있다면 높은 적중률은 아무 의미가 없습니다. 그 시점이 지나면 설정 조정을 중단하고, 동일한 워크로드에서 같은 문제가 재발할 때만 설정을 재검토하십시오.

VM이나 데이터베이스와 메모리 경쟁 없이 ZFS를 제대로 실행할 수 있는 충분한 RAM 여유 공간을 갖춘 서버가 필요하다면(실제로 필요한 RAM 용량이 얼마인지 먼저 확인해 볼 가치가 있습니다), FDC 전용 서버를 살펴보시기 바랍니다.