Azure Files 성능 문제 해결

참고 항목

이 문서에서 참조하는 CentOS는 Linux 배포이며 EOL(수명 종료)에 도달합니다. 사용 및 계획을 적절하게 고려하세요. 자세한 내용은 CentOS 수명 종료 지침을 참조 하세요.

이 문서에서는 Azure 파일 공유 성능과 관련된 일반적인 문제를 나열하고 잠재적인 원인과 해결 방법을 제공합니다. 이 문제 해결 가이드를 최대한 활용하려면 먼저 Azure Files 성능 이해를 읽는 것이 좋습니다.

적용 대상

파일 공유 유형	SMB	NFS
표준 파일 공유(GPv2), LRS/ZRS
표준 파일 공유(GPv2), GRS/GZRS
프리미엄 파일 공유(FileStorage), LRS/ZRS

일반 성능 문제 해결

먼저 성능 문제가 발생할 수 있는 몇 가지 일반적인 이유를 제외합니다.

이전 운영 체제를 실행하고 있음

클라이언트 VM(가상 머신)이 Windows 8.1, Windows Server 2012 R2, 이전 Linux 배포판 또는 커널을 실행하는 경우 Azure 파일 공유에 액세스할 때 성능 문제가 발생할 수 있습니다. 클라이언트 OS를 업그레이드하거나 아래 수정 사항을 적용합니다.

Windows

Windows 8.1 및 Windows Server 2012 R2에 대한 고려 사항

Windows 8.1 또는 Windows Server 2012 R2를 실행하는 클라이언트는 Azure 파일 공유를 통해 I/O 집약적 워크로드에 액세스할 때 예상보다 많은 대기 시간이 표시될 수 있습니다. KB3114025 핫픽스가 설치되어 있는지 확인합니다. 이 핫픽스는 핸들 만들기 및 닫기 성능을 개선합니다.

다음 스크립트를 실행하여 핫픽스가 설치되었는지 확인할 수 있습니다.

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

핫픽스가 설치된 경우 다음 출력이 표시됩니다.

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

참고 항목

2015년 12월부터 Azure Marketplace의 Windows Server 2012 R2 이미지에는 핫픽스 KB3114025가 기본적으로 설치되어 있습니다.

Linux

CentOS Linux 또는 RHEL에서의 낮은 IOPS

원인

이전 버전의 CentOS Linux 또는 RHEL에서는 1 보다 큰 I/O 깊이가 지원되지 않습니다.

해결 방법

• CentOS Linux 8.6 이상 또는 RHEL 8.6 이상으로 업그레이드합니다.
• Ubuntu로 변경합니다.
• 다른 Linux VM의 경우 커널을 5.0 이상으로 업그레이드합니다.

워크로드가 제한되고 있음

파일 공유에 대한 IOPS(초당 I/O 작업 수), 수신 또는 송신 제한에 도달하면 요청이 제한됩니다. 예를 들어 클라이언트가 기준 IOPS를 초과하는 경우 Azure Files 서비스에 의해 제한됩니다. 제한으로 인해 클라이언트의 성능이 저하될 수 있습니다.

표준 및 프리미엄 파일 공유에 대한 제한을 알아보려면 파일 공유 및 파일 배율 목표를 참조하세요. 워크로드에 따라 표준에서 프리미엄 Azure 파일 공유로 이동하여 제한을 피할 수 있는 경우가 많습니다.

공유 수준 또는 스토리지 계정 수준에서 제한으로 인해 어떻게 긴 대기 시간, 낮은 처리량, 일반적인 성능 문제가 발생할 수 있는지 알아보려면 공유 또는 스토리지 계정이 제한되고 있음을 참조하세요.

긴 대기 시간, 낮은 처리량 또는 낮은 IOPS

원인 1: 공유 또는 스토리지 계정이 제한되고 있음

공유 또는 스토리지 계정이 제한되고 있는지 확인하려면 포털에서 Azure 메트릭에 액세스하여 사용하면 됩니다. 공유가 제한되거나 제한되려는 경우 사용자에게 알리는 경고를 만들 수도 있습니다. 경고를 만들어 Azure Files 문제 해결

