Go ランタイムにおける「無害」なラッパーが引き起こすパフォーマンス劣化：sendfile 無効化の解説

小型のファイルサーバー開発中に、単一行の変更で CPU 使用率が倍増し、スループットが半減するという深刻な障害が発生しました。原因は、

io.Copy

sendfile(2)

この記事では、なぜその仕様が成立するのか、確認方法、そして回避策について解説します。

環境設定 (The setup)

本記事のベンチマークは以下の環境で行っています。

• OS: Linux 6.6 / Ubuntu 24.04 (WSL2)
• CPU: AMD Ryzen 5 9600X
• RAM: 16 GiB
• Go Version: 1.22.1
• ワークロード: 512 MiB のランダムバイトファイル（ページキャッシュがウォーム状態）

測定条件

• サーバーとクライアントは同一マシン上で動作。
• 同じ

  big.bin

  ファイルを単純な TCP 経由で配信。
• サーバー: CPU コア 0 にピン留め、クライアント: CPU コア 1 にピン留め。
• 計測ツール:

  /usr/bin/time

  （サーバーサイド時間計測）。
• システムコール追跡:

  strace -c -e trace=read,write,sendfile,splice

sendfile が実際に何を行うか (What sendfile actually does)

通常の転送（スローパス）

通常の「ファイルを転送する」という動作は、データをユーザー空間のバッファを往復する必要があります。

1. ディスク → ページキャッシュ

2. read()

   でユーザーバッファへコピー

3. write()

   でソケットバッファへコピー
4. NIC

このプロセスでデータが2 回コピーされます（ディスク↔RAM、RAM↔NIC）。

sendfile(2)（高速パス）

sendfile(2)

1. ディスク → ページキャッシュ

2. sendfile()

   でソケットバッファへ直接結合（splice）
3. NIC

• データはアドレス空間を通過しません。
• カーネルがページキャッシュのページをそのままソケット送信キューに結合します。

注意: ソケットからソケットへの転送には

splice(2)

高速パス (The fast path) の内部動作

Go ランタイムの

io.Copy

io.ReaderFrom

*net.TCPConn

*os.File

このロジックは

net/sendfile_linux.go

os/zero_copy_linux.go

// (simplified, in net/sendfile_linux.go)
lr, ok := r.(*io.LimitedReader)
if ok { 
    remain, r = lr.N, lr.R 
}
f, ok := r.(*os.File)
if !ok { 
    return 0, nil, false // 高速パス利用不能、スローパスへフォールバック 
}
// ... sendfile ループを実行 ...

重要な要件:

1. スイッチ文によるタイプライド断定（Type Assertion）が成功しなければならない。
2. 型システムとしては有効でも、ランタイム側で明示的に

   *os.File

   か

   *io.LimitedReader

   かを検出できない場合、高速パスは利用できません。

3 つのハンドラー比較 (Three handlers, one file)

以下の 3 つのパターンを

io.Copy(conn, destination)

1. raw: 原生ファイル（高速パス使用）

*os.File

_, _ = io.Copy(conn, f)

• 結果: 高速パスが維持される。

2. wrapped: 無害なラッパー（高速パス失墜）

単なる

io.Reader

type justReader struct {
    r io.Reader 
}
func (j justReader) Read(p []byte) (int, error) { return j.r.Read(p) }

// 無害に見えますが、*os.File は見えないため高速パス失效
_, _ = io.Copy(conn, justReader{r: f}) 

• 結果: タイプライド断定（

  *os.File

  ）に失敗し、スローパスへフォールバック。

3. limit: ランタイム認識のラッパー（高速パス維持）

*io.LimitedReader

_, _ = io.Copy(conn, io.LimitReader(f, fileSize))

• 結果: ランタイムは

  *io.LimitedReader

  のチェックを内部で実装しており、アンラップして処理するため、高速パスが維持される。

結論: 「ただバイト数を数えたいだけ」というミドルウェアの実装（例：

justReader

strace による監視 (Watching it with strace)

