Amazon EFS 성능 - Amazon Elastic File System
성능 요약스토리지 클래스성능 모드처리량 모드성능 팁

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon EFS 성능

다음 섹션에서는 Amazon EFS 성능에 대한 개요를 제공하고 파일 시스템 구성이 주요 성능 차원에 미치는 영향을 설명합니다. 또한 파일 시스템의 성능을 최적화하기 위한 몇 가지 중요한 팁과 권장 사항도 제공합니다.

주제

성능 요약

파일 시스템 성능은 일반적으로 지연 시간, 처리량 및 초당 입력/출력 작업()의 차원을 사용하여 측정됩니다IOPS. 이러한 차원에 걸친 Amazon EFS 성능은 파일 시스템의 구성에 따라 달라집니다. 다음 구성은 Amazon EFS 파일 시스템의 성능에 영향을 미칩니다.

  • 파일 시스템 유형 - Regional 또는 One Zone

  • 성능 모드 - 범용 또는 최대 I/O

    중요

    최대 I/O 성능 모드는 범용 성능 모드보다 작업당 지연 시간이 더 깁니다. 더 빠른 성능을 위해 항상 범용 성능 모드를 사용하는 것이 좋습니다. 자세한 내용은 성능 모드 단원을 참조하십시오.

  • 처리량 모드 - 탄력적, 프로비저닝 또는 버스팅

다음 표에는 범용 성능 모드를 사용하는 파일 시스템의 성능 사양과 파일 시스템 유형 및 처리량 모드의 가능한 다양한 조합이 요약되어 있습니다.

범용 성능 모드를 사용하는 파일 시스템의 성능 사양
스토리지 및 처리량 구성 지연 시간 최대 IOPS 최대 처리량

파일 시스템 유형

처리량 모드

읽기 작업

쓰기 작업

읽기 작업

쓰기 작업

Per-file-system 읽기 1

Per-file-system 쓰기 1

클라이언트별 읽기/쓰기

리전

 탄력적

최저 250마이크로초(µs)

 최저 2.7밀리초(ms) 90,000~250,0002 50,000

초당 10~60기가비바이트(GiBps)

1~5 GiBps

초당 1,500메비바이트(MiBps)3

리전

 프로비저닝됨

최저 250µs

 최저 2.7ms 55,000 25,000

3~10 GiBps

1~3.33 GiBps

 500 MiBps

리전

 Bursting

최저 250µs

 최저 2.7ms 35,000 7,000

3~5 GiBps

1~3 GiBps

 500 MiBps

One Zone

 탄력적, 프로비저닝됨, 버스트

최저 250µs

최저 1.6ms

 35,000 7,000

3 GiBps4

1 GiBps4

 500 MiBps
참고

각주:

  1. 최대 읽기 및 쓰기 처리량은 AWS 리전에 따라 달라집니다. 처리량이 AWS 리전의 최대 처리량을 초과하는 경우 처리량 할당량을 늘려야 합니다. 추가 처리량에 case-by-case 대한 모든 요청은 Amazon EFS 서비스 팀에 의해 고려됩니다. 승인은 워크로드 유형에 따라 달라질 수 있습니다. 할당량 증가 요청에 대해 자세히 알아보려면 Amazon EFS 할당량 섹션을 참조하세요.

  2. 탄력적 처리량을 사용하는 파일 시스템은 자주 액세스IOPS하지 않는 데이터의 경우 최대 90,000개의 읽기를, 자주 액세스하는 데이터의 IOPS 경우 250,000개의 읽기를 실행할 수 있습니다. 최대 를 달성하기 위해 추가 권장 사항이 적용됩니다IOPS. 자세한 내용은 처리량과 처리량이 높은 워크로드 최적화 IOPS 단원을 참조하십시오.

  3. 탄력적 처리량을 사용하고 Amazon EFS 클라이언트(amazon-efs-utils 버전) 또는 Amazon EFS CSI 드라이버() 버전 2.0 이상을 사용하여 탑재된 MiBps 파일 시스템의 경우 최대 읽기 및 쓰기 결합 처리량은 1,500입니다aws-efs-csi-driver. 다른 모든 파일 시스템의 경우 처리량 제한은 500입니다 MiBps. Amazon EFS 클라이언트에 대한 자세한 내용은 섹션을 참조하세요. Amazon EFS 클라이언트 설치

  4. 버스팅 처리량을 사용하는 하나의 영역 파일 시스템은 버스팅 처리량을 사용하여 리전 파일 시스템과 동일한 per-file-system 읽기 및 쓰기 처리량을 구동할 수 있습니다(읽기용 최대 읽기 5개 및 쓰기 GiBps 용 최대 GiBps 읽기 3개).