Important

표준 스토리지 계정의 경우 스토리지 계정 수준에서 제한이 발생합니다. 프리미엄 파일 공유의 경우 공유 수준에서 제한이 발생합니다.

1. Azure Portal에서 스토리지 계정으로 이동합니다.

2. 왼쪽 창의 모니터링에서 메트릭을 선택합니다.

3. 파일을 스토리지 계정 범위에 대한 메트릭 네임스페이스로 선택합니다.

4. 트랜잭션을 메트릭으로 선택합니다.

5. 응답 형식에 대한 필터를 추가한 다음, 요청이 제한되었는지 여부를 확인합니다.

   표준 파일 공유의 경우 클라이언트 계정 수준에서 요청이 제한되면 다음 응답 형식이 기록됩니다.

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

   프리미엄 파일 공유의 경우 공유 수준에서 요청이 제한되면 다음 응답 형식이 기록됩니다.

   • SuccessWithShareEgressThrottling
   • SuccessWithShareIngressThrottling
   • SuccessWithShareIopsThrottling
   • ClientShareEgressThrottlingError
   • ClientShareIngressThrottlingError
   • ClientShareIopsThrottlingError

   제한된 요청이 Kerberos로 인증된 경우 다음과 같은 인증 프로토콜을 나타내는 접두사를 볼 수 있습니다.

   • KerberosSuccessWithShareEgressThrottling
   • KerberosSuccessWithShareIngressThrottling

   각 응답 형식에 대해 자세히 알아보려면 메트릭 차원을 참조하세요.

   

솔루션

프리미엄 파일 공유를 사용하는 경우 프로비전된 파일 공유 크기를 늘려 IOPS 제한을 늘립니다. 자세히 알아보려면 프리미엄 파일 공유에 대한 프로비전 이해를 참조하세요.

원인 2: 메타데이터 또는 네임스페이스에 워크로드가 과도함

대부분의 요청이 메타데이터 중심이라면(예: createfile, openfile, closefile, queryinfo 또는 querydirectory) 대기 시간이 읽기/쓰기 작업에서보다 늘어날 수 있습니다.

대부분의 요청이 메타데이터 중심인지 확인하려면 앞서 원인 1에 설명한 것처럼 1~4단계를 수행하여 시작합니다. 5단계의 경우 응답 형식에 대한 필터를 추가하는 대신, API 이름에 대한 속성 필터를 추가합니다.

해결 방법

• 메타데이터 작업의 수를 줄이기 위해 애플리케이션을 수정할 수 있는지 여부를 확인합니다.

• 프리미엄 SMB Azure 파일 공유를 사용하는 경우 메타데이터 캐싱을 사용합니다.

• 파일 공유를 동일한 스토리지 계정 내의 여러 파일 공유로 분리합니다.

