성능 병목 상태 디버깅
16개 이상의 많은 VM에서 HPC(고성능 컴퓨팅) 애플리케이션을 실행하는 경우, 적은 수의 VM에서 작은 문제부터 실행하는 것이 가장 좋습니다. 해당 테스트는 HPC 애플리케이션이 예상대로 실행되는지 확인합니다.
단지 HPC 병렬 애플리케이션을 실행한다는 이유로 더 많은 VM에서(더 많은 병렬 프로세스를 사용) 실행할수록 실제 경과 시간이 계속 줄어들 것이라고 가정하면 안 됩니다. 사실, 밀결합된 HPC 애플리케이션 중 상당수는 다른 VM에서 실행하려고 시도할 때 실제 경과 시간이 더 길어질 수 있습니다.
실제 경과 시간이 더 길어지는 여러 가지 이유가 있습니다. 예시:
병렬 알고리즘을 비효율적으로 구현할 수도 있습니다.
문제 크기(즉, 모델 크기 또는 자유도 수(NDOF))가 충분히 크지 않습니다. 애플리케이션이 더 많은 병렬 프로세스에서 실행될수록 각 프로세스에서 수행하는 계산의 양이 너무 작아집니다. 결과적으로 병렬 프로세스 간의 통신 시간이 전체 실행 시간을 차지하게 됩니다. 통신 시간이 늘어나면 전체적인 실제 경과 시간도 늘어납니다.
관심 있는 문제 크기를 실행하여 HPC 애플리케이션이 얼마나 잘 스케일링되는지 파악하는 것이 중요합니다. 그런 다음, 성능 및 비용 관점에서 허용 가능한 병렬 효율성을 결정할 수 있습니다.
다음은 병렬 프로세스를 추가할 때 병렬 애플리케이션 성능이 얼마나 향상되는지 측정하는 병렬 속도 향상 계산 수식입니다.
$${\text{Parallel speed-up}} = {\dfrac{\text{Wall time (1 process)}}{\text{Wall time (n processes)}}}$$
다음은 병렬 애플리케이션 성능을 개선하기 위해 프로세스를 추가할 때 계산 리소스가 얼마나 효율적으로 사용되는지 보여주는 병렬 효율성 수식입니다.
$${\text{Parallel efficiency}} = {\dfrac{\text{Parallel speed-up}}{\text{N processes}}}$$
밀결합된 HPC 애플리케이션의 병렬 스케일링 성능을 잘 모르는 경우에는 스케일링 연구를 실행합니다. 즉, 1개, 2개, 4개, 8개, 16개 등의 병렬 프로세스에서 애플리케이션을 실행합니다. 병렬 속도 향상 및 병렬 효율성을 계산하고 이러한 결과를 기준으로 사용할 병렬 프로세스 수를 결정합니다.
작업을 실행하기 전에 Azure Linux 에이전트처럼 병렬 스케일링에 영향을 미칠 수 있는 불필요한 서비스를 사용하지 않도록 설정하는 것이 좋습니다. 작업이 완료된 후 서비스를 다시 사용하도록 설정할 수 있습니다. 사용 가능한 모든 코어를 사용하고 많은 수의 VM으로 확장하는 경우에는 특히 그렇습니다.
Azure Linux 에이전트를 중지하려면 다음 명령을 사용합니다.
sudo system stop waagent.service
성능 검사
다음 정보는 잠재적 성능 문제를 식별하는 데 도움이 되는 몇 가지 기본 검사를 제공합니다.
각 VM에서 실행되는 프로세스 및 스레드 수가 올바른지 확인
각 VM(가상 머신)에서 올바른 수의 프로세스와 스레드를 사용하고 있는지 확인하는 쉬운 방법은 uptime과 같은 도구를 사용하여 각 VM의 시스템 부하 평균을 구하는 것입니다. 이 숫자가 각 VM의 총 예상 프로세스 및 스레드 수와 거의 같아야 합니다. 기록된 부하 평균이 예상되는 총 프로세스 및 스레드 수보다 낮거나 높으면 문제를 해결해야 합니다.
MPI(메시지 전달 인터페이스) 인수와 병렬 스레드 수를 지정하는 방법을 주의 깊게 확인해야 합니다. 예: 애플리케이션의 명령줄 인수 또는 OMP_NUM_THREADS과(와) 같은 환경 변수 값을 확인해야 합니다.
프로세스 및 스레드가 모든 NUMA 노드 도메인 간에 균등하게 배포되는지 확인
top 또는 htop 도구를 사용하는 경우 명령줄 매개 변수로 2를 지정하여 NUMA(Nonuniform Memory Access) 노드 도메인 보기를 선택할 수 있습니다. (예를 들어 HB120_v2에서는 이 보기를 사용하여 NUMA 노드 도메인 30개가 표시됩니다.)
사용자 사용률 백분율이 모든 NUMA 도메인 간에 균등하게 분산되어야 합니다. 그렇지 않은 경우 MPI 명령줄 인수와 환경 변수를 확인합니다.
다음 이미지는 NUMA 보기에서 Linux top 도구의 출력을 보여줍니다. 이 경우 각 NUMA의 활용도는 50%입니다.
프로세스 및 스레드의 실행 상태 확인
프로세스 및 스레드의 실행 상태를 확인하려면 top을 사용해야 합니다. 모든 프로세스 및 스레드가 실행 중(R) 상태인 것이 가장 좋습니다.
프로세스 및 스레드의 일부 또는 전체가 무중단 일시 중지(D) 또는 일시 중지(S) 상태인 경우 상황을 조사하여 원인을 파악합니다. 애플리케이션의 알고리즘 설계 방식에 따라 프로세스와 스레드가 일시 중지 상태인 것이 정상이자 예상되는 동작일 수 있습니다. 그러나 사용 중인 스토리지 솔루션으로 인해 I/O 성능이 부족한 경우처럼 리소스 제약 조건을 나타낼 수도 있습니다.
다음 수식은 병렬 애플리케이션이 시스템 리소스를 대기 중일 때(예: I/O) 어느 범위까지 얼마나 효율적으로 실행되는지 보여줍니다.
$${\text{Application wait time}} = {\text{Wall time}} - \left( {\dfrac{\text{Total CPU time for all parallel processes}}{\text{Number of parallel processes}}} \right)$$
애플리케이션이 I/O 바인딩되어 있는지 확인
무중단 일시 중지(D) 또는 일시 중지(S) 상태에서 상당한 시간을 소비하는 프로세스 및 스레드는 I/O 병목 현상을 조사해야 함을 의미할 수 있습니다. 일부 HPC 애플리케이션은 출력의 일부로 성능 프로파일링을 제공합니다. 이러한 프로필은 I/O를 수행하는 데 소요된 시간의 백분율과 읽기/쓰기 I/O 속도를 보여줍니다. I/O 속도는 I/O 병목 상태를 의미할 수도 있습니다.
I/O가 진행하는 위치를 잘 모를 경우 iostat와 같은 도구가 유용할 수 있습니다. I/O 문제가 있는지 확인하려면 현재 사용 중인 것보다 속도가 빠른 스토리지 솔루션으로 변경합니다. 그런 다음, HPC 애플리케이션을 다시 실행합니다. 예를 들어 고속 로컬 NVMe SSD 또는 RAM 디스크를 사용할 수 있습니다.
이렇게 변경한 후에는 다음 질문을 자문해 보세요. I/O 시간에 개선 사항이 있나요? 총 실제 경과 시간이 향상되었나요? 그렇다면, 얼마나 그런가요?
애플리케이션이 네트워크에 바인딩되는지 확인
애플리케이션에서 프로세스 통신(일반적으로 MPI 통신)을 수행하는 데 소요되는 전체 실제 경과 시간의 백분율을 확인합니다.
애플리케이션이 네트워크에 바인딩되는 경우 HPC 애플리케이션을 실행할 때 InfiniBand 네트워크를 사용하는지 확인합니다. 하이브리드 병렬 버전을 사용할 수 있는 경우 네트워크 통신 시간이 단축되는지 확인합니다.
소스 코드에 액세스할 수 있는 경우 통신을 구현하는 보다 효율적인 방법이 있는지 확인합니다. 예: 지점 간 대신 집합적 연산을 사용하거나 동기 대신 비동기 통신을 사용해 볼 수 있습니다.