SMBプロトコルを使用して上記のNASデバイス上に作成された共有フォルダにファイルをダウンロード/アップロードする際、転送速度は180~200MB/sの範囲です。ターゲットNASサーバーとクライアントPCの間には、10Gb/sの速度を完全にサポートする構成のスイッチがあります。上記NASサーバーのSCAコントローラーには10GBase-T拡張カードが搭載されていることも付記します。
SSH接続を利用し、“ifcfg status eth8”コマンドで接続に使用されているポートの状態を確認しました。
また、iperf3による接続テストも実施しました。“iperf3 -c -P 64”コマンドを使用し、接続が約10Gb/sの速度に対応していることを確認しました。
NASサーバーの全スロットと拡張部分にはディスクが搭載されており、RAID5が構築されています。その後、上記RAID全体の容量を使用して共有フォルダが作成されました。
user712471326:
上記に記載されたNASデバイスについて
デバイスについての記載は見当たりません。QESについての記述のみです。ご使用のモデルとファームウェアの情報を追加していただけますか?
Lucas
2026 年 2 月 21 日午前 1:28
3
@user712471326 様
QESシステムでのSMBパフォーマンスについて、詳細な技術情報をご提供いただき誠にありがとうございます。iperf3やifcfgによる診断結果から、10GbEネットワークバックボーンが正常に動作していることが確認できました。ご尽力に感謝いたします。
SMBのスループットボトルネック(180~200MB/s)について調査を進めるため、以下の点についてご確認いただけますでしょうか?
問題発生のタイムライン: 転送速度は以前は正常でしたか?それとも初期設定時からこの速度でしょうか?
他端末でのテスト: 10GbE NICを搭載した他のクライアントPCから接続した場合も同様の速度制限が見られますか?この確認により、ボトルネックが特定のクライアントなのかNAS構成なのかを判断できます。
お使いのハードウェア環境(SCAコントローラーおよびQES上のRAID 5)の複雑さを考慮し、システムログの詳細分析を行うためにも、正式なサポートチケットの発行を強くおすすめいたします。
チケットのご提出はこちらから: https://service.qnap.com/
よろしくお願いいたします。
QNAPサポートチーム
デバイスはEs1686dc R2で、ファームウェアは2.2.1.2513 Build 20251126です。
初期設定後、旧QNAPサーバーから新しいEs1686dc R2(ファームウェア2.2.1.2513 Build 20251126)へのデータ転送を開始しました。ネットワークは最初の数日間は問題なく動作し、速度は900〜1000MB/sに達しました。その間、QNAP Es1686dc R2サーバー上で設定変更は行っていません。初回起動から約1か月後、問題が発生しました。私のチームと私は、異なるクライアントマシンで問題が発生するかどうかをテストしました。どのデバイスでも、10Gbps接続にもかかわらず速度は約200MB/sにとどまりました。異なるケーブル、MTU 9000、異なるSMB規格も試しましたが、良い結果は得られませんでした。
SSHやコマンドラインでNASにアクセスすることに慣れている場合、いくつか確認しておきたいことがあります。これらはどれも設定変更を伴うものではなく、ネットワークスタックをコンソールインターフェースで確認するだけです。
まず最初に by
cat /sys/class/net/eth0/speed
[eth0ネットワークポートを使用していない場合は、上記コマンド内の値を実際に使用しているポート名に変更する必要があります。]私はTVS672XTを使っていて、これはネイティブで10Gbポートを搭載しているので、上記コマンドを実行すると「10000」と表示されます。これで、少なくともNASのネットワークアダプターが本当に10Gbで動作していて、他の(つまり外部の)要因で速度が落ちていないことを確認できます。
もうひとつ試せるコマンドは
ifconfig -a
です。
このコマンドではかなり多くの出力が得られますが、物理/仮想アダプターごとにブロックで分かれているのが比較的簡単に分かります。デフォルトアダプター(通常はeth0)を見つけたら、出力の3行目と4行目を確認してください。ここにエラーやドロップされたパケット数が表示されます。私の672でこのコマンドを実行したときの例は以下の通りです。
eth0 Link encap:Ethernet HWaddr 24:5E:BE:53:7F:06
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:222358095 errors:0 dropped:161 overruns:0 frame:0
TX packets:372509639 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:230092094401 (214.2 GiB) TX bytes:455412818198 (424.1 GiB)
ご覧の通り、このアダプターはパケットを161個ドロップしています(再起動してから31日間で)。もし大量のエラーやドロップされたパケットが見つかった場合、それはより深刻な問題を示しているかもしれません。
最後に、これは正確な問題特定にはならないかもしれませんが、プロトコル関連の課題を切り分けるのに役立つかもしれません。unixやlinuxホストにアクセスできる場合は、NFSネットワーキングプロトコルを有効化して、CIFSではなくNFSでパフォーマンステストをしてみてください。
Microsoft Windows 11 Pro にはNFSの統合サポートがありますが、利用するには有効化が必要です。手順はGoogleで検索してください… ワークステーションでNFSクライアントを動作させ、コントロールパネルからNFSを有効化できたら、2つの異なるネットワークプロトコルで並行テストができるはずです。ここで差(delta)が出ればプロトコルの問題が示唆されますし、同じまたは非常に近い結果であれば、問題は接続のトランスポート層または物理層にあることが示唆されます。
最後に、最初の問題説明ではパフォーマンスが最初は正常だったがその後悪化したとあります。もし変化が急激だった場合、どこかで何らかの「変更」が加えられた結果かもしれません。「変更」とは広い意味で、例えば「誰かがケーブルを動かして微妙な接続状態になった」…あるいは実際の技術的な設定変更かもしれません。もし変化が徐々に進行したものであれば、リソースの徐々の枯渇やメモリリークなどが考えられます。これらの可能性は、回路内のすべてのデバイス(NAS、ホスト、ネットワーク機器)を再起動することで排除できるかもしれません。これでも問題が見つからないかもしれませんが、調査範囲を絞り込むのには役立つかもしれません。
SSH経由でサーバーに接続する際は、QTSで使用するコマンドとは異なるコマンドを使用します。ここでは、「ifcfg」コマンドを使用しています。例えば、「status eth8」という変数を追加すると、次のような情報が返されます。
OK、ここからいくつかのことが分かります… ハードウェアレベルでは、少なくともNASからスイッチまでは確実に10Gb/sで動作しています。また、「MTU … 9000」の設定から、「ジャンボフレーム(jumbo frames)」が有効になっていることが分かります。これは10Gb/sネットワークで最適なパフォーマンスを得るためにまさに必要な設定です。
これは決定的な証拠ではありませんが… 潜在的な問題を着実に排除できています。
この転送の「もう一方の端」でも同様のチェックを行い、そちらも10Gbで設定されていることが確認できれば、次のステップはエラーやドロップパケットのデータを確認すること、または両方のホストでNFSを使用するように設定し、並行して比較テストを行うことになるでしょう。
私の経験は古いですが… NFSの方がCIFSと比べて「ワイヤ上」でより効率的だと思っていました。CIFSはそれに比べて「少しおしゃべり」だからです。ただし、その情報は10年以上前のもので、NFSv4や最新のCIFSバージョンでは状況が変わっているかもしれません。
最初の速度が10Gbpsだったことに興味を持っています。これはSMBマルチチャネル(SMB Multichannel)のサポート不足によるものなのか疑問に思います。
https://www.qnap.com/en/how-to/faq/article/does-qes-support-smb-multichannel
この質問は少なくとも最初は脇に置いておきたくなります。というのも、あなたが説明しているのは、時間の経過とともにパフォーマンスが低下したという問題だからです。互換性の問題は(少なくとも私が知る限り)もっとバイナリな性質のもので、動くか動かないかのどちらかです。あなたの問題の説明からすると、互換性が根本原因であるとは考えにくいです。
「何が問題で」「何が問題でないか」というあなたの説明にもう一度焦点を当てたいと思います。
もう少し範囲を絞ってみましょう…
ネットワーク上に他のNASやサーバーデバイスがあり、クライアントをそれらでテストできる場合、問題が特定のデバイスにあると断言できますか?
再現可能で客観的な速度テストを行えるようなテストを設定できますか?例えば、Windowsのシェルスクリプトでタイマーをゼロにし、NASからホストへ(またはホストからNASへ)1つ以上のファイルをコピーし、所要時間を記録することができます。これをシンプルなシェルスクリプトとして用意し、異なるホストや異なるタイミングで客観的に繰り返せると非常に役立ちます。
デバイスは何らかのネットワーク機器を介して接続されているはずで、ワークステーションとNASの間に1つ以上のイーサネットスイッチがあるかもしれません。ここでいくつか確認事項があります。まず、クライアントマシンを物理的にNASと同じ場所に移動し、テストを再実行して中間のネットワーク機器をすべて排除できますか?次に、ネットワーク機器はマネージドですか、それともアンマネージドですか?前者なら、SNMPワークステーションがあればネットワーク機器からパフォーマンス指標を取得できるかもしれません。
QNAP NAS上で、SSH経由で「ethtool」を実行してみてください。コマンドラインオプションの意味や使い方はGoogleで調べられます。WindowsではPowershellの「Get-NetAdapterStatistics」を使い、ワークステーションのネットワークアダプタのパフォーマンスを確認できます。
すでに述べましたが、ホスト間でCIFS以外のプロトコルをテストできると役立つと思います。NFSを推奨します。NASをNFS接続要求に対応するよう設定し(バージョン設定も正しく)、テストしてみてください。無理ならftpやsftpの利用も検討してみてください。
6つ目は明白な点、つまり「変更」です。問題が長期間正常に稼働した後に発生したという事実は、何かが変わったことを強く示唆しています。組織の規模や技術変更の管理体制については説明されていませんが、主たる関心領域とは直接関係のない何かが原因となっている可能性もあります。変更履歴を確認したり、環境管理者に相談したりしてみてください。
7つ目は信頼性です。NAS自体は基本的に「動くか動かないか」ですが、例えばハードディスクに不良がある可能性はありませんか?NASがハードディスクの問題を検出した場合、外部にアラートを送信するよう設定されていますか?S.M.A.R.T.監視で正常と判定されていますか?
8つ目はネットワーク利用率です。ネットワーク上で他の何かが帯域を大量に消費し、NASがパケットを送信できない状況になっていませんか?このため、最初にクライアントワークステーションとNASを物理的に近づけ、2台だけをスイッチに接続してパフォーマンステストを再実行するのが良いと思います。それでも失敗するなら、どちらかのデバイスに問題があると分かります。うまくいけば、今度はワークステーションを徐々に離していき、どこでパフォーマンスが低下するかを「逆追跡」できます。
ここからはより特殊な原因の可能性です。例えば「Remote File Dirt Page」しきい値など、ワークステーションのパフォーマンスを確認しましたか?これが今回のような問題を引き起こすことがあります。基本的に、Windowsクライアントには「ダーティ」かつ「未保存」データ用のデフォルトバッファ(通常5GB程度)があり、このしきい値を超えると、システムはディスクへの書き込みが終わるまで新たなデータの受信を停止します。レジストリの「RemoteFileDirtyPageThreshold」パラメータ(Googleで調べてください)をテストの前後で調整し、違いが出るか確認できます。
まだ試していなければ、ぜひMicrosoftサポートコミュニティにも質問してください。規模が大きく(当然ですが)、同様の事例を見たことがある人がいるかもしれません。
上記はやや散発的なアプローチになってしまいましたが(一応論理的な順序でテストを並べたつもりです)、すべてをそのまま実施できなくても、何かヒントになるアイディアが得られれば幸いです。
NA9D
2026 年 2 月 24 日午後 7:52
11
SMBマルチチャネル(SMB multi-channel)は、複数のNIC(ネットワークインターフェースカード)がある場合に、より高速な接続を実現するために使用されます。例えば、2つの2.5 Gbit/s NICがある場合、両方を使ってSMB接続でデータ転送が可能です。
デュアルまたはそれ以上の10Gbps接続でも同じことができますが、それはあなたの問題ではないようです。私には、単一の10Gbps接続で期待した速度が出ていないように思えますので、マルチチャネルは助けにならないでしょう。
もう一台、古いQNAP QTS Hero NASサーバーがネットワークに接続されています。SMB経由でサーバーとのファイルのコピー速度は、期待通り1GB/sに達しています。
テスト用ステーションをes1686dc R2 NASサーバーの10Gbpsポートに直接接続しました。スイッチを介さない直接接続にもかかわらず、転送速度は依然として約200MB/s前後で変動しています。
このQNAPには「ethtool」コマンドがありません。利用可能なコマンドの一覧は以下の通りです。
SMARTテストを実施しましたが、全ドライブは正常で、イベントログも確認しましたがエラーや警告はありませんでした。
FTP接続もテストしましたが、結果はSMBよりも悪く、約95MB/sでした。
30台以上あるコンピューターのうち1台だけ、速度が200MB/sを超える状況があります。具体的には約600MB/sに達しますが、速度は安定せず、300~600MB/sの間で変動します。つまり、接続の安定性が全くありません。
QNAPからターゲットPCに直接iperfを使って速度を確認してください。そこで10Gしか出ない場合、以下のような要因が考えられます。
ファイルの種類と数(サイズ)
NASやPCで他に何が動作しているか
ターゲットPCの書き込みキャッシュのサイズ。いくつかのギガバイトのファイルであれば、最大速度を出すことができます。
転送前にNASから読み込む必要がある場合、転送速度は大幅に低下します。PCの書き込みキャッシュがいっぱいの場合も同様です。
大量のデータを転送したい場合、約500MB/sが現実的です。
私は世界中の多数のQNAP、PC、サーバー、ストレージシステムでこれをテストしました。
– 英語に翻訳された「Mr worldwide」がドイツ語で投稿 –
最初のメッセージで、iperf3の結果を提示しました。この接続は10Gbpsに対応しています。ファイルの数やサイズは関係ありません。100~500GBの単一ファイルを送信またはダウンロードしようとしても、速度は約200MB/sで安定しています。
qnapを確認し、ストレージとスナップショットの概要でディスクを選択し、ディスクの健康状態をチェックし、詳細設定でNCQがすべてのディスクでACTIVEになっていることを確認してください。
また、コンピュータとqnapのすべての10Gbitインターフェースが10Gbitになっていて、2.5Gbitになっていないことも確認してください。
接続速度のテストには、常に無料のBlackmagic Speedtestソフトウェア(インターフェースとディスクのテスト)を基準として使用しています。また、QNAPでリビルドが実行中でないことも確認してください。リビルド中はリビルド速度に依存して速度が制限されます。
皆さん、こんにちは。この問題に数日間苦しんだ結果、部分的な解決策を見つけました。まず最初に、ES1686DC R2を再起動したことをお伝えします。あらゆる共有フォルダー設定で、様々なプールおよびRAID構成を作成しました。スイッチやスイッチの設定、ケーブル、クライアントPCも変更しました。さらに、2台目のNASであるTS-h1277AXU-RPは常時ネットワークに接続されており、全く問題なくネットワーク速度(10Gbps)をフルに活用できています。
チームとともに、興味深い状況を発見しました。クライアント側でSMB署名を無効にするコマンド、
Set-SmbClientConfiguration -RequireSecuritySignature $false
を使用したところ、速度が200MB/sから650MB/sに向上しました。しかし、まだ完全には問題を解決できていません。SMB署名に関連する潜在的な問題に遭遇した方はいらっしゃいますか?
クライアントPCに関する情報も追記します。
Windows 11 Pro (25H2)
ASUS ProArt X870E
AMD Ryzen 9 9950X
192GB RAM
ネットワークカード: Aquantia/Marvell AQC113 FastLinQ Edge 10Gbit Network Adapter
ドライブ: 3x Samsung SSD 9100 PRO 4TB