このトピックでは、SMB プロトコルまたは NFS プロトコルを使用する File Storage NAS(NAS)ファイルシステムのパフォーマンスに関するよくある質問(FAQ)に回答します。
ファイルシステムのパフォーマンスとファイルシステムのストレージ容量の関係は?
汎用型 NAS ファイルシステム
ファイルシステムの読み取り/書き込みパフォーマンス(最大スループット)は、ストレージ容量に比例します。容量が大きいほどスループットが高くなります。詳細については、「汎用型 NAS ファイルシステム」をご参照ください。
超高速型 NAS ファイルシステム
ファイルシステムの読み取り/書き込みパフォーマンスは、ストレージ容量の増加に伴って段階的に向上します。詳細については、「超高速型 NAS ファイルシステム」をご参照ください。
ファイルシステムのパフォーマンスとディレクトリサイズの関係は?
ファイルシステム内のディレクトリの走査は、以下の条件下では遅くなる可能性があります。
ディレクトリが変更されている。たとえば、ディレクトリ内のファイルが作成、削除、または名前変更されている場合です。これにより、頻繁なキャッシュの無効化が発生するため、応答が遅くなります。
ディレクトリのデータサイズが大きすぎる。これにより、キャッシュ エビクションが発生するため、応答が遅くなります。
解決策:
1 つのディレクトリに保存するファイルの数を制限します。1 つのディレクトリには 10,000 個未満のファイルを保存することをお勧めします。
ディレクトリを走査している間は、ディレクトリを頻繁に変更しないようにしてください。
ディレクトリに 10,000 個を超えるファイルが含まれていて、頻繁に変更されない場合は、NFSv3 プロトコルを使用してファイルシステムをマウントし、`nordirplus` パラメーターを指定することで走査を高速化できます。この方法を実装する前に、その有効性を検証することをお勧めします。
マウントパラメーターは NAS ファイルシステムのパフォーマンスにどのような影響を与えますか?
マウントパラメーターは、NAS ファイルシステムのパフォーマンスに大きく影響します。以下は、特定のマウントパラメーターの影響について説明したリストです。
rsize と wsize:
影響: これら 2 つのパラメーターは、クライアントとサーバー間でデータを交換するためのブロックサイズを定義します。ブロックサイズを大きくすると、ネットワークリクエストの数を減らすことができ、特に大きなファイルを扱う場合にスループットが向上します。
推奨値: 1048576(1 MB)。可能な限り最大値を使用することをお勧めします。ブロックサイズが小さいと、ネットワークオーバーヘッドが増加し、パフォーマンスが低下する可能性があります。
hard:
影響: このオプションが有効になっている場合、File Storage NAS が使用できなくなった場合、クライアントはファイルシステムが回復するまでリクエストを再試行し続けます。これにより、データの整合性と一貫性が確保されます。
推奨事項: このパラメーターを有効にします。このパラメーターはデータ損失を防ぎますが、アプリケーションが一時的に停止する可能性があります。したがって、このパラメーターは、高可用性が求められるシナリオに適しています。
timeo:
影響: このパラメーターは、リクエストを再試行する前にクライアントが応答を待機する時間を定義します。タイムアウト期間が短いと、再試行が頻繁に発生し、特に不安定なネットワークではパフォーマンスが低下する可能性があります。
推奨値: 600(60 秒)。この値により、ネットワークが回復するのに十分な時間が確保され、再試行の回数が減少します。
retrans:
影響: このパラメーターは、NFS クライアントが失敗したリクエストを再試行する回数を定義します。再試行の回数が多いほど、リクエストの成功率は高くなりますが、待機時間も長くなる可能性があります。
推奨値: 2。この値は、パフォーマンスとデータの信頼性のバランスを取ります。
noresvport:
影響: このオプションが有効になっている場合、ネットワーク障害から回復したときに、新しい TCP ポートを使用してネットワーク接続を確保します。これにより、ネットワークの信頼性が向上します。
推奨事項: 安定したネットワーク接続を確保するために、このパラメーターを有効にします。
データ整合性の脅威があるため、`soft` オプションを使用しないことをお勧めします。`soft` オプションを使用する場合は、関連するリスクを受け入れる必要があります。
マウントオプションをデフォルト以外の値に設定しないでください。読み取り/書き込みバッファーサイズを変更したり、属性キャッシュを無効にしたりすると、パフォーマンスが低下する可能性があります。
ECS インスタンスの帯域幅は NAS ファイルシステムのパフォーマンスをどのように制限しますか?
NAS ファイルシステムの最大スループットは、接続されている ECS インスタンスの内部帯域幅を超えることはできません。内部帯域幅が低い場合、スループットはトラフィックシェーピングによって制限されます。
リクエストの読み取り/書き込みスループットがしきい値を超えるとどうなりますか?
お客様またはアプリケーションからのリクエストの読み取り/書き込みスループットがしきい値を超えると、NAS はリクエストを自動的にスロットルします。これにより、待機時間が長くなります。
汎用型 NAS ファイルシステムの場合、`Truncate` コマンドを実行してスループットしきい値を上げることができます。詳細については、「汎用型 NAS ファイルシステムの読み取り/書き込みスループットしきい値を上げるにはどうすればよいですか? 」をご参照ください。
超高速型 NAS ファイルシステムの場合、スケールアウトしてスループットしきい値を上げることができます。詳細については、「超高速型 NAS ファイルシステムをスケールアウトする」をご参照ください。
汎用型 NAS ファイルシステムと超高速型 NAS ファイルシステムのスループットしきい値の詳細については、「汎用型 NAS ファイルシステムのパフォーマンスメトリック」および「超高速型 NAS ファイルシステムのパフォーマンスメトリック」をご参照ください。
汎用型 NAS ファイルシステムの読み取り/書き込みスループットしきい値を上げるにはどうすればよいですか?
汎用型 NAS ファイルシステムの読み取り/書き込みスループットは、ストレージ容量に比例して増加します。ファイルシステムの読み取り/書き込みスループットと容量使用率の関係の詳細については、「汎用型 NAS ファイルシステムの仕様」をご参照ください。
スパースファイルを書き込むか、`Truncate` コマンドを実行してファイルシステムにファイルを作成することで、ファイルシステムの容量を増やすことができます。これにより、ファイルシステムの読み取り/書き込みスループットが向上します。Alibaba Cloud NAS ファイルシステムでは、スパースファイルまたは生成されたファイルによって実際に占有されているスペースに対して課金されます。詳細については、「汎用型 NAS ファイルシステムの課金」をご参照ください。
たとえば、容量型 NAS ファイルシステムに 1 TiB のファイルを書き込むと、読み取り/書き込みスループットが 150 MB/s 増加します。パフォーマンス NAS ファイルシステムに 1 TiB のファイルを書き込むと、読み取り/書き込みスループットが 600 MB/s 増加します。
Linux
`Truncate` コマンドを実行してファイルシステムにファイルを作成し、読み取り/書き込みスループットを上げることができます。
sudo truncate --size=1TB /mnt/sparse_file.txt上記のコマンドで、/mnt は計算ノード上のファイルシステムのマウントパスです。
Windows
スパースファイルをファイルシステムに書き込んで、読み取り/書き込みスループットを上げることができます。
fsutil file createnew Z:\sparse_file.txt 1099511627776上記のコマンドで、Z:\ は計算ノード上のファイルシステムのマウントパスです。
Linux オペレーティングシステムから NAS にアクセスする際のパフォーマンスの低下を解決するにはどうすればよいですか?
解決策 1: `nconnect` パラメーターを設定して、NAS にアクセスする単一 ECS インスタンスのスループットを向上させる
nconnectパラメーターは、Linux クライアントに NFS ファイルシステムをマウントするためのオプションです。このパラメーターを使用すると、クライアントとサーバーの間に複数の TCP 接続を確立してスループットを向上させることができます。テストでは、nconnectパラメーターを使用すると、NAS にアクセスする単一 ECS インスタンスのスループットを 3 ~ 6 倍、最大 3 GB/s まで向上させることができることが示されています。シナリオ
単一の ECS インスタンスで複数の同時 I/O 読み取り/書き込み操作が実行される(16 を超える同時操作)。
前提条件
Linux カーネルバージョンが 5.3 以降であること。
手順
nconnectパラメーターをmountコマンドに追加します。nconnect=4に設定することをお勧めします。以下はコマンドの例です。sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,nconnect=4重要`nconnect` パラメーターは、NAS にアクセスする単一 ECS インスタンスのスループットを向上させますが、NAS ファイルシステムのスループットしきい値は向上させません。単一同時実行、小規模データブロック、または遅延の影響を受けやすいサービスに対して `nconnect` パラメーターを有効にすると、待機時間が長くなります。このようなサービスには `nconnect` パラメーターを有効にしないことをお勧めします。
解決策 2: `sunrpc.tcp_slot_table_entries` を変更して、NAS にアクセスする単一 ECS インスタンスのスループットを向上させる
Linux カーネルの
sunrpcモジュールは、単一の NFS リンク内の通信スロットの数を決定します。Linux のバージョンによって、異なる `sunrpc` 構成が使用されます。スロット構成が高いと、待機時間が長くなる可能性があります。スロット構成が低いと、スループットが不足する可能性があります。高いスループットが必要な場合は、スロット数を 128 に設定することをお勧めします。低い待機時間が必要な場合は、スロット数を 16 以下に設定することをお勧めします。説明sunrpc.tcp_slot_table_entriesパラメーターを設定する効果は、nconnectパラメーターほど大きくありません。Linux カーネル 5.3 以降では、nconnectパラメーターを設定することをお勧めします。シナリオ
単一の ECS インスタンスで複数の同時 I/O 読み取り/書き込み操作が実行される。カーネルバージョンが 3.10 より前である。
手順
詳細については、「同時 NFS リクエストの数を変更する方法」をご参照ください。
NGINX がファイルシステムにログを書き込むのに長い時間がかかるのはなぜですか?
背景:
NGINX ログを指定するには、2 つの命令を使用できます。log_format 命令はログ形式を指定します。access_log 命令は、ログファイルの保存パス、形式名、およびキャッシュサイズを指定します。
問題:
NGINX がファイルシステムにログを書き込むのに時間がかかり、書き込みパフォーマンスが低下します。
原因:
access_log 命令で指定されたログファイルパスに変数が含まれています。NGINX がログを書き込もうとするたびに、宛先ファイルを開いてから閉じます。データの可視性を確保するために、NAS はファイルが閉じられたときにデータを NAS サーバーに書き戻します。これにより、パフォーマンスが大幅に消費されます。
解決策:
解決策 1: access_log 命令の変数を削除し、ログを固定パスに保存します。
解決策 2: open_log_file_cache 命令を使用して、頻繁に使用されるログのファイル記述子をキャッシュします。これにより、変数が含まれるパスへのログ保存のパフォーマンスが向上します。構成の詳細については、open_log_file_cache をご参照ください。
推奨構成:
open_log_file_cache max=1000 inactive=1m valid=3m min_uses=2;
SMB ファイルシステムで I/O 操作が遅延するのはなぜですか?
問題:
マウントポイントを使用して SMB ファイルシステムにアクセスする場合、ファイルシステムで I/O 操作を実行できるようになるまで数分待つ必要があります。
原因:
NFS クライアントがインストールされているが使用されていないために遅延が発生します。
WebClient サービスが有効になっているため、インターネットファイルサーバーが SMB ファイルシステムにログオンできません。
Nfsnpがレジストリ設定項目の値に含まれているため、ファイルシステム内のファイルを開くことができません。
解決策:
SMB ファイルシステムに初めてアクセスする場合は、ping コマンドを使用してマウントポイントのドメイン名に ping を実行し、計算ノードとファイルシステム間のネットワーク接続を確認し、待機時間が正常範囲内であることを確認することをお勧めします。
ping コマンドが失敗した場合は、ネットワーク設定を確認し、ネットワークが接続されていることを確認してください。
待機時間が長い場合は、マウントポイントの IP アドレスに ping を実行します。IP アドレスに ping を実行したときの待機時間が、ドメイン名に ping を実行したときの待機時間よりもはるかに短い場合は、DNS サーバーの構成を確認してください。
NFS クライアントがインストールされているが使用されていない場合は、NFS クライアントをアンインストールすることをお勧めします。
WebClient サービスを無効にします。
次のパスにあるレジストリ設定項目を確認します: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder。レジストリ値に
Nfsnpが含まれている場合は、Nfsnpを削除してインスタンスを再起動します。
Fio ツールを使用して、パフォーマンスメトリックが異常かどうかを確認できます。
fio.exe --name=./iotest1 --direct=1 --rwmixread=0 --rw=write --bs=4K --numjobs=1 --thread --iodepth=128 --runtime=300 --group_reporting --size=5G --verify=md5 --randrepeat=0 --norandommap --refill_buffers --filename=\\<mount point dns>\myshare\testfio1大きなデータブロックを使用して I/O 読み取り/書き込み操作を実行することをお勧めします。小さなデータブロックは、より多くのネットワークリソースを消費します。データブロックサイズを変更できない場合は、BufferedOutputStream クラスを構築して、指定されたバッファーサイズでデータを書き込むことができます。
Windows Server SMB クライアントで I/O 操作が遅延するのはなぜですか?
原因:
デフォルトでは、Windows SMB クライアントでは
large mtuオプションが無効になっています。これにより、これらのクライアントの I/O パフォーマンスが制限されます。解決策:
レジストリを変更することで、
large mtuオプションを有効にすることができます。レジストリキーは、次のパスにあります: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parametersこのパスで、
DWORDデータ型のキーを作成し、DisableLargeMtu という名前を付けます。キーの値を0に設定します。変更を有効にするには、インスタンスを再起動します。
IIS から NAS へのアクセスパフォーマンスを向上させるにはどうすればよいですか?
原因:
インターネットインフォメーションサービス(IIS)が NAS ファイルシステムの共有ディレクトリにあるファイルにアクセスする場合、IIS バックエンドは共有ディレクトリに複数回アクセスする可能性があります。NAS ファイルシステムへのアクセスには、少なくとも 1 つのネットワークインタラクションが必要であり、これはローカルファイルシステムへのアクセスとは異なります。各アクセスリクエストに時間がかかるわけではありませんが、複数のアクセスリクエストが送信された場合、クライアントの応答に時間がかかる可能性があります。
解決策:
SMB リダイレクターコンポーネントを使用してパフォーマンスを最適化します。詳細については、SMB2 Client Redirector Caches Explained をご参照ください。
レジストリキーは、次のパスにあります: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters。次の 3 つの設定項目の値を 600 以上に変更します。
FileInfoCacheLifetime
FileNotFoundCacheLifetime
DirectoryCacheLifetime
説明上記のレジストリ設定項目が存在しない場合は、次の手順を実行します。
ファイルシステムで SMB プロトコルが使用されていることを確認します。
Windows のバージョンで 3 つのレジストリ設定項目がサポートされているかどうかを確認します。Windows のバージョンでレジストリ設定項目がサポートされているが、存在しない場合は、手動で作成する必要があります。詳細については、ファイルサーバーのパフォーマンスチューニング をご参照ください。
IIS がこれらのファイルに頻繁にアクセスする場合は、JS ファイルや CSS ファイルなどの Web 関連ファイルをローカルディスクに保存することをお勧めします。
IIS の読み取り/書き込みパフォーマンスが依然としてビジネス要件を満たせない場合は、チケットを送信 してください。
ls コマンドを実行すると、ファイルシステムが途切れたり応答しなくなったりするのはなぜですか?
症状
ファイルシステムのディレクトリを走査すると、ファイルシステムが途切れたり応答しなくなったりします。これは、ls コマンド、
*または?ワイルドカード文字を含む操作、rm -rfコマンド、または `getdents` システムコールを実行するときに発生する可能性があります。原因
ディレクトリが変更されている。たとえば、ディレクトリ内のファイルが作成、削除、または名前変更されている場合です。これにより、頻繁なキャッシュの無効化が発生するため、応答が遅くなります。
ディレクトリのデータサイズが大きすぎる。これにより、キャッシュ エビクションが発生するため、応答が遅くなります。
解決策
1 つのディレクトリに保存するファイルの数を制限します。1 つのディレクトリには 10,000 個未満のファイルを保存することをお勧めします。
ディレクトリを走査している間は、ディレクトリを頻繁に変更しないようにしてください。
ディレクトリに 10,000 個を超えるファイルが含まれていて、頻繁に変更されない場合は、NFSv3 プロトコルを使用してファイルシステムをマウントし、nordirplus パラメーターを指定することで走査を高速化できます。この方法を実装する前に、その有効性を検証することをお勧めします。詳細については、「マウントパラメーター」をご参照ください。
Linux カーネル 5.4 以降で NFS シーケンシャル読み取りパフォーマンスを向上させるにはどうすればよいですか?
NFS のread_ahead_kb パラメーターは、シーケンシャル読み取り操作中に Linux カーネルによって事前に読み取られる、つまりプリフェッチされるデータのサイズを KB 単位で定義します。
5.4.* より前の Linux カーネルバージョンでは、read_ahead_kb パラメーターの値は、NFS_MAX_READAHEAD と rsize(マウントオプションで指定されたクライアント読み取りサイズ)の積です。Linux カーネルバージョン 5.4.* 以降では、read_ahead_kb パラメーターのデフォルトは 128 KB です。したがって、推奨されるマウントオプションを使用する場合は、read_ahead_kb パラメーターを 15 MB に増やすことをお勧めします。
ファイルシステムがマウントされた後、次のコマンドを実行して read_ahead_kb パラメーターの値をリセットできます。コマンドでは、nas-mount-point をマウントされたファイルシステムのローカルパスに置き換え、read-ahead-kb を事前に読み取るかプリフェッチするデータのサイズ(KB 単位)に置き換えます。
device_number=$(stat -c '%d' nas-mount-point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo read-ahead-kb > /sys/class/bdi/$major:$minor/read_ahead_kb"次のコマンドは、マウントされたファイルシステムのローカルパスとして /mnt を使用して read_ahead_kb パラメーターの値を 15 MB に設定する例を示しています。
device_number=$(stat -c '%d' /mnt)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 15000 > /sys/class/bdi/$major:$minor/read_ahead_kb"SMB 共有への最初の接続が遅いのはなぜですか?
原因:
SMB 共有への最初の接続が遅いのは、通常、Windows クライアントが無効な複数のネットワークプロバイダーを使用しようとしたり、ドメインネームシステム(DNS)の解決の待機時間が発生したりするためです。
解決策:
警告レジストリの変更はリスクの高い操作です。この操作を実行する前に、システムスナップショットを作成する か、レジストリをバックアップしてください。
手順 1: ネットワークプロバイダーの順序を最適化する
Win + R キーを押し、
regeditと入力して、レジストリエディターを開きます。次のパスに移動します。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
右側ペインで、ProviderOrder 値を見つけてダブルクリックします。
[値のデータ] テキストボックスで、
NfsnpエントリとWebClientエントリを見つけて削除します。他のプロバイダー間のコンマは必ず残してください。[OK] をクリックして変更を保存します。
変更を有効にするには、クライアント ECS インスタンスを再起動します。
手順 2: DNS 解決の待機時間のトラブルシューティング
手順 1 を完了した後も問題が解決しない場合は、DNS 解決が遅いことが原因かどうかを確認できます。
コマンドプロンプト(CMD)を開きます。
`ping <マウントポイントアドレス>` を実行して待機時間を記録します。
`ping <マウントポイントの IP アドレス>` を実行して待機時間を記録します。
結果を比較する: IP アドレスに ping を実行したときの待機時間が、マウントポイントアドレスに ping を実行したときの待機時間よりもはるかに短い場合は、DNS 解決が遅くなっています。ECS インスタンスの DNS 構成を確認してください。