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

  • [アーティクル]

注:

この記事で参照されている CentOS は Linux ディストリビューションであり、End Of Life (EOL) に到達します。 使用を検討し、それに応じて計画します。 詳細については、「 CentOS End Of Life ガイダンス」を参照してください。

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

適用対象

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

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

まず、パフォーマンスの問題が発生する可能性がある一般的な理由を除外します。

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

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

R2 のWindows 8.1とWindows Server 2012に関する考慮事項

Windows 8.1または R2 Windows Server 2012を実行しているクライアントでは、I/O 集中型ワークロードの Azure ファイル共有にアクセスするときに予想よりも長い待機時間が発生する可能性があります。 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

注:

Azure Marketplace Windows Server 2012 R2 イメージには、2015 年 12 月から修正プログラム KB3114025が既定でインストールされています。

ワークロードの調整中

要求は、1 秒あたりの I/O 操作 (IOPS)、イングレス、またはエグレスの制限に達すると調整されます。 たとえば、クライアントがベースライン IOPS を超えると、Azure Files サービスによって調整されます。 調整すると、クライアントのパフォーマンスが低下する可能性があります。

標準ファイル共有と Premium ファイル共有の制限については、「 ファイル共有とファイル スケール ターゲット」を参照してください。 ワークロードによっては、Standard から Premium Azure ファイル共有に移行することで、調整を回避できることがよくあります。

共有レベルまたはストレージ アカウント レベルでの調整によって待機時間が長く、スループットが低く、一般的なパフォーマンスの問題が発生する方法の詳細については、「 共有またはストレージ アカウントの調整中」を参照してください。

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

原因 1: 共有アカウントまたはストレージ アカウントが調整中

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

重要

大きなファイル共有 (LFS) が有効になっている標準ストレージ アカウントでは、アカウント レベルで調整が行われます。 LFSが有効になっていない Premium ファイル共有と標準ファイル共有の場合、共有レベルで調整が行われます。

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

  2. 左側のウィンドウの [ 監視] で、[ メトリック] を選択します。

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

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

  5. 応答の種類のフィルターを追加し、チェックして、要求が調整されているかどうかを確認します。

    大きなファイル共有が有効になっていない標準ファイル共有の場合、要求が共有レベルで調整された場合、次の応答の種類がログに記録されます。

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

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

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Premium ファイル共有の場合、要求が共有レベルで調整された場合、次の応答の種類がログに記録されます。

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

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

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

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

    'Response type' プロパティ フィルターを示すスクリーンショット。

ソリューション

原因 2: メタデータまたは名前空間の負荷の高いワークロード

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

ほとんどの要求がメタデータ中心であるかどうかを判断するには、前に「原因 1」で説明したように、手順 1 から 4 に従って開始します。 手順 5 では、 Response 型のフィルターを追加する代わりに、 API 名のプロパティ フィルターを追加します。

'API 名' プロパティ フィルターを示すスクリーンショット。

回避策

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

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

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

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

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

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

ソリューション

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

原因 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. コンソールで udev ルールを適用するには、 udevadm コマンドをスーパーユーザーとして実行し、ルール ファイルやその他のデータベースを再読み込みします。 udev で新しいファイルを認識するには、このコマンドを 1 回だけ実行する必要があります。

    sudo udevadm control --reload

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

原因

クライアント VM は、ファイル共有とは異なるリージョンに配置できます。 待機時間が長いその他の理由は、クライアントまたはネットワークによって発生する待機時間が原因である可能性があります。

ソリューション

  • ファイル共有と同じリージョンにある VM からアプリケーションを実行します。
  • ストレージ アカウントについては、Azure portalの Azure Monitor を使用してトランザクション メトリック SuccessE2ELatency と SuccessServerLatency を確認します。 SuccessE2ELatency と SuccessServerLatency メトリックの値の大きな違いは、ネットワークまたはクライアントによって発生する可能性のある待機時間を示しています。 「Azure Files監視データ リファレンス」の「トランザクション メトリック」を参照してください。

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

原因

考えられる原因の 1 つは、標準ファイル共有に対する SMB マルチチャネル サポートの欠如です。 現在、Azure Filesでは標準ファイル共有に対して 1 つのチャネルのみがサポートされているため、クライアント VM からサーバーへの接続は 1 つだけです。 この 1 つの接続はクライアント VM 上の 1 つのコアにペギングされるため、VM から達成できる最大スループットは 1 つのコアによってバインドされます。

回避策

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)

または オプションが存在しない場合は、ドキュメントの mount コマンドを実行して、Azure Filesマウントを解除してマウントし直します。serverinocache=strict 次に、 /etc/fstab エントリに正しいオプションがあることを再確認します。

原因 2: 調整

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

原因 2 の解決策

アプリがAzure Filesスケール ターゲット内にあることを確認します。 標準の 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 を使用することをお勧めします。

Windows のAzure Filesとの間でのファイルのコピーが遅い

  • 書き込みで拡張するファイルの最終的なサイズがわかっていて、ファイルの書き込まれていない末尾にゼロが含まれている場合にソフトウェアに互換性の問題がない場合は、書き込みごとに拡張書き込みを行うのではなく、事前にファイル サイズを設定します。

  • 適切なコピー メソッドを使用します。

    • 2 つのファイル共有間の任意の転送には AzCopy を使用します。
    • オンプレミス コンピューター上のファイル共有間で Robocopy を使用します。

過剰な DirectoryOpen/DirectoryClose 呼び出し

原因

DirectoryOpen/DirectoryClose 呼び出しの数が上位の API 呼び出しの中にあり、クライアントがその多くの呼び出しを行うとは思わない場合は、Azure クライアント VM にインストールされているウイルス対策ソフトウェアによって問題が発生する可能性があります。

回避策

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

SMB マルチチャネルがトリガーされていない

原因

再マウントなしの SMB マルチチャネル構成設定に対する最近の変更。

ソリューション

  • Windows SMB クライアントまたはアカウントの SMB マルチチャネル構成設定に変更が加えられたら、共有のマウントを解除し、60 秒間待ってから、共有を再マウントしてマルチチャネルをトリガーする必要があります。
  • Windows クライアント OS の場合、キューの深さが高い IO 負荷を生成します (たとえば、ファイルをコピーして SMB マルチチャネルをトリガーするなど)。 サーバー 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 の場合) の要求があるかどうかを確認します。

ソリューション

  • ファイル変更通知が使用されていない場合は、ファイル変更通知を無効にします (推奨)。

  • ファイル変更通知ポーリング間隔の頻度を増やして、ボリュームを減らします。

    要件に基づいて、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 コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。