스토리지 클래스

Amazon EFS 스토리지 클래스는 사용 사례에 따라 가장 효과적인 스토리지를 위해 설계되었습니다.

  • EFS 표준 스토리지 클래스는 솔리드 스테이트 드라이브(SSD) 스토리지를 사용하여 자주 액세스하는 파일에 대해 가장 낮은 수준의 지연 시간을 제공합니다. 이 스토리지 클래스는 읽기의 경우 250마이크로초, 쓰기의 경우 2.7밀리초의 1바이트 지연 시간을 제공합니다.

  • EFS 빈번하지 않은 액세스(IA) 및 EFS 아카이브 스토리지 클래스는 자주 액세스하는 데이터에 필요한 지연 시간 성능이 필요하지 않은 덜 자주 액세스하는 데이터를 저장합니다. 이러한 스토리지 클래스는 수십 밀리초의 첫 번째 바이트 지연 시간을 제공합니다.

EFS 스토리지 클래스에 대한 자세한 내용은 섹션을 참조하세요EFS 스토리지 클래스.

성능 모드

AmazonEFS은 범용 및 최대 I/O라는 두 가지 성능 모드를 제공합니다.

  • 범용 모드는 작업당 지연 시간이 가장 낮으며 파일 시스템의 기본 성능 모드입니다. 하나의 영역 파일 시스템은 항상 범용 성능 모드를 사용합니다. 더 빠른 성능을 위해 항상 범용 성능 모드를 사용하는 것이 좋습니다.

  • 최대 I/O 모드는 범용 모드보다 긴 지연 시간을 견딜 수 있는 고도로 병렬화된 워크로드용으로 설계된 이전 세대 성능 유형입니다. One Zone 파일 시스템 또는 탄력적 처리량을 사용하는 파일 시스템에서는 최대 I/O 모드가 지원되지 않습니다.

    중요

    최대 I/O에서는 작업당 지연 시간이 길어지기 때문에 모든 파일 시스템에 범용 성능 모드를 사용하는 것이 좋습니다.

범용 성능 모드를 사용하여 워크로드가 파일 시스템에서 사용할 수 있는 IOPS 한도 내에 있도록 하려면 PercentIOLimit CloudWatch 지표를 모니터링할 수 있습니다. 자세한 내용은 CloudWatch Amazon 지표 EFS 단원을 참조하십시오.

애플리케이션은 성능 모드와 관련된 한도까지 IOPS 탄력적으로 확장할 수 있습니다. 에 대해서는 별도로 요금이 청구되지 않으며 파일 시스템의 처리량 계산에 IOPS포함됩니다. 모든 네트워크 파일 시스템(NFS) 요청은 4KB(킬로바이트) 처리량 또는 실제 요청 및 응답 크기 중 큰 값으로 처리됩니다.

처리량 모드

파일 시스템의 처리량 모드에 따라 파일 시스템에서 사용할 수 있는 처리량이 결정됩니다. AmazonEFS은 탄력적, 프로비저닝 및 버스팅이라는 세 가지 처리량 모드를 제공합니다. 쓰기 처리량보다 높은 읽기 처리량을 제공할 수 있도록 읽기 처리량이 할인됩니다. 각 처리량 모드에서 사용할 수 있는 최대 처리량은 AWS 리전에 따라 달라집니다. 지역별 최대 파일 시스템 처리량에 대한 자세한 내용은 Amazon EFS 할당량을 참조하세요.

