Azure Files のパフォーマンスに関する問題のトラブルシューティング

この記事では、Azure ファイル共有のパフォーマンスに関連する一般的な問題を一覧形式で提示し、考えられる原因と回避策を提供します。 このトラブルシューティング ガイドから最大限の価値を得るには、まず「Azure Files のパフォーマンスについて」を読むことをお勧めします。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

全般的なパフォーマンスのトラブルシューティング

まず、パフォーマンスの問題を引き起こす可能性がある一般的な原因のいくつかを除外します。

古いオペレーティング システムを実行している

クライアント仮想マシン (VM) で Windows 8.1 または Windows Server 2012 R2、あるいは古い Linux ディストリビューションまたはカーネルを実行している場合、Azure ファイル共有にアクセスするとパフォーマンスの問題が発生することがあります。 クライアント OS をアップグレードするか、以下の修正プログラムを適用してください。

ワークロードがスロットルされている

1 秒あたりの操作回数 (IOPS)、ファイル共有のイングレスまたはエグレスの制限に達すると、要求がスロットルされます。 たとえば、クライアントがベースライン IOPS を上回ると、Azure Files サービスによってスロットルされます。 スロットリングにより、クライアントのパフォーマンスが低下する可能性があります。

Standard および Premium ファイル共有の制限については、「ファイル共有とファイルのスケール ターゲット」を参照してください。 ワークロードによっては、多くの場合、Standard の Azure ファイル共有から Premium に移行するとスロットリングを回避できます。

共有レベルまたはストレージ アカウント レベルでのスロットリングによって、待機時間が長くなったり、スループットが低下したり、全般的なパフォーマンスの問題が発生したりする可能性がある件の詳細については、「共有またはストレージ アカウントがスロットルされている」を参照してください。

高待機時間、低スループット、または低 IOPS

原因 1: 共有またはストレージ アカウントがスロットルされている

共有またはストレージ アカウントがスロットルされているかどうかを確認するには、ポータルで Azure メトリックスにアクセスして使用します。 共有がスロットルされている (または、スロットルされようとしている) かどうかを通知するアラートも作成できます。 「アラートを作成して Azure Files のトラブルシューティングを行う」を参照してください。

1. Azure portal で、ストレージ アカウントに移動します。

2. 左側のペインの [監視] で [メトリック] を選択します。

3. お使いのストレージ アカウント スコープのメトリック名前空間として、 [ファイル] を選択します。

4. メトリックとして [トランザクション] を選択します。

5. [応答の種類] に対してフィルターを追加し、その後、スロットルされた要求があるかどうかを確認します。

   標準ファイル共有の場合、要求がクライアント アカウント レベルで調整されると、次の応答の種類がログに記録されます。

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

   Premium ファイル共有では、共有レベルで要求がスロットルされると、次の応答の種類がログに記録されます。

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

   調整された要求が Kerberos で認証された場合、次のような認証プロトコルを示すプレフィックスが表示されることがあります。

   • KerberosSuccessWithShareEgressThrottling
   • KerberosSuccessWithShareIngressThrottling

   各応答の種類の詳細については、「メトリック ディメンション」を参照してください。

   

解決策

Premium ファイル共有を使用している場合は、プロビジョニングされたファイル共有のサイズを増やして IOPS の上限を上げます。 詳細については、「Premium ファイル共有のプロビジョニングについて」をご覧ください。

原因 2:メタデータまたは名前空間の過大なワークロード

要求の大部分がメタデータ中心の場合 (createfile、openfile、closefile、queryinfo、querydirectory など)、読み取り/書き込み操作よりも待機時間が長くなります。

要求の大半がメタデータ中心であるかどうかを確認するには、前述の「原因 1」で説明した手順 1-4 に従ってください。 手順 5 では、 [応答の種類] のフィルターを追加する代わりに、 [API 名] にプロパティ フィルターを追加します。

対処方法

• メタデータ操作の数を減らすようにアプリケーションを変更できるかどうかを確認します。

• Premium SMB Azure ファイル共有を使用している場合は、 metadata キャッシュを使用します。

• ファイル共有を同じストレージ アカウント内の複数のファイル共有に分割します。