• 파일 공유에 VHD(가상 하드 디스크)를 추가하고 클라이언트에서 VHD를 탑재하여 데이터에 대한 파일 작업을 수행합니다. 이 방법은 단일 작성자/판독자 시나리오나, 작성자는 여럿이고 판독자는 없는 시나리오에 적합합니다. 파일 시스템은 Azure Files가 아닌 클라이언트의 소유이므로 메타데이터 작업을 로컬로 사용할 수 있습니다. 설치 프로그램은 로컬에서 직접 연결된 스토리지와 비슷한 성능을 제공합니다. 그러나 데이터가 VHD에 있으므로 REST API 또는 Azure Portal을 통해 SMB 탑재 이외의 다른 수단으로 액세스할 수 없습니다.

  1. Azure 파일 공유에 액세스해야 하는 머신에서 스토리지 계정 키를 사용하여 파일 공유를 탑재하고 사용 가능한 네트워크 드라이브(예: Z:)에 매핑합니다.
  2. 디스크 관리로 이동하여 작업 > VHD 만들기를 선택합니다.
  3. 위치를 Azure 파일 공유가 매핑된 네트워크 드라이브로 설정하고, 필요에 따라 가상 하드 디스크 크기를 설정하고, 고정 크기를 선택합니다.
  4. 확인을 선택합니다. VHD 만들기가 완료되면 자동으로 탑재되고 할당되지 않은 새 디스크가 나타납니다.
  5. 알 수 없는 새 디스크를 마우스 오른쪽 단추로 클릭하고 디스크 초기화를 선택합니다.
  6. 할당되지 않은 영역을 마우스 오른쪽 단추로 클릭하고 새 단순 볼륨을 만듭니다.
  7. 디스크 관리에 읽기/쓰기 액세스 권한이 있는 이 VHD를 나타내는 새 드라이브 문자가 표시됩니다(예: E:). 파일 탐색기에서 매핑된 Azure 파일 공유의 네트워크 드라이브에 새 VHD가 표시됩니다(이 예제에서는 Z:). 정리하면, Z:의 표준 Azure 파일 공유 네트워크 매핑과 E: 드라이브의 VHD 매핑이라는 두 개의 드라이브 문자가 있어야 합니다.
  8. Azure 파일 공유 매핑된 드라이브(Z:)에 비해 VHD 매핑된 드라이브(E:)에서 많은 양의 파일 메타데이터 작업 시 훨씬 더 나은 성능을 발휘해야 합니다. 원하는 경우 매핑된 네트워크 드라이브(Z:)의 연결을 끊을 수 있고 탑재된 VHD 드라이브(E:)에는 계속 액세스할 수 있어야 합니다.
  • VHD를 Windows 클라이언트에 탑재하려면 Mount-DiskImage PowerShell cmdlet을 사용해도 됩니다.
  • Linux에 VHD를 탑재하려면 Linux 배포판에 대한 설명서를 참조하세요. 예를 들면 다음과 같습니다.

원인 3: 단일 스레드 애플리케이션

사용 중인 애플리케이션이 단일 스레드인 경우 프로비전된 공유 크기에 따라 이 설정으로 인해 가능한 최대 처리량보다 IOPS 처리량이 상당히 줄어들 수 있습니다.

솔루션

• 스레드 수를 늘려 애플리케이션 병렬 처리를 늘립니다.
• 병렬 처리를 사용할 수 있는 애플리케이션으로 전환합니다. 예를 들어 복사 작업의 경우 Windows 클라이언트 또는 Linux 클라이언트의 병렬 명령에서 AzCopy 또는 RoboCopy를 사용할 수 있습니다.

원인 4: SMB 채널 수가 4개를 초과함

SMB MultiChannel을 사용하는 경우 채널 수가 4개를 초과하면 성능이 저하됩니다. 연결 수가 4개를 초과하는지 확인하려면 PowerShell cmdlet get-SmbClientConfiguration을 사용하여 현재 연결 수 설정을 확인합니다.

솔루션

총 채널이 4개를 초과하지 않도록 SMB에 대한 NIC당 Windows 설정을 지정합니다. 예를 들어 2개의 NIC가 있는 경우 Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2 PowerShell cmdlet을 사용하여 NIC당 최댓값을 2로 설정할 수 있습니다.

원인 5: 미리 읽기 크기가 너무 작음(NFS만 해당)

Linux 커널 버전 5.4부터 Linux NFS 클라이언트는 기본 read_ahead_kb 값인 128kibibytes(KiB)를 사용합니다. 이 작은 값은 대용량 파일의 읽기 처리량을 줄일 수 있습니다.

솔루션

커널 매개 변수 값을 MiB(15메비바이트)로 늘리는 read_ahead_kb 것이 좋습니다. 이 값을 변경하려면 Linux 커널 디바이스 관리자인 udev에 규칙을 추가하여 미리 읽기 크기를 영구적으로 설정합니다. 다음 단계를 수행합니다.