各パターンのシステムコール呼び出しを確認します。512 MiB の転送を 5 回繰り返し、サマリーを比較しました。

raw (

io.Copy(conn, f)

)

sendfile

EAGAIN

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.79    0.231981          78      2958       860 sendfile
  0.15    0.000359          51         7         1 write
  0.05    0.000126          18         7           read
------ ----------- ----------- --------- --------- ----------------
100.00    0.232466          78      2972       861 total

wrapped (

io.Copy(conn, justReader{f})

)

sendfile はゼロ回。全てのデータがユーザー空間を往復します。

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 56.67    3.202339          48     65546         3 write
43.33    2.448353          37     65547           read
------ ----------- ----------- --------- --------- ----------------
100.00    5.650692          43    131093         3 total

• read: ~6.5 万回、write: ~6.5 万回（合計 13 万回以上の Syscall）。
• データサイズ：

  io.Copy

  のデフォルトバッファサイズ（32 KiB）のチャンクで往復。
• CPU コスト: raw に比べて約 24 倍 のウォール時間が必要になります。
• Flamegraph: ヒートスタック上部が

  io.Copy

  ->

  io.copyBuffer

  ->

  syscall.Read/Write

  と続くことを示しています。

limit (

io.Copy(conn, io.LimitReader(f, n))

)

raw と同様に高速パス作動。

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.84    0.239191          82      2896       893 sendfile
  0.14    0.000330          47         7         1 write
  0.02    0.000047           6         7           read

この代償 (What this costs)

CPU 使用時間の比較

（サーバーユーザー＋システム CPU / 10 x 512 MiB ファイル転送）

• 結論:

  wrapped

  パターンでは、バイトあたりの CPU コストが約 3.4 倍 に増大します。
• ネットワーク環境や負荷が高くなると、この差はさらに顕著になり、テールレイテンシ（tail latency）を大幅に悪化させます。

スplice の活用（プロキシの場合）

ソケットからソケットへの転送でも同様のルールが適用されます。

io.Copy

splice

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.98    0.754999          70     10677       481 splice
  0.01    0.000109          13         8           read
  0.01    0.000065          65         1           write

ラップしていない場合は

splice

指針 (Rules of thumb)

高速パスを維持するための実践的なガイドラインです。

• 🚫 ラップしない（原則）:

  io.Reader

  や

  io.Writer

  を実装してラップすることを避けてください。ファイルと接続の間に層が増えるほど、タイプ断定で高速パスが失われるリスクが高まります。

• ✅ 必須の場合はインターフェースを実装せよ: ラップせざるを得ない場合でも、転送のディスパッチを

  io.Copy

  に委ねるためには、ソース側に

  io.WriterTo

  、宛先側に

  io.ReaderFrom

  を実装してください。これにより、ランタイムが独自の実装（splice 等）を利用し続けます。

• 💡 io.LimitReader は例外なく無料: レンジレスポンスなど、バイト数の制御が必要な場合のみ、標準ライブラリの

  io.LimitReader

  を使用してください。ランタイムはこれを特定して高速パスを維持するため、他の自作ラッパーとは異なりコストゼロです。

• 🛠️ strace で検証せよ: 直感に頼らず

  strace -c

  を実行してください。
  • 正常:

    sendfile

    または

    splice

    が主体で、read/write はほぼゼロ。
  • 異常: read/write のペアが数万分の回呼び出されている（32 KiB チャンク）場合、高速パスに乗っていない証拠です。

• ⚠️ 常に高速パスがあると仮定せず: フレームワークや特定のライブラリによって

  io.Copy

  が裏で別の処理を行っている可能性があります。sendfile ルートを回避する理由を常に確認してください。

まとめ:

sendfile

と

splice

は Go ランタイムが無料で提供する重要な機能ですが、最も良意のある理由（メトリクス測定や型変換など）で追加された「無害なラッパー」によって容易に破壊されます。システムコールのプロファイリングを習慣化し、データコピーのコストを意識してコードを書きましょう。