파일 시스템은 읽기 및 쓰기 처리량을 합쳐 100%를 달성할 수 있습니다. 예를 들어 파일 시스템이 읽기 처리량 한도의 33%를 사용하는 경우 그 파일 시스템은 동시에 쓰기 처리량 한도의 최대 67%까지 달성할 수 있습니다. 콘솔의 파일 시스템 세부 정보 페이지에 있는 처리량 사용률(%) 그래프에서 파일 시스템의 처리량 사용량을 모니터링할 수 있습니다. 자세한 내용은 처리량 성능 모니터링 단원을 참조하십시오.

파일 시스템의 올바른 처리량 모드 선택

파일 시스템에 적합한 처리량 모드를 선택하는 것은 워크로드의 성능 요구 사항에 따라 달라집니다.

  • 탄력적 처리량(권장) - 예측하기 어려운 급증하거나 예측할 수 없는 워크로드 및 성능 요구 사항이 있거나 애플리케이션이 5% 이하의 비율로 처리량을 구동하는 경우 기본 탄력적 처리량을 average-to-peak 사용합니다. 자세한 내용은 탄력적 처리량 단원을 참조하십시오.

  • 프로비저닝된 처리량 - 워크로드의 성능 요구 사항을 알고 있거나 애플리케이션이 5% 이상의 비율로 처리량을 구동할 때 프로비저닝된 처리량을 average-to-peak 사용합니다. 자세한 내용은 프로비저닝된 처리량 단원을 참조하십시오.

  • 버스트 처리량 - 파일 시스템의 스토리지 양에 따라 확장되는 처리량을 원하는 경우 버스트 처리량을 사용합니다.

    버스트 처리량을 사용한 후 애플리케이션이 처리량이 제한되어 있는 경우(예: 허용된 처리량의 80% 이상을 사용하거나 모든 버스트 크레딧을 사용한 경우) 탄력적 또는 프로비저닝된 처리량을 사용해야 합니다. 자세한 내용은 처리량 버스트 단원을 참조하십시오.

Amazon CloudWatch 을 사용하여 MeteredIOBytes 지표와 PermittedThroughput 지표를 비교하여 워크로드의 average-to-peak 비율을 확인할 수 있습니다. Amazon EFS 지표에 대한 자세한 내용은 섹션을 참조하세요CloudWatch Amazon 지표 EFS.

탄력적 처리량

탄력적 처리량을 사용하는 파일 시스템의 경우 Amazon은 워크로드 활동의 요구 사항을 충족하기 위해 처리량 성능을 EFS 자동으로 확장하거나 축소합니다. 탄력적 처리량은 예측하기 어려운 성능 요구 사항이 있는 급증하거나 예측할 수 없는 워크로드 또는 처리량을 평균 최고 처리량( average-to-peak비율)의 5% 이하로 높이는 애플리케이션에 가장 적합한 처리량 모드입니다.

탄력적 처리량이 있는 파일 시스템의 처리량 성능은 자동으로 확장되므로 애플리케이션 요구 사항을 충족하기 위해 처리량 용량을 지정하거나 프로비저닝할 필요가 없습니다. 읽거나 쓰는 메타데이터 및 데이터의 양에 대해서만 요금을 지불하며 탄력적 처리량을 사용하는 동안에는 버스트 크레딧이 누적되거나 소비되지 않습니다.

참고

탄력적 처리량은 범용 성능 모드를 사용하는 파일 시스템에서만 사용할 수 있습니다.

리전별 탄력적 처리량 제한에 대한 자세한 내용은 섹션을 참조하세요늘릴 수 있는 Amazon EFS 할당량.

프로비저닝된 처리량

프로비저닝된 처리량을 사용하면 파일 시스템의 크기 또는 버스트 크레딧 밸런스와 관계없이 파일 시스템이 구동할 수 있는 처리량 수준을 지정합니다. 워크로드의 성능 요구 사항을 알고 있거나 애플리케이션이 처리량을 비율의 5% 이상으로 구동하는 경우 프로비저닝된 처리량을 average-to-peak 사용합니다.