• ファイル共有に仮想ハード ディスク (VHD) を追加し、クライアントから VHD をマウントして、データに対するファイル操作を実行します。 このアプローチは、単一のライター/リーダーのシナリオ、またはリーダーが複数でライターが存在しないシナリオで機能します。 ファイル システムは Azure Files ではなくクライアントが所有するため、これによってメタデータ操作をローカルにすることができます。 セットアップすると、ローカルに直接アタッチされているストレージの場合と同様のパフォーマンスが実現されます。 ただし、データは VHD 内にあるため、SMB マウント以外の方法、REST API や Azure portal を使ってアクセスすることはできません。

  1. Azure ファイル共有にアクセスする必要があるマシンから、ストレージ アカウント キーを使用してファイル共有をマウントし、利用可能なネットワーク ドライブ (Z: など) にマップします。
  2. [ディスクの管理] に移動し、[アクション]>[VHD の作成] を選択します。
  3. [場所] を Azure ファイル共有のマップ先のネットワーク ドライブに設定し、[仮想ハード ディスク サイズ] を必要に応じて設定し、[固定サイズ] を選択します。
  4. [OK] を選択します。 VHD の作成が完了すると、自動的にマウントされ、新しい未割り当てディスクが表示されます。
  5. 新しい不明ディスクを右クリックし、[ディスクの初期化] を選択します。
  6. 未割り当て領域を右クリックして、新しいシンプル ボリュームを作成します。
  7. [ディスク管理] に、読み取り/書き込みアクセス権を持つこの VHD を表す新しいドライブ文字 (例: E:) が表示されます。 エクスプローラーで、マップされた Azure ファイル共有のネットワーク ドライブ (この例では Z:) に新しい VHD が表示されます。 つまり、2 つのドライブ文字が存在しているはずで、標準の Azure ファイル共有ネットワーク マッピングは Z:、VHD マッピングは E: ドライブです。
  8. VHD マップ ドライブ (E:) 上のファイルに対する大量メタデータ操作では、Azure ファイル共有マップ ドライブ (Z:) よりはるかにパフォーマンスが向上するはずです。 必要であれば、マップされたネットワーク ドライブ (Z:) を切断しても、マウントされた VHD ドライブ (E:) にはアクセスできる必要があります。
  • Windows クライアントに VHD をマウントするには、Mount-DiskImage PowerShell コマンドレットを使用することもできます。
  • Linux に VHD をマウントするには、Linux ディストリビューションのドキュメントを参照してください。 こちらでサンプルをご覧ください。

原因 3:シングル スレッド アプリケーション

使用しているアプリケーションがシングルスレッドで処理されている場合、これをセットアップすると、プロビジョニングされた共有サイズに応じて、最大限のスループットよりも IOPS スループットが大幅に低下する結果になる可能性があります。

解決策

• スレッドの数を増やすことで、アプリケーションの並列処理を増やします。
• 並列処理が可能なアプリケーションに切り替えます。 たとえば、コピー操作では、Windows クライアントから AzCopy または RoboCopy を使用でき、Linux クライアントから parallel コマンドを使用できます。

原因 4: SMB チャンネル数が 4 を超える

SMB MultiChannel の使用時、チャンネル数が 4 を超える場合、パフォーマンスが低下します。 接続数が 4 を超えるかどうかを判断するには、PowerShell コマンドレット get-SmbClientConfiguration を使用し、現在の接続数設定を表示します。

解決策

チャンネルの合計が 4 を超えないよう、SMB の NIC 設定ごとに Windows を設定します。 たとえば、NIC が 2 つの場合、PowerShell コマンドレット Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2 を使用し、NIC あたりの最大を 2 に設定できます。

原因 5: 先読みサイズが小さすぎます (NFS のみ)

Linux カーネル バージョン 5.4 以降、Linux NFS クライアントは既定の read_ahead_kb 値 128 kibibytes (KiB) を使用します。 このような小さな値を使うと、大きなファイルでは読み取りスループットの量が減る場合があります。

解決策

read_ahead_kbカーネル パラメーターの値を 15 メビバイト (MiB) に増やすことをお勧めします。 この値を変更するには、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 が新しいファイルを認識できるようにするには、このコマンドを 1 回だけ実行する必要があります。

   sudo udevadm control --reload
   

非常に長い要求の待機時間

原因

クライアント VM がファイル共有とは異なるリージョンに置かれている可能性があります。 待機時間が長いその他の理由として、クライアントまたはネットワークに起因する待機時間が原因として考えられます。

解決策