1. 텍스트 편집기에서 다음 텍스트를 입력하고 저장하여 /etc/udev/rules.d/99-nfs.rules 파일을 만듭니다.

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. 콘솔에서 udevadm 명령을 슈퍼 사용자로 실행하고 규칙 파일 및 기타 데이터베이스를 다시 로드하여 udev 규칙을 적용합니다. udev가 새 파일을 인식하도록 하려면 이 명령을 한 번만 실행하면 됩니다.

   sudo udevadm control --reload
   

요청에 대한 대기 시간 매우 김

원인

클라이언트 VM이 파일 공유와는 다른 지역에 있을 수 있습니다. 대기 시간이 긴 다른 이유는 클라이언트나 네트워크에서 초래하는 대기 시간으로 인해 발생할 수 있습니다.

솔루션

• 파일 공유와 동일한 지역에 있는 VM에서 애플리케이션을 실행합니다.
• 스토리지 계정의 경우 Azure Portal에서 Azure Monitor를 통해 트랜잭션 메트릭 SuccessE2ELatency 및 SuccessServerLatency를 검토합니다. SuccessE2ELatency와 SuccessServerLatency 메트릭 값 간의 큰 차이는 네트워크 또는 클라이언트로 인해 발생할 수 있는 대기 시간을 나타냅니다. Azure Files 모니터링 데이터 참조의 트랜잭션 메트릭을 참조하세요.

클라이언트에서 네트워크를 통해 지원되는 최대 처리량을 달성할 수 없음

원인

가능한 한 가지 원인은 표준 파일 공유에 대한 SMB 다중 채널 지원이 부족한 것입니다. 현재 Azure Files는 표준 파일 공유를 위한 단일 채널만 지원하므로 클라이언트 VM에서 서버로의 연결은 하나뿐입니다. 이 단일 연결은 클라이언트 VM의 단일 코어에 고정되므로 VM에서 달성할 수 있는 최대 처리량은 단일 코어에 의해 바인딩됩니다.

해결 방법

• 프리미엄 파일 공유의 경우 SMB 다중 채널을 사용하도록 설정합니다.
• 코어가 더 큰 VM을 가져오면 처리량을 향상시킬 수 있습니다.
• 여러 VM에서 클라이언트 애플리케이션을 실행하면 처리량이 증가합니다.
• 가능한 경우 REST API를 사용합니다.
• NFS Azure 파일 공유의 경우 nconnect를 사용할 수 있습니다. nconnect를 사용하여 NFS Azure 파일 공유 성능 향상을 참조하세요.

Linux VM에 탑재된 Azure 파일 공유의 성능 저하

원인 1: 캐싱

성능 저하의 한 가지 가능한 원인은 캐싱 비활성화입니다. 캐싱은 파일에 반복적으로 액세스하는 경우에 유용할 수 있습니다. 그렇지 않으면 오버헤드가 될 수 있습니다. 캐시를 사용하지 않도록 설정하기 전에 캐시를 사용하고 있는지 확인합니다.

원인 1의 해결 방법

캐싱을 사용하지 않도록 설정했는지 확인하려면 항목을 찾습니다 cache= .

Cache=none 는 캐싱을 사용할 수 없음을 나타냅니다. 기본 탑재 명령을 사용하거나 탑재 명령에 옵션을 명시적으로 추가하여 cache=strict 기본 캐싱 또는 "엄격한" 캐싱 모드를 사용하도록 설정하여 공유를 다시 탑재합니다.

일부 시나리오 serverino 에서는 탑재 옵션을 사용하면 모든 디렉터리 항목에 ls 대해 명령이 실행 stat 될 수 있습니다. 이 동작으로 인해 큰 디렉터리를 나열할 때 성능이 저하됩니다. /etc/fstab 항목에서 탑재 옵션을 확인할 수 있습니다.

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

명령을 실행하고 sudo mount | grep cifs 출력을 확인하여 올바른 옵션이 사용되고 있는지 확인할 수도 있습니다. 다음은 출력 예제입니다.

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

cache=strict 또는 serverino 옵션이 없는 경우 설명서에서 탑재 명령을 실행하여 Azure Files를 분리하고 다시 탑재합니다. 그런 다음 /etc/fstab 항목에 올바른 옵션이 있는지 다시 확인합니다.