프로비저닝된 처리량을 사용하는 파일 시스템의 경우 파일 시스템에 대해 활성화된 처리량에 대한 요금이 부과됩니다. 한 달에 청구되는 처리량은 Standard 스토리지에서 파일 시스템에 포함된 기준 처리량을 초과하여 프로비저닝된 처리량을 기준으로 하며, AWS 리전의 일반적인 버스팅 기준 처리량 한도까지 초과하여 청구됩니다.

파일 시스템의 기준 처리량이 프로비저닝된 처리량 양을 초과하는 경우 파일 시스템에 허용되는 버스트 처리량을 자동으로 사용합니다(해당 의 일반적인 \Bursting 기준 처리량 한도까지 AWS 리전).

RegionProvisioned 처리량당 제한에 대한 자세한 내용은 섹션을 참조하세요늘릴 수 있는 Amazon EFS 할당량.

처리량 버스트

파일 시스템의 스토리지 양에 따라 확장되는 처리량이 필요한 워크로드에는 버스트 처리량이 권장됩니다. 버스트 처리량을 사용하면 기본 처리량은 표준 스토리지 클래스의 파일 시스템 크기에 비례하며 스토리지의 각 GiB KiBps 당 50입니다. 버스트 크레딧은 파일 시스템이 기본 처리량 이하로 소비할 때 누적되고, 처리량이 기본 속도를 초과하면 차감됩니다.

버스트 크레딧을 사용할 수 있는 경우 파일 시스템은 스토리지 TiB당 최대 100 MiBps개의 처리량을 최소 100개 AWS 리전 로 제한할 수 있습니다 MiBps. 버스트 크레딧을 사용할 수 없는 경우 파일 시스템은 스토리지 TiB MiBps 당 최대 50개를 최소 1개까지 구동할 수 있습니다 MiBps.

리전별 버스팅 처리량에 대한 자세한 내용은 섹션을 참조하세요General resource quotas that cannot be changed.

Amazon EFS 버스트 크레딧 이해

버스트 처리량을 사용하면 각 파일 시스템은 EFS 표준 스토리지 클래스에 저장된 파일 시스템의 크기에 따라 결정되는 기준 속도로 시간이 지남에 따라 버스트 크레딧을 획득합니다. 기준 속도는 스토리지의 테비바이트 MiBps 당 50[TiB]입니다(스토리지의 GiB KiBps 당 50에 해당). Amazon EFS 미터는 쓰기 작업 속도의 최대 1/3까지 읽기 작업을 수행하므로 파일 시스템이 읽기 처리량의 GiB KiBps 당 최대 150 또는 쓰기 처리량의 GiB KiBps 당 50의 기준 속도를 구동할 수 있습니다.

파일 시스템은 기준 측정 속도로 지속적으로 처리량을 높일 수 있습니다. 파일 시스템은 비활성 상태이거나 처리량이 기준 측정 속도 이하로 떨어질 때마다 버스트 크레딧을 누적합니다. 누적된 버스트 크레딧은 파일 시스템에 처리량을 기준 속도 이상으로 끌어올릴 수 있는 기능을 제공합니다.

예를 들어 표준 스토리지 클래스에서 100GiB의 측정 데이터를 사용하는 파일 시스템의 기준 처리량은 5입니다 MiBps. 24시간 동안 활동이 없으면 파일 시스템은 432,000MiB 상당의 크레딧(5MiB × 86,400초 = 432,000MiB)을 획득하며, 이를 사용하여 100에서 72분 MiBps 동안 버스트할 수 있습니다(432,000MiB ÷ 100 MiBps = 72분).

1TiB보다 큰 파일 시스템은 나머지 50%의 시간 동안 비활성 상태이면 최대 50%의 시간 동안 항상 버스트할 수 있습니다.

다음 표는 버스팅 동작의 예를 보여 줍니다.

