기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 성능 팁
Amazon FSx for Lustre를 사용할 때는 다음과 같은 성능 관련 팁을 유의하세요. 서비스 제한은 [Amazon FSx for Lustre 서비스 할당량](limits.md) 섹션을 참조하세요.
+ **평균 I/O 크기** - Amazon FSx for Lustre는 네트워크 파일 시스템이므로 각 파일 작업은 클라이언트와 Amazon FSx for Lustre를 왕복하여 진행되므로 약간의 지연 시간 오버헤드가 발생합니다. 이렇게 작업당 지연 시간이 있으므로 평균 I/O 크기가 늘어남에 따라 전체 처리량도 대개 증가합니다. 대량의 데이터에 대해 오버헤드가 분할 사용되기 때문입니다.
+ **요청 모델** - 파일 시스템에 대한 비동기 쓰기를 활성화하여, 보류 중인 쓰기 작업을 Amazon EC2 인스턴스에서 버퍼링했다가 Amazon FSx for Lustre에 비동기식으로 기록합니다. 비동기 쓰기는 일반적으로 지연 시간이 더 짧습니다. 비동기 쓰기를 수행하는 경우 커널은 캐싱에 추가 메모리를 사용합니다. 동기 쓰기를 활성화한 파일 시스템은 Amazon FSx for Lustre에 동기 요청을 보냅니다. 모든 작업은 클라이언트와 Amazon FSx for Lustre 간을 왕복합니다.
**참고**
선택한 요청 모델은 일관성(여러 Amazon EC2 인스턴스를 사용하는 경우)과 속도를 절충합니다.
+ **디렉터리 크기 제한** - Persistent 2 FSx for Lustre파일 시스템에서 최적의 메타데이터 성능을 얻으려면 각 디렉터리를 100K 미만의 파일로 제한합니다. 디렉터리의 파일 수를 제한하면 파일 시스템이 상위 디렉터리에서 잠금을 획득하는 데 필요한 시간이 줄어듭니다.
+ **Amazon EC2 인스턴스** - 다수의 읽기 및 쓰기 작업을 수행하는 애플리케이션은 그렇지 않은 애플리케이션보다 메모리 또는 컴퓨팅 용량이 훨씬 더 많이 필요합니다. 컴퓨팅 집약적 워크로드를 위한 Amazon EC2 인스턴스를 시작할 때 애플리케이션에 필요한 만큼의 충분한 리소스가 있는 인스턴스 유형을 선택합니다. Amazon FSx for Lustre 파일 시스템의 성능 특성은 Amazon EBS 최적화 인스턴스의 사용과 관련이 없습니다.
+ **최적의 성능을 위한 권장 클라이언트 인스턴스 튜닝**
1. 메모리가 64GiB를 초과하는 클라이언트 인스턴스 유형의 경우 다음 조정을 적용하는 것이 좋습니다.
```
sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000
sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>
```
1. vCPU 코어가 64개 이상인 클라이언트 인스턴스 유형의 경우 다음 조정을 적용하는 것이 좋습니다.
```
echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf
echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf
# reload all kernel modules to apply the above two settings
sudo reboot
```
클라이언트가 마운트된 후에는 다음 튜닝을 적용해야 합니다.
```
sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32
sudo lctl set_param mdc.*.max_rpcs_in_flight=64
sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50
```
1. 디렉터리 목록(ls)의 성능을 최적화하려면 다음 튜닝을 적용해야 합니다.
```
sudo lctl set_param llite.*.statahead_max=512
sudo lctl set_param llite.*.statahead_agl=1
if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then
sudo lctl set_param llite.*.statahead_xattr=1
else
echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning"
fi
```
`lctl set_param`은 재부팅하는 경우 지속되지 않는 것으로 알려져 있습니다. 이러한 파라미터는 클라이언트 측에서 영구적으로 설정할 수 없으므로 부팅 크론 작업을 구현하여 권장 튜닝으로 구성을 설정하는 것이 좋습니다.
+ **OST 간 워크로드 밸런스** - 파일 시스템이 제공할 수 있는 총 처리량(스토리지 TiB당 200MBps)을 워크로드로 인해 주도하지 못하는 경우도 있습니다. 그러한 경우 CloudWatch 지표를 사용하여 워크로드 I/O 패턴의 불균형으로 인해 성능이 영향을 받는지 여부를 해결할 수 있습니다. 이것이 원인인지 확인하려면 Amazon FSx for Lustre의 최대 CloudWatch 측정치를 살펴보세요.
경우에 따라 이 통계는 처리량(1.2TiB Amazon FSx for Lustre 디스크 한 개의 처리량 용량) 240MBps 이상의 부하를 보여줍니다. 이 경우 워크로드가 디스크 전체에 고르게 분산되지 않습니다. 이 경우 `lfs setstripe` 명령을 사용하여 워크로드에서 가장 자주 액세스하는 파일의 스트라이핑을 수정할 수 있습니다. 성능을 최적화하려면 파일 시스템을 구성하는 모든 OST에서 처리량이 높은 파일을 스트라이핑합니다.
데이터 리포지토리에서 파일을 가져오는 경우 처리량이 높은 파일을 OST 전체에 고르게 스트라이핑하는 다른 방법을 사용할 수 있습니다. 이렇게 하려면 다음 Amazon FSx for Lustre 파일 시스템을 생성할 때 `ImportedFileChunkSize` 파라미터를 수정하면 됩니다.
예를 들어, 워크로드가 7.0TiB 파일 시스템(6x 1.17TiB OST로 구성)을 사용하고 2.4GiB 파일에서 높은 처리량을 구현해야 한다고 가정해 보겠습니다. 이 경우 파일을 파일 시스템의 OST 전체에 균등하게 분산하도록 `ImportedFileChunkSize` 값을 `(2.4 GiB / 6 OSTs) = 400 MiB`로 설정할 수 있습니다.
+ **Lustre 메타데이터 IOPS용 클라이언트** - 파일 시스템에 메타데이터 구성이 지정된 경우 다음 OS 버전 중 하나에 Lustre 2.15 클라이언트 또는 Lustre 2.12 클라이언트를 설치하는 것이 좋습니다: Amazon Linux 2023, Amazon Linux 2, Red Hat/Rocky Linux 8.9, 8.10 또는 9.x, CentOS 8.9 또는 8.10, 6.2, 6.5 또는 6.8 커널이 포함된 Ubuntu 22\$1 또는 Ubuntu 20.
## Intelligent-Tiering 성능 고려 사항
다음은 Intelligent-Tiering 스토리지 클래스를 사용하는 파일 시스템을 사용할 때 고려해야 할 몇 가지 중요한 성능 고려 사항입니다.
+ Intelligent-Tiering 스토리지 계층의 지연 시간이 길기 때문에 I/O 크기가 작은 데이터를 읽는 워크로드가 큰 I/O 크기를 사용하는 워크로드와 동일한 처리량을 달성하려면 더 높은 동시성이 필요하며 더 많은 요청 비용이 발생합니다. 작은 IO 크기를 사용할 때 더 높은 동시성과 처리량을 지원할 수 있도록 SSD 읽기 캐시를 충분히 크게 구성하는 것이 좋습니다.
+ 클라이언트가 Intelligent-Tiering 파일 시스템으로 얻을 수 있는 최대 디스크 IOPS는 워크로드의 특정한 액세스 패턴 및 SSD 읽기 캐시를 프로비저닝했는지 여부에 따라 달라집니다. 무작위 액세스를 사용하는 워크로드의 경우, 데이터가 캐시에 없을 때보다 SSD 읽기 캐시에 데이터가 캐시될 때 클라이언트가 일반적으로 훨씬 더 높은 IOPS를 얻을 수 있습니다.
+ Intelligent-Tiering 스토리지 클래스는 순차 읽기 요청의 성능을 최적화하기 위해 미리 읽기를 지원합니다. 데이터를 미리 가져오고 성능을 높일 수 있도록 가능하면 데이터 액세스 패턴을 순차적으로 구성하는 것이 좋습니다.