원인 2: 제한

제한이 발생하고 요청이 큐로 전송될 수 있습니다. Azure Monitor의 Azure Storage 메트릭을 활용하여 이를 확인할 수 있습니다. 공유가 제한되거나 제한될 경우 사용자에게 알리는 경고를 만들 수도 있습니다. 경고를 만들어 Azure Files 문제 해결

원인 2의 해결 방법

앱이 Azure Files 크기 조정 대상 내에 있는지 확인합니다. 표준 Azure 파일 공유를 사용하는 경우 프리미엄으로 전환하는 것이 좋습니다.

Linux 클라이언트의 처리량이 Windows 클라이언트의 처리량보다 적음

원인

이는 Linux에서 SMB 클라이언트를 구현하는 데 알려진 문제입니다.

해결 방법

• 부하를 여러 VM에 분산합니다.
• 동일한 VM에서 nosharesock 옵션을 사용하여 여러 탑재 위치를 사용하고 이러한 탑재 지점의 부하를 분산합니다.
• Linux에서 nostrictsync 옵션으로 탑재를 시도하여 모든 fsync 호출에서 SMB 강제 플러시를 방지합니다. Azure Files의 경우 이 옵션은 데이터 일관성을 방해하지 않지만 디렉터리 목록(ls -l 명령)에 오래된 파일 메타데이터가 발생할 수 있습니다. stat 명령을 사용하여 파일 메타데이터를 직접 쿼리하면 최신 파일 메타데이터가 반환됩니다.

메타데이터에 대한 긴 대기 시간-광범위한 열기/닫기 작업과 관련된 과도한 워크로드

원인

디렉터리 임대에 대한 지원이 부족합니다.

해결 방법

• 가능하면 짧은 시간 내에 동일한 디렉터리에서 열기/닫기 핸들을 과도하게 사용하지 마세요.
• Linux VM의 경우 actimeo=<sec>를 탑재 옵션으로 지정하여 디렉터리 항목 캐시 제한 시간을 늘립니다. 기본적으로 제한 시간은 1초이므로 30초와 같은 큰 값이 도움이 될 수 있습니다.
• RHEL(CentOS Linux 또는 Red Hat Enterprise Linux) VM의 경우 시스템을 CentOS Linux 8.2 또는 RHEL 8.2로 업그레이드합니다. 다른 Linux 배포판의 경우 커널을 5.0 이상으로 업그레이드합니다.

파일 및 폴더의 느린 열거

원인

이 문제는 클라이언트 머신에서 대규모 디렉터리에 대한 캐시가 충분하지 않을 때 발생할 수 있습니다.

솔루션

이 문제를 해결하려면 클라이언트 컴퓨터에서 DirectoryCacheEntrySizeMax 더 큰 디렉터리 목록을 캐싱할 수 있도록 레지스트리 값을 조정합니다.

• 위치: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
• 값 이름: DirectoryCacheEntrySizeMax
• 값 형식: DWORD

예를 들어 0x100000(으)로 설정하고 성능이 향상하는지 볼 수 있습니다.

Azure Files 공유와 서로 파일을 복사하는 속도가 느림

Azure Files 서비스에 파일을 전송하려고 하면 성능 저하가 발생할 수 있습니다. 최소 I/O 크기에 대한 특정 요구 사항이 없을 경우 최적 성능을 위해 I/O 크기로 1MiB를 사용하는 것이 좋습니다.

Windows

Windows에서 Azure 파일로의 느린 파일 복사 속도

• 쓰기를 사용하여 확장 중인 파일의 최종 크기를 알고 있고 파일의 기록되지 않은 꼬리에 0이 포함된 경우 소프트웨어에 호환성 문제가 없는 경우 모든 쓰기를 확장 쓰기로 만드는 대신 파일 크기를 미리 설정합니다.