파일 시스템 크기 버스트 처리량 기준 처리량
Standard 스토리지에 있는 100GiB의 측정된 데이터

  • 하루에 최대 72분 동안 읽기 전용으로 300(MiBps)으로 버스트 또는

  • 하루 최대 72분 동안 100 MiBps 쓰기 전용으로 버스트

  • 최대 15개의 MiBps 읽기 전용 연속 드라이브

  • 최대 5개의 MiBps 쓰기 전용 연속 드라이브
Standard 스토리지에 있는 1TiB의 측정된 데이터

  • 하루에 12시간 동안 300 MiBps 읽기 전용으로 버스트 또는

  • 하루 12시간 동안 100 MiBps 쓰기 전용으로 버스트

  • Drive 150 MiBps read 전용 연속

  • Drive 50 MiBps write-only 연속
Standard 스토리지에 있는 10TiB의 측정된 데이터

  • 하루에 12시간 동안 3 GiBps 읽기 전용으로 버스트 또는

  • 하루 12시간 동안 1 GiBps write-only로 버스트

  • 드라이브 1.5 GiBps 읽기 전용 연속

  • Drive 500 MiBps write-only 연속
일반적으로 규모가 더 큰 파일 시스템

  • 하루에 12시간 동안 스토리지 TiB당 300 MiBps 개 읽기 전용으로 버스트 또는

  • 하루에 12시간 동안 스토리지 TiB당 100 MiBps 쓰기 전용으로 버스트

  • 스토리지의 TiB당 지속적으로 150 MiBps 읽기 전용 드라이브

  • 스토리지의 TiB당 지속적으로 드라이브 50 MiBps write 전용
참고

Amazon은 기준 속도가 낮더라도 MiBps 모든 파일 시스템에 대해 1의 측정 처리량을 EFS 제공합니다.

기준 및 버스트 속도를 결정하는 데 사용되는 파일 시스템 크기는 DescribeFileSystems API 작업을 통해 사용할 수 있는 ValueInStandard 측정 크기입니다.

파일 시스템이 획득할 수 있는 최대 크레딧 잔고는 1TiB보다 작은 파일 시스템의 경우 2.1TiB이고, 1TiB보다 큰 파일 시스템의 경우 저장된 TiB당 2.1TiB입니다. 즉, 파일 시스템은 최대 12시간 동안 연속으로 버스트하는 데 충분한 크레딧을 축적할 수 있습니다.

처리량 전환 및 프로비저닝된 양 변경에 대한 제한

기존 파일 시스템의 처리량 모드를 전환하고 처리량을 변경할 수 있습니다. 그러나 처리량 모드를 프로비저닝된 처리량으로 전환하거나 프로비저닝된 처리량 양을 변경한 후에는 24시간 동안 다음 작업이 제한됩니다.

  • 프로비저닝된 처리량 모드에서 탄력적 또는 버스트 처리량 모드로 전환합니다.

  • 프로비저닝된 처리량을 줄입니다.

Amazon EFS 성능 팁

Amazon EFS를 사용할 때는 다음 성능 팁을 염두에 두세요.

평균 I/O 크기

Amazon의 분산 속성은 높은 수준의 가용성, 내구성 및 확장성을 EFS 가능하게 합니다. 이러한 분산 아키텍처로 인해 각 파일 작업에서 약간의 지연 오버헤드가 생기는데, 이렇게 작업당 지연 시간이 있으므로 평균 I/O 크기가 늘어남에 따라 전체 처리량도 대개 증가합니다. 대량의 데이터에 대해 오버헤드가 분할 사용되기 때문입니다.

처리량과 처리량이 높은 워크로드 최적화 IOPS

처리량이 높고 가 필요한 워크로드의 경우 범용 성능 모드 및 탄력적 처리량으로 구성된 리전 파일 시스템을 IOPS사용합니다.

참고

자주 액세스하는 데이터에 IOPS 대해 최대 250,000개의 읽기를 달성하려면 파일 시스템에서 탄력적 처리량을 사용해야 합니다.

