maxdir-size의 영향
변경 제안
PDF
제한을 maxdir-size 높이면 디렉토리 파일의 증가가 허용됩니다. 용량 및 성능 비용은 디렉토리 파일이 실제로 커질 때만 발생하는 반면, 한도에 도달하면 생성 및 이름 변경 작업이 실패합니다.
용량 영향
`maxdir-size`설정을 변경하는 것 자체는 용량을 소모하지 않습니다. 디렉터리 항목의 증가가 용량을 소모합니다. 디렉터리 파일은 이름이 추가될 때마다 4 KiB 블록을 할당하며, 관련 인덱스와 스냅샷에 저장되는 디렉터리 블록은 더 많은 용량을 추가합니다. 용량 제한을 설정해도 해당 공간은 예약되지 않습니다. 삭제 후 최대 용량에 대한 자세한 내용은 link:high-file-count-workloads-02-maxdirsize.html#how-the-maxdir-size-cap-behaves["maxdir-size 제한의 작동 방식"]을 참조하십시오.
`maxdir-size`값을 추정할 때 디렉터리 아래에 저장된 파일은 포함할 필요가 없습니다. 대신 단일 디렉터리에 있는 항목만 고려하십시오. 이 옵션은 볼륨 수준에서 설정되지만 디렉터리 단위로 적용됩니다.
파일 수가 많은 디렉토리의 용량 사용량을 계획할 때는 디렉토리 및 인덱스 오버헤드를 포함해야 합니다. 예를 들어, 각각 320MB 용량 제한까지 커지는 디렉토리가 100개 있는 볼륨은 약 32GB의 디렉토리 파일 메타데이터를 보유하며, 이는 볼륨 사용 용량에 포함됩니다. 해당 디렉토리가 인덱싱되어 있고 공개되어 있는 경우, maxfiles 예산에 약 100개의 inode를 추가해야 합니다. 디렉토리 메타데이터가 자주 변경되는 경우에는 추가 스냅샷 용량을 고려해야 합니다. Snapshot 복사본은 더 이상 사용되지 않는 디렉토리 및 인덱스 블록을 유지하기 때문입니다.
성능 영향
ONTAP 시스템에서 대규모 디렉토리는 다음과 같은 영향을 미칠 수 있습니다.
-
이름 조회, 생성, 연결 해제 및 이름 변경 경로 길이
-
전체 디렉토리 열거 및 와일드카드 검색
-
네임스페이스 처리에 사용되는 CPU 및 메모리
-
인덱스 및 디렉터리 블록을 로드하려면 콜드 캐시 I/O가 필요합니다.
-
장시간 작업 중 프로토콜 지연 시간 및 클라이언트 타임아웃
-
분석, 백업, 복제 또는 보안 기능에 의해 수행되는 네임스페이스 스캔
디렉터리 인덱싱은 대상 조회 비용을 줄여주지만, 매우 큰 평면 디렉터리를 샤딩된 계층 구조와 동일하게 만들어주지는 않습니다. 주변 볼륨이나 클러스터에 사용되지 않는 리소스가 있더라도 단일 디렉터리에 대한 작업은 여전히 직렬화 및 선호도 제한에 부딪힐 수 있습니다. 인덱싱은 조회, 열기, 생성, 이름 변경 및 삭제 등 대상 이름 작업에 도움이 됩니다. 전체 디렉터리 스캔 및 와일드카드 검색은 여전히 디렉터리 네임스페이스를 탐색하며, 인덱스를 이름-블록 바로가기로 사용하지 않습니다. 홀 펀칭된 디렉터리의 경우 인덱스는 READDIR 검색 중에 빈 블록을 건너뛸 수 있지만, 이는 샤딩 레이아웃을 대체할 수는 없습니다.
ONTAP가 성능 저하를 선언하는 별도의 디렉터리 파일 크기는 없습니다. 약 2MiB의 인덱스 임계값("디렉토리 인덱싱이 존재하는 이유"에 설명됨)은 대상 조회 처리 방식을 변경합니다. 이 크기 미만에서는 디렉터리 블록을 스캔하고 임시 메모리 내 해시를 생성하여 이름을 찾을 수 있으므로 디렉터리 크기가 커질수록 비용이 증가하지만 ONTAP는 영구 인덱스를 생성하지 않습니다. 이 크기를 초과하면 대상 이름 작업은 인덱스를 사용합니다. 디렉터리 크기가 커짐에 따라 지속적으로 비용이 증가하는 요소는 전체 열거 및 와일드카드 검색, 디렉터리 및 인덱스 블록의 콜드 캐시 로드, 그리고 해당 디렉터리에 대한 작업의 직렬화입니다.
클라이언트는 더 긴 디렉터리 목록, 와일드카드 검색 및 애플리케이션 스캔, 더 높은 프로토콜 지연 시간 및 해당 작업 중 시간 초과를 경험할 수 있습니다. 디렉터리를 소유한 노드는 데이터 처리량이 낮은 상태로 유지되는 동안 메타데이터에 CPU와 메모리를 사용할 수 있습니다. 이러한 영향은 작업 속도, 동시성, 캐시 상태 및 해당 디렉터리에 집중된 이름 수에 따라 달라집니다. `wafl.dir.size.warning`일반적으로 약 90%의 `maxdir-size`에서 디렉터리가 크기 제한에 가까워지고 있음을 경고합니다. 이는 측정된 지연 시간 임계값을 나타내는 것은 아닙니다.
예를 들어, 해당 디렉토리에서 알려진 파일 하나를 여는 것은 인덱스가 이름 조회를 제공하기 때문에 여전히 빠르게 응답할 수 있습니다. 동일한 디렉토리를 `ls`로 나열하거나, `find`로 탐색하거나, 모든 이름을 읽는 애플리케이션, 백업 또는 보안 검사를 실행하면 실행 시간이 오래 걸리거나, 멈춘 것처럼 보이거나, 클라이언트 또는 애플리케이션 시간 초과가 발생할 수 있습니다. 이 시간 동안 클라이언트는 파일 데이터를 거의 전송하지 않습니다. 이미 열려 있는 파일을 읽거나 쓰는 작업은 일반적으로 영향을 받지 않습니다.
작업 부하가 더 큰 단일 디렉터리를 필요로 하고 구조 변경이 현실적으로 불가능한 경우에만 디렉터리 크기를 늘리십시오. maxdir-size 애플리케이션에서 허용하는 경우 넓거나 깊은 계층 구조를 선호하십시오.
maxdir-size를 초과하면 어떻게 됩니까?
디렉토리 파일이 최대치에 도달하면:
-
ONTAP는 해당 디렉토리에 다른 이름을 추가해야 하는 작업(생성 또는 이름 변경 등)을 거부합니다.
-
클라이언트는 ENOSPC, "파일 크기가 너무 큽니다", NFS 오류 27,
STATUS_CANNOT_MAKE또는 기타 애플리케이션별 생성 또는 이름 변경 실패를 보고할 수 있습니다. -
다른 디렉토리는 용량과 inode가 있는 경우 계속해서 항목을 수락할 수 있습니다.
-
해당 볼륨에는 여전히 사용 가능한 데이터 용량과 공용 inode가 있을 수 있습니다.
-
기존 파일을 읽는 것은 디렉터리 항목을 추가하는 것과 동일하지 않으며 일반적으로 영향을 받지 않습니다.
`maxfiles` 또는 `maxdir-size`을 초과하면 용량 문제처럼 보일 수 있습니다. EMS 메시지를 확인하십시오. 클라이언트 오류가 inode 고갈 오류와 겹칩니다. link:high-file-count-workloads-01-overview.html#maxfiles-compared-with-maxdir-size["Maxfiles와 maxdir-size 비교"]을 참조하십시오.
평면 네임스페이스를 변경할 수 없는 경우, 제어된 maxdir-size 증가 방식을 검토하십시오.
set -privilege advanced volume modify -vserver <svm> -volume <volume> -maxdir-size 327MB
평균 성장률의 경우, 현재 상한값을 약 2%씩 점진적으로 높이십시오. 측정된 요구 사항이 있는 마이그레이션의 경우, 해당 요구 사항보다 약 2% 높은 값으로 상한값을 설정하십시오. 변경 사항은 즉시 적용되며 시스템 중단을 초래하지 않습니다.
나중에 상한값을 낮출 수 있지만, 기존 디렉터리 파일의 최대 크기보다 낮출 수는 없습니다. 상한값을 낮춰도 기존 디렉터리는 압축되지 않습니다. ONTAP 릴리스 및 플랫폼에서 지원되는 값을 확인하고 변경 후 성능을 모니터링하십시오.