# Check NIC ring buffer sizes
ethtool -g eth0
# Monitor socket buffer usage
ss -tm
# Check for TCP zero window events
tcpdump -i any 'tcp[tcpflags] & tcp-push != 0' -vv
# Check network statistics for buffer issues
netstat -s | grep -i "buffer\|queue\|drop"
Windows 診断
# Check TCP parameters
netsh interface tcp show global
# View network adapter buffer settings
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where-Object {$_.DisplayName -like "*buffer*"}
# Monitor TCP statistics
netstat -s -p tcp
# Check receive window auto-tuning
netsh interface tcp show global | findstr "Receive Window"
macOS 診断
# Check current buffer settings
sysctl kern.ipc.maxsockbuf
sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace
# View network statistics
netstat -s -p tcp
# Monitor socket buffers
netstat -an -p tcp
Linuxのバッファチューニング
レガシー Linux 設定 (2009 年頃)
| パラメータ |
レガシーバリュー (2009) |
説明 |
| net.core.rmem_default |
124928 (122KB) |
デフォルトの受信ソケットバッファサイズ |
| net.core.rmem_max |
131071 (128KB) |
最大受信ソケットバッファサイズ |
| net.core.wmem_default |
124928 (122KB) |
デフォルトの送信ソケットバッファサイズ |
| net.core.wmem_max |
131071 (128KB) |
最大送信ソケットバッファサイズ |
| net.ipv4.tcp_rmem |
4096 87380 174760 |
TCP 受信バッファ: 最小、デフォルト、最大 (バイト単位) |
| net.ipv4.tcp_wmem |
4096 16384 131072 |
TCP 送信バッファ: 最小、デフォルト、最大 (バイト単位) |
| net.ipv4.tcp_mem |
196608 262144 393216 |
TCP メモリ ページ: 低、圧力、高 |
| net.core.netdev_max_backlog |
1000 |
入力キュー内の最大パケット数 |
| net.core.optmem_max |
10240 (10KB) |
ソケットあたりの最大補助バッファ サイズ |
現在の Linux 設定 (2025-2026)
| パラメータ |
現在の推奨値 |
説明 |
| net.core.rmem_default |
16777216 (16MB) |
デフォルトの受信ソケットバッファサイズ |
| net.core.rmem_max |
134217728 (128MB) |
最大受信ソケットバッファサイズ |
| net.core.wmem_default |
16777216 (16MB) |
デフォルトの送信ソケットバッファサイズ |
| net.core.wmem_max |
134217728 (128MB) |
最大送信ソケットバッファサイズ |
| net.ipv4.tcp_rmem |
4096 87380 134217728 |
TCP 受信バッファ: 最小、デフォルト、最大 (最大 128MB) |
| net.ipv4.tcp_wmem |
4096 65536 134217728 |
TCP 送信バッファ: 最小、デフォルト、最大 (最大 128MB) |
| net.ipv4.tcp_mem |
8388608 12582912 16777216 |
TCP メモリ ページ: 低、プレッシャー、高 (64GB システム) |
| net.core.netdev_max_backlog |
250000 |
入力キュー内の最大パケット数 (10GbE+) |
| net.core.optmem_max |
65536 (64KB) |
ソケットあたりの最大補助バッファ サイズ |
| net.ipv4.tcp_congestion_control |
ああ |
BBR 輻輳制御 (Google のアルゴリズム) を使用する |
| net.ipv4.tcp_window_scaling |
1 |
TCP ウィンドウ スケーリングを有効にする (RFC 1323) |
| net.ipv4.tcp_timestamps |
1 |
RTT 推定を改善するために TCP タイムスタンプを有効にする |
| net.ipv4.tcp_sack |
1 |
選択的確認応答を有効にする |
| net.ipv4.tcp_no_metrics_save |
1 |
TCP メトリクスのキャッシュを無効にする |
Linux 構成アプリケーション
これらの設定を/etc/sysctl.confまたは新しいファイルを作成します/etc/sysctl.d/99-network-tuning.conf:
# Network Buffer Tuning for High-Performance Applications
# Optimized for 10GbE+ networks with RTT up to 300ms
# Core socket buffer settings
net.core.rmem_default = 16777216
net.core.rmem_max = 134217728
net.core.wmem_default = 16777216
net.core.wmem_max = 134217728
# TCP buffer settings
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_mem = 8388608 12582912 16777216
# Device buffer settings
net.core.netdev_max_backlog = 250000
net.core.netdev_budget = 50000
net.core.netdev_budget_usecs = 5000
net.core.optmem_max = 65536
# TCP optimizations
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
# Apply with: sysctl -p /etc/sysctl.d/99-network-tuning.conf
NICリングバッファのチューニング
# Check current ring buffer sizes
ethtool -g eth0
# Set maximum ring buffer sizes (adjust based on NIC capabilities)
ethtool -G eth0 rx 4096 tx 4096
# Make persistent by adding to /etc/network/interfaces or systemd service
重大な警告 - メモリ消費量:tcp_mem 値はメモリ ページ (通常は 4KB) 内にあります。バッファ サイズが大きいと、深刻なメモリ負荷が発生する可能性があります。
-
接続ごとのメモリ:各接続は最大 rmem_max + wmem_max (128MB バッファで 256MB) を使用できます。
-
システム全体への影響:1,000 接続 × 256MB = 256GB の潜在的な使用量
-
安全な推定:最大同時接続数 × 256MB はシステム RAM の 50% を超えてはなりません
-
例:64GB サーバーでは、最大接続数を 128MB バッファーを使用した最大 125 の同時高スループット接続に制限する必要があります。
-
RAM が 16GB 未満のサーバーの推奨事項:バッファを最大 16 ~ 32MB に減らし、それに比例して tcp_mem を調整します
Windowsのバッファチューニング
従来の Windows 設定 (2009 年頃 - Windows Vista/7/Server 2008)
| パラメータ |
レガシーバリュー (2009) |
位置 |
| Tcpウィンドウサイズ |
65535 (64KB) |
レジストリ: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters |
| Tcp1323オプト |
0 (無効) |
ウィンドウのスケーリングはデフォルトで無効になっています |
| デフォルト受信ウィンドウ |
8192 (8KB) |
デフォルトの受信ウィンドウ |
| デフォルトの送信ウィンドウ |
8192 (8KB) |
デフォルトの送信ウィンドウ |
| GlobalMaxTcpWindowSize |
65535 (64KB) |
最大 TCP ウィンドウ サイズ |
| TcpNumConnections |
16777214 |
最大TCP接続数 |
現在の Windows 設定 (Windows 10/11/Server 2019-2025)
最新の Windows では、受信ウィンドウの自動調整ネットワークの状況に基づいて受信バッファを動的に調整する機能。
| 特徴 |
現在の推奨設定 |
説明 |
| オートチューニングレベル |
通常 (または 10GbE+ については非常に実験的) |
動的受信ウィンドウ調整 |
| 受信側スケーリング (RSS) |
有効化 |
ネットワーク処理を CPU 全体に分散する |
| 煙突のオフロード |
自動 (または最新の NIC では無効) |
NIC ハードウェアへの TCP オフロード |
| NetDMA |
無効 |
ダイレクト メモリ アクセス (非推奨) |
| TCP グローバルパラメータ |
以下のコマンドを参照してください |
システム全体の TCP 設定 |
| 輻輳プロバイダー |
CUBIC (または NewReno フォールバック) |
TCP輻輳制御アルゴリズム |
Windows 設定コマンド
# Check current auto-tuning level
netsh interface tcp show global
# Enable auto-tuning (normal mode - default for most scenarios)
netsh interface tcp set global autotuninglevel=normal
# For high-bandwidth, high-latency networks (10GbE+, data center environments)
netsh interface tcp set global autotuninglevel=experimental
# For conservative tuning (if experimental causes issues)
netsh interface tcp set global autotuninglevel=restricted
# For very conservative tuning (not recommended for high-performance networks)
netsh interface tcp set global autotuninglevel=highlyrestricted
# Enable CUBIC congestion provider (Windows Server 2022/Windows 11+ only)
netsh interface tcp set supplemental template=Internet congestionprovider=cubic
# Note: Windows 10 and Server 2019 use Compound TCP or NewReno by default
# CUBIC is not available on these older versions
# Enable Receive-Side Scaling (RSS)
netsh interface tcp set global rss=enabled
# Set chimney offload (automatic is recommended)
netsh interface tcp set global chimney=automatic
# Disable NetDMA (recommended for modern systems)
netsh interface tcp set global netdma=disabled
# Enable Direct Cache Access (if supported)
netsh interface tcp set global dca=enabled
# Enable ECN (Explicit Congestion Notification)
netsh interface tcp set global ecncapability=enabled
# Set initial congestion window to 10 (RFC 6928)
netsh interface tcp set global initialRto=3000
高度な NIC バッファ設定 (デバイス マネージャーまたは PowerShell 経由)
# View current adapter settings
Get-NetAdapterAdvancedProperty -Name "Ethernet"
# Increase receive buffers (adjust based on NIC)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue 2048
# Increase transmit buffers
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue 2048
# Enable Jumbo Frames (if network supports it)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Jumbo Packet" -DisplayValue 9014
# Enable Large Send Offload (LSO)
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue Enabled
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Large Send Offload V2 (IPv6)" -DisplayValue Enabled
レジストリの調整 (上級 - 慎重に使用してください)
# These settings are typically NOT needed on Windows 10/11 due to auto-tuning
# Only modify if auto-tuning is disabled or problematic
# Registry path: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
# Maximum TCP window size (if auto-tuning disabled)
# TcpWindowSize = 16777216 (16MB) - REG_DWORD
# Enable window scaling (enabled by default on modern Windows)
# Tcp1323Opts = 3 - REG_DWORD
# Number of TCP Timed Wait Delay
# TcpTimedWaitDelay = 30 - REG_DWORD (default 240)
警告:最新の Windows (10/11/Server 2019 以降) では、自動チューニングによって問題が発生しない限り、レジストリを手動で変更しないでください。一般に、自動調整アルゴリズムは静的設定よりも優れています。
macOSのバッファチューニング
従来の macOS 設定 (2009 年頃 - Mac OS X 10.5/10.6)
| パラメータ |
レガシーバリュー (2009) |
説明 |
| kern.ipc.maxsockbuf |
262144 (256KB) |
ソケットバッファの最大サイズ |
| net.inet.tcp.sendspace |
32768 (32KB) |
デフォルトの TCP 送信バッファ |
| net.inet.tcp.recvspace |
32768 (32KB) |
デフォルトのTCP受信バッファ |
| net.inet.tcp.autorcvbufmax |
131072 (128KB) |
自動調整された最大受信バッファー |
| net.inet.tcp.autosndbufmax |
131072 (128KB) |
自動調整された最大送信バッファー |
| net.inet.tcp.rfc1323 |
0 (無効) |
TCPウィンドウスケーリング |
現在の macOS 設定 (macOS 12-15 モントレーからセコイアまで)
| パラメータ |
現在の推奨値 |
説明 |
| kern.ipc.maxsockbuf |
8388608 (8MB) |
ソケットバッファの最大サイズ |
| net.inet.tcp.sendspace |
131072 (128KB) |
デフォルトの TCP 送信バッファ |
| net.inet.tcp.recvspace |
131072 (128KB) |
デフォルトのTCP受信バッファ |
| net.inet.tcp.autorcvbufmax |
16777216 (16MB) |
自動調整された最大受信バッファー |
| net.inet.tcp.autosndbufmax |
16777216 (16MB) |
自動調整された最大送信バッファー |
| net.inet.tcp.rfc1323 |
1 (有効) |
TCP ウィンドウ スケーリングを有効にする |
| net.inet.tcp.sack |
1 (有効) |
選択的確認応答を有効にする |
| net.inet.tcp.mssdflt |
1440 |
デフォルトの TCP 最大セグメント サイズ |
| net.inet.tcp.layed_ack |
3 |
遅延 ACK 動作 |
macOS 設定アプリケーション
# Check current settings
sysctl kern.ipc.maxsockbuf
sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace
sysctl net.inet.tcp.autorcvbufmax
sysctl net.inet.tcp.autosndbufmax
# Apply settings temporarily (until reboot)
sudo sysctl -w kern.ipc.maxsockbuf=8388608
sudo sysctl -w net.inet.tcp.sendspace=131072
sudo sysctl -w net.inet.tcp.recvspace=131072
sudo sysctl -w net.inet.tcp.autorcvbufmax=16777216
sudo sysctl -w net.inet.tcp.autosndbufmax=16777216
sudo sysctl -w net.inet.tcp.rfc1323=1
sudo sysctl -w net.inet.tcp.sack=1
# Make settings persistent (create /etc/sysctl.conf)
sudo tee /etc/sysctl.conf <<EOF
kern.ipc.maxsockbuf=8388608
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.inet.tcp.autorcvbufmax=16777216
net.inet.tcp.autosndbufmax=16777216
net.inet.tcp.rfc1323=1
net.inet.tcp.sack=1
net.inet.tcp.mssdflt=1440
net.inet.tcp.delayed_ack=3
EOF
# Note: On recent macOS versions, /etc/sysctl.conf may not be read automatically
# Use a LaunchDaemon to apply settings at boot
永続的な設定のための LaunchDaemon の作成
# Create /Library/LaunchDaemons/com.local.sysctl.plist
sudo tee /Library/LaunchDaemons/com.local.sysctl.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.local.sysctl</string>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/sysctl</string>
<string>-w</string>
<string>kern.ipc.maxsockbuf=8388608</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
EOF
sudo chmod 644 /Library/LaunchDaemons/com.local.sysctl.plist
sudo launchctl load /Library/LaunchDaemons/com.local.sysctl.plist
警告:macOS Ventura (13) 以降には、システム整合性保護 (SIP) の制限があります。一部のカーネルパラメータは、sudo を使用しても変更できない場合があります。特定の環境で設定をテストします。
パフォーマンスのテストと検証
バッファのパフォーマンスをテストするためのツール
iperf3 - ネットワークパフォーマンステスト
# Server side
iperf3 -s
# Client side - test TCP throughput
iperf3 -c server_ip -t 60 -i 5 -w 16M
# Test with multiple parallel streams
iperf3 -c server_ip -P 10 -t 60
# Test UDP performance
iperf3 -c server_ip -u -b 1000M -t 60
tcpdump - TCP ウィンドウ サイズのキャプチャ
# Capture and display TCP window sizes
tcpdump -i any -n 'tcp' -vv | grep -i window
# Save capture for Wireshark analysis
tcpdump -i any -w /tmp/capture.pcap 'tcp port 443'
Wireshark 分析
バッファの問題を示す次の指標を探してください。
- TCP ゼロ ウィンドウ メッセージ
- TCPウィンドウアップデートパケット
- TCP ウィンドウの完全な通知
- 低い RTT での高い再送信率
システム監視
# Linux - Monitor network buffer statistics
watch -n 1 'cat /proc/net/sockstat'
watch -n 1 'ss -tm | grep -i mem'
# Check for drops
netstat -s | grep -i drop
# Windows - Monitor TCP statistics
netstat -e 1
# macOS - Monitor network statistics
netstat -s -p tcp
帯域幅遅延積 (BDP) の計算
ネットワークに最適なバッファ サイズを決定するには、帯域幅と遅延の積を計算します。
BDP = Bandwidth (bits/sec) × RTT (seconds)
Example for 10 Gigabit Ethernet with 50ms RTT:
BDP = 10,000,000,000 × 0.050 = 500,000,000 bits = 62.5 MB
Buffer Size = BDP × 2 (for bidirectional traffic and headroom)
Buffer Size = 62.5 MB × 2 = 125 MB
This is why modern settings recommend 128MB maximum buffers.
ワークロード固有の推奨事項
| ワークロードの種類 |
推奨されるバッファサイズ |
主要なパラメータ |
| Web サーバー (低遅延) |
4~16MB |
バッファが少なく、接続数が多く、応答が速い |
| データベースサーバー |
16~32MB |
適度なバッファー、安定したスループット |
| ファイル転送・バックアップ |
64~128MB |
最大バッファー、高スループット優先 |
| ビデオストリーミング |
32~64MB |
大規模なバッファ、安定した配信速度 |
| HPC / データセンター |
128~256MB |
最大バッファ、特殊な輻輳制御 |
| ワイヤレス / モバイル |
2~8MB |
保守的なバッファ、可変レイテンシの処理 |
よくある間違いと落とし穴
避けるべき間違い
-
オーバーバッファリング:バッファーが大きすぎるとバッファーの肥大化が発生し、レイテンシが増加する可能性があります
-
メモリ制約を無視する:バッファが大きいと接続数が増加します。 10,000 の接続と 128MB のバッファを持つサーバーには 1.25TB の RAM が必要です
-
理由なく自動チューニングを無効にする:最新の OS の自動チューニングは通常、静的な設定よりも優れています
-
変更後にテストを行わない:実際のワークロードでパフォーマンスの向上を常に検証する
-
NIC バッファを忘れる:リングバッファの枯渇はソケットバッファとは独立して発生する可能性があります
-
一貫性のない設定:クライアントとサーバーには互換性のあるバッファ構成が必要です
-
輻輳制御を無視する:BBR と CUBIC は古いアルゴリズムよりも大幅に優れています
トラブルシューティングのワークフロー
-
ベースラインを確立する:iperf3 または同様のツールを使用して現在のパフォーマンスを測定する
-
パケットをキャプチャします。tcpdump/Wireshark を使用して TCP ウィンドウの動作を識別する
-
システム統計を確認します。ドロップ、バッファの枯渇、再送信を探す
-
BDP を計算します。理論的に最適なバッファ サイズを決定する
-
増分変更を適用します。一度にすべてを変更しないでください
-
テストと検証:実際のパフォーマンスの向上を測定する
-
経時的に監視します:負荷が変動しても設定が最適に保たれるようにする
参考文献と詳細情報
- RFC 1323 - 高性能のための TCP 拡張機能 (ウィンドウ スケーリング)
- RFC 2018 - TCP 選択的確認応答オプション
- RFC 6928 - TCP の初期ウィンドウの増加
- RFC 8312 - CUBIC 輻輳制御アルゴリズム
- BBR 輻輳制御 (Google) - https://research.google/pubs/pub45646/
- Linux カーネルのドキュメント - networking/ip-sysctl.txt
- Windows TCP/IP パフォーマンス チューニング ガイド (Microsoft)
- ESnet ネットワーク チューニング ガイド - https://fasterdata.es.net/
結論
バッファの枯渇は、ネットワーク関連と思われるパフォーマンスの問題の一般的な根本原因です。 2009 年の 128KB の制限から今日の 128MB の容量までのバッファ サイズの進化を理解することで、ネットワーク エンジニアはこれらの問題を迅速に特定して解決できます。
重要なポイント:
- 最新のシステムには、従来の (2009 年) 構成よりも大幅に大きなバッファが必要です
- 特定のネットワーク条件に応じて BDP を常に計算します
- 利用可能な場合は OS 自動チューニング機能を使用します (Windows、最新の Linux)
- 変更を検証するための監視とテスト
- チューニング時にワークロード固有の要件を考慮する
覚えておいてください: TCP ゼロ ウィンドウを示すパケット分析によって明らかになった「ネットワークの問題」は、実際にはホスト システムのリソースの問題です。バッファを適切に調整すると、これらの誤った診断を排除し、最適なパフォーマンスを達成できます。
最終更新日: 2026 年 2 月 2 日
著者: Baud9600 技術チーム