최고 수준의 성능을 달성하려면 다음과 같이 애플리케이션 또는 워크로드를 구성하여 병렬화를 활용해야 합니다.

  1. 최소한 사용 중인 클라이언트 수와 동일한 수의 디렉터리를 사용하여 모든 클라이언트와 디렉터리에 워크로드를 균등하게 분배하십시오.

  2. 개별 스레드를 별개의 데이터 세트 또는 파일에 맞게 조정하여 경합을 최소화합니다.

  3. 단일 탑재 대상에 NFS 클라이언트당 최소 64개의 스레드를 사용하여 10개 이상의 클라이언트에 워크로드를 분산합니다.

동시 연결

최대 수천 개의 Amazon EC2 및 기타 AWS 컴퓨팅 인스턴스에 Amazon EFS 파일 시스템을 동시에 탑재할 수 있습니다. 더 많은 인스턴스에서 병렬화할 수 있는 애플리케이션인 경우, 인스턴스 간 집계를 통해 파일 시스템의 처리량을 더 높은 수준으로 끌어올릴 수 있습니다.

요청 모델

파일 시스템에 비동기 쓰기를 활성화하면 보류 중인 쓰기 작업이 Amazon EC2 인스턴스에서 버퍼링된 후 Amazon에 EFS 비동기적으로 기록됩니다. 비동기 쓰기는 일반적으로 지연 시간이 더 짧습니다. 비동기 쓰기를 수행하는 경우 커널은 캐싱에 추가 메모리를 사용합니다.

동기 쓰기를 활성화했거나 캐시를 우회하는 옵션(예: O_DIRECT)을 사용하여 파일을 여는 파일 시스템은 Amazon 에 동기 요청을 발행합니다EFS. 모든 작업은 클라이언트와 Amazon 간의 왕복을 거칩니다EFS.

참고

선택한 요청 모델은 일관성과 속도 면에서 절충점이 있습니다(여러 Amazon EC2 인스턴스를 사용하는 경우). 동기 쓰기를 사용하면 다음 요청을 처리하기 전에 각 쓰기 요청 트랜잭션을 완료하여 데이터 일관성을 높일 수 있습니다. 비동기 쓰기를 사용하면 보류 중인 쓰기 작업을 버퍼링하여 처리량을 높일 수 있습니다.

NFS 클라이언트 마운트 설정

EFS파일 시스템 마운트과 Linux의 마운팅 고려 사항에 설명된 대로 권장 탑재 옵션을 사용하고 있는지 확인하세요.

Amazon EC2 인스턴스에 파일 시스템을 탑재할 때 Amazon은 Network File System 버전 4.0 및 4.1(NFSv4) 프로토콜을 EFS 지원합니다. NFSv4.1은 병렬 소형 파일 읽기 작업(초당 10,000개 파일 초과)에서 NFSv4.0(초당 1,000개 파일 미만)에 비해 더 나은 성능을 제공합니다. macOS Big SurEC2를 실행하는 Amazon macOS 인스턴스의 경우 NFSv4.0만 지원됩니다.

다음 탑재 옵션은 사용하지 마세요.

  • noac, actimeo=0, acregmax=0, acdirmax=0 - 이 옵션은 성능에 매우 큰 영향을 미치는 속성 캐시를 비활성화합니다.

  • lookupcache=pos, lookupcache=none - 이 옵션은 성능에 매우 큰 영향을 미치는 파일 이름 조회 캐시를 비활성화합니다.

  • fsc - 이 옵션은 로컬 파일 캐싱을 활성화하지만 NFS 캐시 일관성은 변경하지 않으며 지연 시간을 줄이지 않습니다.

참고

파일 시스템을 탑재할 때는 NFS 클라이언트의 읽기 및 쓰기 버퍼 크기를 1MB로 늘리는 것이 좋습니다.

소규모 파일 성능 최적화