• 올바른 복사 방법을 사용합니다.

  • 두 파일 공유 간의 전송에는 AzCopy를 사용합니다.
  • 온-프레미스 컴퓨터와 파일 공유 간에는 Robocopy를 사용합니다.

Linux

Linux에서 Azure Files와 서로 파일을 복사하는 속도 느림

• 올바른 복사 방법을 사용합니다.

  • 두 파일 공유 간의 전송에는 AzCopy를 사용합니다.
  • cp 또는 dd를 병렬로 사용하면 복사 속도가 향상될 수 있습니다. 스레드 수는 사용 사례 및 워크로드에 따라 달라집니다. 다음 예제에서는 6개를 사용합니다.
    • cp 예(cp는 파일 시스템의 기본 블록 크기를 청크 크기로 사용): find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ &.
    • dd 예(이 명령은 명시적으로 청크 크기를 1MiB로 설정): find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M
  • 오픈 소스 타사 도구(예: - GNU Parallel). - Fpart - 파일을 정렬하고 파티션으로 압축합니다. - Fpsync - Fpart 및 복사 도구를 사용하여 여러 인스턴스를 생성하고 src_dir에서 dst_url로 데이터를 마이그레이션합니다. - Multi - GNU coreutils를 기반으로 하는 다중 스레드 cp 및 md5sum입니다.

• 모든 쓰기를 확장 쓰기로 설정하는 대신 파일 크기를 미리 설정하면 파일 크기가 알려진 시나리오에서 복사 속도를 향상시키는 데 도움이 됩니다. 쓰기 확장을 피해야 하는 경우 명령을 사용하여 대상 파일 크기를 truncate --size <size> <file> 설정할 수 있습니다. 그런 다음 명령이 dd if=<source> of=<target> bs=1M conv=notrunc대상 파일의 크기를 반복적으로 업데이트하지 않고도 원본 파일을 복사합니다. 예를 들어 복사하려는 모든 파일에 대해 대상 파일 크기를 설정할 수 있습니다(공유가 /mnt/share 아래에 탑재된 것으로 가정).

  for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done

  그런 다음, 쓰기를 병렬로 확장하지 않고 파일을 복사합니다.

  find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc

과도한 DirectoryOpen/DirectoryClose 호출

원인

DirectoryOpen/DirectoryClose 호출 수가 최상위 API 호출 중 하나이고 클라이언트가 많은 호출을 수행할 할 것으로 예상되지 않는 경우 Azure 클라이언트 VM에 설치된 바이러스 백신 소프트웨어로 인해 문제가 발생할 수 있습니다.

해결 방법

이 문제에 대한 해결 방법은 Windows용 4월 플랫폼 업데이트에서 확인할 수 있습니다.

SMB 다중 채널이 트리거되지 않음

원인

다시 탑재하지 않았는데 최근 SMB 다중 채널 구성 설정에 변경 사항이 있습니다.

솔루션

• Windows SMB 클라이언트 또는 계정 SMB 다중 채널 구성 설정을 변경한 후에는 공유를 탑재 해제하고 60초 동안 기다린 후 공유를 다시 탑재하여 다중 채널을 트리거해야 합니다.
• Windows 클라이언트 OS의 경우 큐 깊이가 높은 IO 부하(QD=8)를 생성합니다. 예를 들어 파일을 복사하여 SMB 다중 채널을 트리거합니다. 서버 OS의 경우 SMB 다중 채널은 QD=1로 트리거되고, 이는 공유에 대한 IO를 시작하는 즉시 발생합니다.

파일 압축을 풀 때 성능 저하

사용된 정확한 압축 방법 및 압축 해제 작업에 따라 압축 풀기 작업은 로컬 디스크보다 Azure 파일 공유에서 더 느리게 수행될 수 있습니다. 이는 압축 해제 도구가 압축된 보관의 압축 해제를 수행하는 과정에서 여러 메타데이터 작업을 수행하기 때문인 경우가 많습니다. 최상의 성능을 위해 압축된 보관을 Azure 파일 공유에서 로컬 디스크로 복사하고 압축을 푼 다음 Robocopy(또는 AzCopy)와 같은 복사 도구를 사용하여 Azure 파일 공유로 다시 복사하는 것이 좋습니다. Robocopy와 같은 복사 도구를 사용하면 여러 스레드를 통해 병렬로 데이터를 복사함으로써 로컬 디스크와 관련된 Azure Files의 메타데이터 작업 성능 저하를 보완할 수 있습니다.

