2.5GbE の NAS が 90MB/s しか出ない、の原因はケーブルでもディスクでもなかった

NAS を 2.5GbE で繋いでいるのに、Windows から SMB で書き込むと 90MB/s あたりで頭打ちになる。ケーブルを疑い、ディスクを疑い、Samba の設定を疑って半日溶かしたので、切り分けの順序を残しておく。結論から書くと、経路の問題だった。

まず「どこが遅いのか」を分ける

ストレージ越しの速度が出ないとき、犯人になりうるのは大きく3つある。ディスク、ネットワーク、そしてプロトコル。これを混ぜたまま測っても何も分からないので、順に切り離す。

1. ディスク単体

NAS 上で直接 dd を叩く。キャッシュに乗せないよう direct I/O を指定して、キャッシュサイズより十分大きいサイズで測る。

# 書き込み
dd if=/dev/zero of=/volume1/testfile bs=1M count=10240 oflag=direct

# 読み込み（キャッシュを落としてから）
sync; echo 3 > /proc/sys/vm/drop_caches
dd if=/volume1/testfile of=/dev/null bs=1M iflag=direct

結果はおおむね次のとおりで、HDD アレイとしては妥当な数字だった。

ここで 90MB/s しか出ていなければディスクが犯人だが、そうではない。次へ進む。

2. ネットワークの素の帯域

iperf3 で TCP のスループットだけを測る。ファイルシステムもプロトコルも介在しない。

# NAS 側
iperf3 -s

# クライアント側（送信）
iperf3 -c <nas> -t 20
# 受信方向も見る
iperf3 -c <nas> -t 20 -R

ここで 2.3Gbps 前後が出るなら物理層は健全。出ないなら、ケーブル・NIC のリンク速度・オートネゴシエーションを確認する。ethtool でリンク速度が 1000Mb/s に落ちていないかは最初に見ておくとよい。

3. SMB 越し

1 と 2 が健全で 3 だけが遅い場合、初めて SMB の設定を疑う価値が出てくる。

実際の原因

私の環境では、2 の時点で送信 727Mbps / 受信 1.34Gbps という中途半端な値が出た。物理は 2.5GbE なのに、1GbE でもない微妙な数字。

犯人は、クライアントに入れていたメッシュ VPN のサブネットルート受け入れ設定だった。同じ LAN 内にある NAS 宛の通信まで、VPN のトンネルを経由して回っていた。ローカルなのに一度暗号化されて戻ってくるので、CPU とオーバーヘッドの分だけ確実に遅くなる。

接続元 IP を確認すれば一発で分かる。NAS 側で smbstatus を見たとき、接続元が LAN のアドレスではなく VPN 側のアドレスになっていた。

smbstatus | head -20

サブネットルートの受け入れを切ったところ、同じ測定で 2.38Gbps まで戻った。SMB 越しの CrystalDiskMark も連動して改善した。

教訓

• 速度が出ないときは、まず接続元 IP を確認する。想定した経路を通っているとは限らない
• メッシュ VPN のサブネットルートは便利だが、同一 LAN 内でも黙ってトンネルを通す。ローカル接続とリモート接続で名前を分けておくと、どちらを踏んでいるか明示できる
• ディスク・ネットワーク・プロトコルは必ず別々に測る。まとめて測ると、どこを直せばいいか永遠に分からない

なお OS によって挙動が違う点も付記しておくと、同じ設定でも macOS 側ではサブネットルート受け入れの有無で速度差がほとんど出なかった。実装依存なので、環境ごとに測るしかない。