파일 다시 열기를 최소화하고, 병렬 처리를 증가시키고, 가능한 경우 참조 파일을 번들링하여 소규모 파일의 성능을 개선할 수 있습니다.

  • 서버로의 왕복 횟수를 최소화하세요.

    나중에 워크플로에서 필요할 경우 파일을 불필요하게 닫지 마세요. 파일 설명자를 열어 두면 캐시에 있는 로컬 사본에 직접 액세스할 수 있습니다. 파일 열기, 닫기 및 메타데이터 작업은 일반적으로 비동기적으로 또는 파이프라인을 통해 수행할 수 없습니다.

    소규모 파일을 읽거나 쓸 때는 두 번의 추가 왕복이 중요합니다.

    각 왕복(파일 열기, 파일 닫기)에는 메가바이트 단위의 대량 데이터를 읽거나 쓰는 시간만큼 걸릴 수 있습니다. 컴퓨팅 작업을 시작할 때 입력 또는 출력 파일을 한 번 열고 전체 작업 기간 동안 열어 두는 것이 더 효율적입니다.

  • 병렬 처리를 사용하면 왕복 시간이 미치는 영향을 줄일 수 있습니다.

  • 참조 파일을 .zip 파일로 번들링합니다. 일부 애플리케이션은 크기가 작고 대부분 읽기 전용인 참조 파일을 대량으로 사용합니다. 이러한 파일을 하나의 .zip 파일로 번들링하면 한 번의 열고 닫기 왕복으로 여러 파일을 읽을 수 있습니다.

    .zip 형식을 사용하면 개별 파일에 무작위로 액세스할 수 있습니다.

디렉터리 성능 최적화

동시에 수정되는 매우 큰 디렉터리(10만 개 이상의 파일ls)에서 목록()을 수행할 때 Linux NFS 클라이언트는 응답을 반환하지 않고 전화를 끊을 수 있습니다. 이 문제는 Amazon Linux 2 커널 4.14, 5.4, 5.10으로 이식된 커널 5.11에서 수정되었습니다.

가능하면 파일 시스템의 디렉터리 수를 10,000개 미만으로 유지하는 것이 좋습니다. 중첩된 하위 디렉터리를 최대한 많이 사용하세요.

디렉터리를 목록을 작성할 때 필요하지 않은 파일 특성은 디렉터리 자체에 저장되지 않으므로 가져오지 마세요.

NFS read_ahead_kb 크기 최적화

NFS read_ahead_kb 속성은 순차 읽기 작업 중에 Linux 커널이 미리 읽거나 미리 가져올 수 있는 킬로바이트 수를 정의합니다.

Linux 커널 버전 5.4.* 이전의 경우 read_ahead_kb 값은 값 rsize(탑재 옵션에 설정된 클라이언트 구성 읽기 버퍼 크기)에 NFS_MAX_READAHEAD를 곱하여 설정됩니다. 권장 탑재 옵션을 사용할 경우 이 공식은 read_ahead_kb을 15MB로 설정합니다.

참고

Linux 커널 버전 5.4.*부터 Linux NFS 클라이언트는 기본read_ahead_kb값 128KB를 사용합니다. 이 값을 15MB로 늘리는 것이 좋습니다.

amazon-efs-utils 버전 1.33.2 이상에서 사용할 수 있는 Amazon EFS 탑재 도우미는 파일 시스템을 탑재한 후 read_ahead_kb 값을 15 * rsize또는 15MB로 자동 수정합니다.

Linux 커널 5.4 이상의 경우 탑재 도우미를 사용하여 파일 시스템을 탑재하지 않는 경우 성능 향상을 위해 수동으로 read_ahead_kb를 15MB로 설정하는 것이 좋습니다. 파일 시스템을 탑재한 후 다음 명령을 사용하여 read_ahead_kb 값을 재설정할 수 있습니다. 이 명령을 사용하기 전에 다음 값을 교체하세요.

  • read-ahead-value-kb를 원하는 크기(킬로바이트)로 교체합니다.

  • efs-mount-point를 파일 시스템의 탑재 포인트를 교체합니다.

device_number=$(stat -c '%d' efs-mount-point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo read-ahead-value-kb > /sys/class/bdi/$major:$minor/read_ahead_kb"

다음 예제는 read_ahead_kb 크기를 15MB로 설정합니다.

device_number=$(stat -c '%d' efs)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 15000 > /sys/class/bdi/$major:$minor/read_ahead_kb"