성능에 대한 고려사항

이 페이지에서는 최상의 성능을 얻기 위해 Parallelstore 환경을 구성하는 방법을 안내합니다.

일반 권장사항

  • 기본 성능을 개선하려면 ls에서 모든 별칭을 삭제합니다. 많은 시스템에서는 기본 Parallelstore 구성에서 훨씬 느린 ls -color=auto에 별칭이 지정됩니다.

  • 목록 작업의 성능이 느린 경우 dfuse 마운트에 캐싱을 사용 설정해 보세요.

가로채기 라이브러리

libioil 라이브러리는 libc를 사용하는 애플리케이션에서 DFuse에 대한 읽기 및 쓰기 작업의 성능을 개선하는 데 사용할 수 있습니다. 이 라이브러리는 애플리케이션의 POSIX 읽기 및 쓰기 호출을 가로채 커널을 우회하여 사용자 공간에서 직접 서비스합니다. 자세한 내용은 가로채기 라이브러리를 참고하세요.

대부분의 경우 프로세스별 또는 애플리케이션별 호출에서 가로채기 라이브러리를 사용하는 것이 좋습니다.

가로채기 라이브러리를 사용하지 않거나 사용할 필요가 없는 상황은 다음과 같습니다.

  • libc로 빌드된 애플리케이션만 가로채기 라이브러리를 사용할 수 있습니다.
  • 동일한 파일에 반복적으로 액세스하는 등 캐싱의 이점을 활용하는 워크로드가 있는 경우 가로채기 라이브러리를 사용하지 않는 것이 좋습니다.
  • 워크로드가 메타데이터 집약적인 경우(예: 많은 소형 파일 작업 또는 매우 큰 디렉터리 목록) 가로채기 라이브러리가 성능을 개선하지 못할 수 있습니다.

LD_PRELOAD 호출은 셸 환경에서 환경 변수로 설정할 수 있지만 이렇게 하면 문제가 발생할 수 있습니다. 대신 각 명령어로 지정하는 것이 좋습니다.

또는 컴파일 시 -lioil 플래그를 사용하여 가로채기 라이브러리를 애플리케이션에 연결할 수 있습니다.

dfuse 캐싱

캐싱은 기본적으로 dfuse에서 사용 설정되어 있습니다.

Parallelstore 인스턴스를 마운트할 때 dfuse에서 사용하는 두 가지 캐시 관련 플래그가 있습니다.

  • --disable-wb-cache는 쓰기 백 캐싱이 아닌 쓰기 스루를 사용합니다.
  • --disable-caching는 모든 캐싱을 사용 중지합니다.

다음 제안사항은 캐싱 및 성능에 적용됩니다.

  • 가로채기 라이브러리를 사용하는 경우 워크 백 캐싱이 우회됩니다. 가로채기 라이브러리를 사용할 때는 --disable-wb-cache를 지정하는 것이 좋습니다.
  • 워크로드에서 한 번에 여러 파일을 읽어야 하는 경우 캐싱을 사용 중지해야 합니다.
  • 많은 클라이언트가 파일을 수정하고 다른 클라이언트에서 즉시 업데이트를 사용할 수 있어야 하는 워크로드의 경우 캐싱을 사용 중지해야 합니다.
  • 워크로드에서 동일한 파일을 반복적으로 읽는 경우 캐싱으로 성능을 개선할 수 있습니다. 이는 파일이 클라이언트의 메모리에 들어맞는 경우에 특히 그렇습니다. dfuse는 캐싱에 Linux 페이지 캐시를 사용합니다.

  • 대용량 파일에 대한 작은 I/O로 구성된 워크로드의 경우 캐싱을 사용 설정하는 것 외에도 dfuse 선행 읽기를 늘리는 것이 유용할 수 있습니다. dfuse 선행 읽기를 늘리려면 dfuse가 마운트된 후 다음 명령어를 실행합니다.

    echo 4096 > /sys/class/bdi/\$(mountpoint -d /mnt)/read_ahead_kb
echo 100 > /sys/class/bdi/\$(mountpoint -d /mnt)/max_ratio

워크로드에 위의 시나리오가 혼합된 경우 동일한 Parallelstore 인스턴스를 여러 마운트 지점에 다른 캐싱 설정으로 마운트할 수 있습니다.

스레드 수 및 이벤트 큐 수

Parallelstore 인스턴스를 마운트할 때 --thread-count 및 --eq-count에 다음 값을 사용하는 것이 좋습니다.

  • 스레드 수 값은 vCPU 코어 수를 초과해서는 안 됩니다.
  • 권장되는 최대 스레드 개수 값은 16~20개입니다. 이 숫자를 초과하면 사용 가능한 코어 수와 관계없이 성능 이점이 거의 또는 전혀 없습니다.
  • 이벤트 큐 값은 스레드 수 값의 절반이어야 합니다.

워크로드에 매우 많은 수의 작은 파일 작업과 과도한 메타데이터 액세스가 포함된 경우 이러한 권장사항을 초과하여 숫자를 늘려 실험해 볼 수 있습니다.

파일 스트라이프 설정