• ファイル共有と同じリージョンに配置されている VM からアプリケーションを実行します。
• ストレージ アカウントについては、Azure portal で Azure Monitor 介したトランザクション メトリック SuccessE2ELatency および SuccessServerLatency を確認してください。 SuccessE2ELatency と SuccessServerLatency のメトリック値が大きく異なる場合は、ネットワークやクライアントに起因する待機時間が原因である可能性があります。 「Azure Files 監視データのリファレンス」の「トランザクション メトリック」を参照してください。

ネットワークでサポートされている最大スループットを達成できないクライアント

原因

考えられる原因の 1 つは、Standard ファイル共有で SMB マルチチャネルがサポートされていないことです。 Azure Files では現在、Standard ファイル共有ではシングル チャネルのみがサポートされているため、クライアント VM からサーバーへの接続は 1 つしかありません。 この単一の接続は、クライアント VM の単一のコアに固定されているため、VM から達成可能な最大スループットは単一コアにバインドされます。

回避策

• Premium ファイル共有の場合、有効な SMB マルチチャネル。
• より大きなコアの VM を取得すれば、スループットの向上に役立つ可能性があります。
• 複数の VM からクライアント アプリケーションを実行すると、スループットが向上します。
• 可能な場合は、REST API を使用します。
• NFS Azure ファイル共有では、nconnect を使用できます。 「nconnect を使用して NFS Azure ファイル共有のパフォーマンスを向上させる」を参照してください。

Linux VM にマウントされている Azure ファイル共有のパフォーマンスが低下している

原因 1:キャッシュ

パフォーマンスの低下の原因の 1 つとして考えられるのは、キャッシュの無効化です。 キャッシュは、ファイルに繰り返しアクセスする場合に便利です。 それ以外の場合は、オーバーヘッドが発生する可能性があります。 キャッシュを無効にする前に、キャッシュを使用しているかどうかを確認します。

原因 1 の解決策

キャッシュが無効になっているかどうかを確認するには、 cache= エントリを探します。

Cache=none は、キャッシュが無効になっていることを示します。 既定の mount コマンドを使用するか、mount コマンドに cache=strict オプションを明示的に追加して、既定のキャッシュ モードまたは "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オプションが存在しない場合は、documentationから mount コマンドを実行して、Azure Files のマウントを解除し、再度マウントします。 その後、 /etc/fstab エントリに正しいオプションが指定されていることを再確認します。

原因 2:Throttling

調整が発生し、要求がキューに送信されている可能性があります。 Azure Monitor の Azure Storage メトリックを利用して、これを確認することができます。 また、共有が調整されているか、調整が行われようとしているかどうかを通知するアラートを作成することもできます。 「アラートを作成して Azure Files のトラブルシューティングを行う」を参照してください。

原因 2 の解決策

アプリが Azure Files のスケール ターゲット内にあることを確認します。 Standard の Azure ファイル共有を使用している場合は、Premium に切り替えることを検討してください。

Linux クライアントでのスループットは、Windows クライアントよりも低下します。

原因

これは、Linux での SMB クライアントの実装に関する既知の問題です。

回避策

• 複数の VM 間で負荷を分散します。
• 同じ VM 上で、nosharesock オプションで複数のマウント ポイントを使用し、これらのマウント ポイント間で負荷を分散します。
• Linux では、すべての fsync 呼び出しで SMB フラッシュが強制されないようにするために、nostrictsync オプションを使用したマウントを試してみてください。 Azure Files の場合、このオプションはデータの一貫性に干渉することはありませんが、ディレクトリのリストに古いファイルのメタデータが表示される可能性があります (ls -l コマンド)。 stat コマンドを使用してファイル メタデータのクエリを直接実行すると、最新のファイルのメタデータが返されます。

多大な開く/閉じる操作に関連するメタデータの過大なワークロードの長い待機時間

原因

ディレクトリ リースのサポートの欠如。

回避策

• 可能であれば、同じディレクトリで短時間に過剰に開く/閉じる操作を使用することを避けます。
• Linux VM では、マウント オプションとして actimeo=<sec> を指定することで、ディレクトリ エントリ キャッシュのタイムアウトを増やします。 既定ではタイムアウトが 1 秒であるため、30 秒などの大きな値が役立つ場合があります。
• CentOS Linux または Red Hat Enterprise Linux (RHEL) VM の場合は、システムを CentOS Linux 8.2 または RHEL 8.2 にアップグレードします。 その他の Linux ディストリビューションの場合は、カーネルを 5.0 以上にアップグレードします。