파일 공유에서 호스트되는 웹 사이트의 대기 시간이 김

원인

파일 공유에 대한 파일 변경 알림 수가 많으면 대기 시간이 발생할 수 있습니다. 이는 일반적으로 심층 중첩 디렉터리 구조를 가진 파일 공유에서 호스트되는 웹 사이트에서 발생합니다. 일반적인 시나리오는 IIS에서 호스트되는 웹 애플리케이션으로, 기본 구성의 각 디렉터리에 대해 파일 변경 알림이 설정됩니다. 클라이언트에서 등록된 공유에 대한 각 변경 내용(ReadDirectoryChangesW)은 파일 서비스에서 클라이언트로 변경 알림을 푸시하며 시스템 리소스를 사용하고 변경 횟수에 따라 문제가 증가됩니다. 이로 인해 공유 제한이 발생할 수 있으므로 클라이언트 쪽 대기 시간이 더 길어질 수 있습니다.

이를 확인하려면 포털에서 Azure 메트릭을 사용하면 됩니다.

1. Azure Portal에서 스토리지 계정으로 이동합니다.
2. 왼쪽 메뉴의 모니터링 아래에서 메트릭을 선택합니다.
3. 파일을 스토리지 계정 범위에 대한 메트릭 네임스페이스로 선택합니다.
4. 트랜잭션을 메트릭으로 선택합니다.
5. ResponseType에 대한 필터를 추가하고 요청에 응답 코드 SuccessWithThrottling (SMB 또는 NFS용) 또는 ClientThrottlingError (REST용)이 있는지 확인합니다.

솔루션

• 파일 변경 알림이 사용되지 않으면 파일 변경 알림(기본 설정)을 사용하지 않도록 설정합니다.

  • FCNMode를 업데이트하여 파일 변경 알림을 사용하지 않도록 설정합니다.
  • 레지스트리에서 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds를 설정하고 W3WP 프로세스를 다시 시작하여 IIS 작업자 프로세스(W3WP) 폴링 간격을 0으로 업데이트합니다. 이 설정에 대한 자세한 내용은 IIS의 여러 부분에서 사용되는 일반적인 레지스트리 키를 참조하세요.

• 볼륨을 줄이기 위해 파일 변경 알림 폴링 간격의 빈도를 늘립니다.

  요구 사항에 따라 W3WP 작업자 프로세스 폴링 간격을 더 높은 값(예: 10분 또는 30분)으로 업데이트합니다. 레지스트리에서 설정하고 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds W3WP 프로세스를 다시 시작합니다.

• 웹 사이트의 매핑된 실제 디렉터리에 중첩된 디렉터리 구조가 있는 경우 파일 변경 알림의 범위를 제한하여 알림 볼륨을 줄일 수 있습니다. 기본적으로 IIS는 가상 디렉터리가 매핑되는 실제 디렉터리의 Web.config 파일과 해당 물리적 디렉터리의 모든 자식 디렉터리의 구성을 사용합니다. 자식 디렉터리에서 Web.config 파일을 사용하지 않으려면 가상 디렉터리의 특성을 지정 false allowSubDirConfig 합니다. 자세한 내용은 여기에서 찾을 수 있습니다.

  Web.Config에서 IIS 가상 디렉터리 allowSubDirConfig 설정을 설정하여 false 매핑된 물리적 자식 디렉터리를 범위에서 제외합니다.

참고 항목

• Azure 파일 문제 해결
• 경고를 만들어 Azure Files 문제 해결
• Azure Files 성능 이해
• Microsoft Azure의 경고 개요
• Azure Files FAQ

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.