파일 스트리핑은 파일을 블록 또는 스트립으로 나누고 여러 스토리지 타겟에 분산하는 데이터 저장 기술입니다. 파일 스트리핑은 인스턴스를 지원하는 두 개 이상의 스토리지 대상에 대한 동시 읽기 쓰기를 허용하여 성능을 향상시킬 수 있습니다.

Parallelstore 인스턴스를 만들 때 다음 세 가지 파일 스트리핑 설정 중 하나를 지정할 수 있습니다.

  • 최소
  • 균형
  • 최대

이 설정은 Parallelstore 성능에 상당한 영향을 미칠 수 있습니다. 대부분의 워크로드에는 균형 잡힌 설정이 좋습니다. 이는 대부분의 워크로드에 적절한 절충안입니다. 균형 설정으로 성능이 허용되지 않는 경우:

  • 최소 설정은 특히 평균 파일 크기가 256KB 미만인 경우 작은 파일이 많은 워크로드의 성능을 개선할 수 있습니다.

  • 최대 설정은 특히 여러 클라이언트가 동일한 파일에 대한 액세스를 공유하는 경우 일반적으로 8GB를 초과하는 매우 큰 파일이 있는 워크로드의 성능을 개선할 수 있습니다.

고급 조정에는 daos 도구가 파일별 또는 디렉터리별 설정을 제공합니다. 고급 조정을 실험하면 성능 관련 위험이 따르므로 일반적으로 권장하지 않습니다. 자세한 내용은 DAOS의 데이터 중복 및 샤딩 이해하기를 참고하세요.

디렉터리 스트리핑 설정

Parallelstore 인스턴스를 만들 때 다음 세 가지 디렉터리 스트리핑 설정 중 하나를 지정할 수 있습니다.

  • 최소
  • 균형
  • 최대

대부분의 워크로드에는 최대 설정을 사용하는 것이 좋습니다.

대규모 디렉터리의 목록이 많이 포함된 워크로드의 경우 균형 또는 최소 설정을 사용하면 목록 성능이 향상될 수 있습니다. 그러나 다른 작업, 특히 파일 생성의 성능이 저하될 수 있습니다.

멀티 사용자

dfuse 도구를 사용하여 Parallelstore 인스턴스를 마운트하는 경우 --multi-user 플래그를 지정하는 것이 좋습니다. 이 플래그는 DFuse 프로세스를 실행하는 사용자뿐만 아니라 클라이언트의 모든 사용자가 파일 시스템을 사용할 수 있도록 커널에 지시합니다. 그러면 DFuse가 일반적인 멀티 사용자 파일 시스템처럼 표시되고 표준 chown 및 chgrp 호출이 사용 설정됩니다. 모든 파일 시스템 항목은 POSIX 파일 시스템에서 일반적으로 그렇듯이 항목을 만든 사용자가 소유합니다.

--multi-user 플래그를 지정할 때는 다음 줄을 추가하여 /etc/fuse.conf를 루트로 업데이트해야 합니다.

user_allow_other

인스턴스를 멀티 사용자로 마운트하는 것에는 성능에 미치는 영향이 없는 것으로 보입니다.

삭제 코딩 설정

삭제 코딩은 2+1로 설정됩니다. 이 설정은 변경할 수 없습니다. EC2+1을 사용하지 않는 I/O는 거부됩니다.

Google Kubernetes Engine 사이드카 컨테이너 리소스 할당

대부분의 경우 Google Kubernetes Engine 및 Parallelstore의 만족스럽지 못한 성능은 Parallelstore 사이드카 컨테이너에 할당된 CPU 또는 메모리가 충분하지 않기 때문에 발생합니다. 리소스를 적절하게 할당하려면 다음 제안을 고려하세요.

  • 사이드카 컨테이너의 리소스 구성에 강조 표시된 고려사항을 읽어보세요. 리소스 할당을 늘려야 하는 이유와 포드 주석을 사용하여 사이드카 컨테이너 리소스 할당을 구성하는 방법을 알아봅니다.

  • 0 값을 사용하여 Standard 클러스터의 리소스 한도 또는 요청을 사용 중지할 수 있습니다. 예를 들어 gke-parallelstore/cpu-limit: 0 및 gke-parallelstore/memory-limit: 0를 설정하면 사이드카 컨테이너의 CPU 및 메모리 한도가 비워지고 기본 요청이 사용됩니다. 이 설정은 워크로드에 필요한 dfuse 리소스 수를 알 수 없고 노드에서 사용 가능한 모든 리소스를 사용하도록 하려는 경우에 유용합니다. 워크로드 측정항목을 기반으로 dfuse에 필요한 리소스 수를 파악한 후 적절한 한도를 설정할 수 있습니다.

  • Autopilot 클러스터에서는 0 값을 사용하여 사이드카 컨테이너 리소스 한도 및 요청을 설정 해제할 수 없습니다. Autopilot 클러스터에서 사이드카 컨테이너에 더 큰 리소스 한도를 명시적으로 설정하고 Google Cloud 측정항목을 사용하여 리소스 한도를 늘릴지 결정해야 합니다.