ファイルとフォルダーの列挙が遅い

原因

この問題は、大きなディレクトリに対応するための十分なキャッシュがクライアント コンピューターにない場合に発生することがあります。

解決策

この問題を解決するには、 DirectoryCacheEntrySizeMax レジストリ値を調整して、クライアント コンピューターで大きなディレクトリ一覧をキャッシュできるようにします。

• 場所: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
• 値の名前: DirectoryCacheEntrySizeMax
• 値の種類: DWORD

たとえば、これを 0x100000 に設定して、パフォーマンスが向上するかどうかを確認できます。

Azure ファイル共有間でのファイルのコピーが遅い

Azure Files サービスにファイルを転送しようとした場合に、パフォーマンスが低下することがあります。 特定の最小 I/O サイズ要件がない場合は、最適なパフォーマンスを得るために I/O サイズとして 1 MiB を使用することをお勧めします。

DirectoryOpen/DirectoryClose の過剰な呼び出し

原因

DirectoryOpen/DirectoryClose の呼び出し数が上位の API 呼び出しに入っており、そのような多数の呼び出しをクライアントにさせるつもりがない場合、Azure クライアント VM にインストールされているウイルス対策が原因で問題が発生する可能性があります。

回避策

この問題の修正プログラムは Windows の 4 月のプラットフォーム更新プログラムで入手できます。

SMB マルチチャネルはトリガーされていません

原因

再マウントせずに、SMB マルチチャネル構成の設定が最近変更されました。

解決策

• Windows SMB クライアントまたはアカウント SMB マルチチャネル構成の設定が変更されたら、共有のマウントを解除し、60 秒間待機してから、共有を再マウントしてマルチチャネルをトリガーする必要があります。
• Windows クライアント OS の場合は、たとえば、ファイルをコピーして SMB マルチチャネルをトリガーして、キューの深さが大きい IO 負荷 (QD=8 など) を生成します。 サーバー OS の場合は、SMB マルチチャネルが QD = 1 でトリガーされます。つまり、共有への IO を開始した直後に発生します。

ファイルを解凍するときのパフォーマンスが低下する

使用されている正確な圧縮方法と解凍操作によっては、展開操作がローカル ディスクよりも Azure ファイル共有で実行速度が遅くなる場合があります。 これは、多くの場合、圧縮アーカイブの展開を実行する過程で、解凍ツールが多数のメタデータ操作を実行する理由です。 最適なパフォーマンスを得る場合は、圧縮アーカイブを Azure ファイル共有からローカル ディスクにコピーし、そこで解凍してから、Robocopy (または AzCopy) などのコピー ツールを使用して Azure ファイル共有にコピーバックすることをお勧めします。 Robocopy のようなコピー ツールを使用すると、複数のスレッドを使用してデータを並列コピーすることで、ローカル ディスクに対する Azure Files でのメタデータ操作のパフォーマンス低下を補正できます。

ファイル共有でホストされている Web サイトの待機時間が長い

原因

ファイル共有に関するファイル変更通知の数が多くなると、待機時間が長くなる可能性があります。 一般に、この問題は、ディレクトリ構造が深い入れ子になっているファイル共有でホストされている Web サイトで発生します。 一般的なシナリオは、IIS でホストされている Web アプリケーションです。既定の構成では、ファイル変更通知はディレクトリごとにセットアップされます。 クライアントが登録されている共有で変更 (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 プロセスを再起動します。

• Web サイトのマップされた物理ディレクトリに入れ子になったディレクトリ構造がある場合は、ファイル変更通知のスコープを制限して通知量を減らすことができます。 既定では、IIS では、仮想ディレクトリがマップされる物理ディレクトリ内の Web.config ファイルと、その物理ディレクトリ内の任意の子ディレクトリの構成が使用されます。 子ディレクトリで Web.config ファイルを使用しない場合は、仮想ディレクトリのallowSubDirConfig属性にfalseを指定します。 詳細については、こちらをご覧ください。

  Web.Config の IIS 仮想ディレクトリのallowSubDirConfig設定をfalseに設定して、マップされた物理子ディレクトリをスコープから除外します。

関連項目

• Azure Files のトラブルシューティング
• アラートを作成して Azure Files のトラブルシューティングを行う
• Azure Files のパフォーマンスについて
• Microsoft Azure のアラートの概要
• Azure Files に関する FAQ

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。