System Buffer Tuning - TCP and Network Performance Optimization
システムバッファのチューニング: 「ネットワークの問題」の後ろに隠された犯人
エグゼクティブ・サマリー
ネットワークエンジニアは、ネットワークインフラにTCPのウィンドウングやアプリケーションのパフォーマンスが隠されている状況に頻繁に遭遇します。 広範なパケットキャプチャ、tcpdump、およびネットワーク解析を実行した後、真のボトルネックはしばしば発見されます。 NIC(Network Interface Card)またはOSレベルのバッファをクライアントまたはサーバーシステムに排出します。
この記事では、レガシー(サーカ2009)と現在の(2025-2026)の両方のバッファ構成をLinux、Windows、およびmacOSに提供し、診断技術を使用して、重要な問題になる前にバッファの排気を識別します。
バッファ排気の一般的な症状
- パケットキャプチャのTCP Zero Windowイベント
- 低いネットワークレイテンシにもかかわらず高い送金率
- 利用できる帯域幅の下のアプリケーションスループットを大幅に下回る
- 負荷が減少したときに改善する負荷の下の性能の低下
- 同じようなハードウェア構成を渡る強烈な性能
- ソケットのエラーや「一時的に利用できなくなったリソース」メッセージ
問題の理解
TCPウィンドウスケーリング機構
TCP は、受入可能なデータ量を示す「ウィンドウサイズ」を発行するフロー制御機構を使用します。 システムバッファを埋め上げると、このウィンドウはゼロに縮小し、送信者を強制して待機します。 これはネットワークの問題として表示されますが、実際にはホストリソースの問題です。
バッファマッターの場所
- ソケットバッファ(SO SNDBUF/SO RCVBUF): Per-socket 送信と受信バッファ
- TCPの窓の緩衝: 接続の最大TCPウィンドウサイズ
- ネットワークデバイスバッファ: パケットキューイング用のNICリングバッファ
- システム全体の記憶: ネットワーキングのための全面的なメモリ割り当て
診断コマンド
Linux診断
# Check current TCP buffer settings sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem sysctl net.core.rmem_max sysctl net.core.wmem_max # 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設定(Circa 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 はバッファを受け取ります: min, default, max (バイト単位) |
| net.ipv4.tcp wmem ディレクティブ | 4096 16384 131072 | TCP 送信バッファ: min, default, max (バイト単位) |
| net.ipv4.tcp mem ディレクティブ | 196608 262144 393216 | TCPメモリページ:低圧力、高 |
| net.core.netdev max backlog の一覧 | 1000万円 | 入力キューの最大パケット |
| net.core.optmem max ディレクティブ | 10240円(税込) | ソケットごとの最高の補助バッファサイズ |
現在のLinuxの設定 (2025-2026)
| Parameter | 現在の推奨値 | Description |
|---|---|---|
| net.core.rmem_default | 16777216(16MB) | Default receive socket buffer size |
| net.core.rmem_max | 134217728 (128MB) | Maximum receive socket buffer size |
| net.core.wmem_default | 16777216 (16MB) | Default send socket buffer size |
| net.core.wmem_max | 134217728 (128MB) | Maximum send socket buffer size |
| 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) | Maximum ancillary buffer size per socket |
| net.ipv4.tcp congestion control の使い方 | バックナンバー | BBR輻輳制御(Googleのアルゴリズム) |
| net.ipv4.tcp window scaling ディレクティブ | 1 | TCP ウィンドウのスケーリングを有効にする (RFC 1323) |
| net.ipv4.tcp timestamps ディレクティブ | 1 | TCP タイムスタンプを有効にして RTT の推定を改善 |
| 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
- 接続メモリごとに: 各接続は rmem max + wmem max (128MB バッファで256MB) まで使用できます。
- 総システムの影響: 1,000 接続 × 256MB = 256GB 潜在的な使用量
- 安全な推定: 最大同時接続×256MBは、システムRAMの50%を超えるべきではありません
- 例: 64GB サーバは、最大接続数を ~125 同時並列接続に 128MB バッファで制限する必要があります。
- <16GB RAMのサーバーへの推奨: バッファを最大16-32MBに減らし、tcp memを比例して調整
Windowsの緩衝調整
レガシーのWindowsの設定(Circa 2009 - Windows Vista/7/Server 2008)
| Parameter | Legacy Value (2009) | アクセス |
|---|---|---|
| TcpWindowサイズ | 65535(64KB) | レジストリ:HKLM\System\CurrentControlSet\Services\Tcpip\Parameters |
| Tcp1323Optsの特長 | 0 (無効) | デフォルトで無効なウィンドウのスケーリング |
| デフォルト受信ウィンドウ | 8192(8KB) | デフォルトはウィンドウを受け取ります |
| デフォルトスレッドウィンドウ | 8192 (8KB) | デフォルト送信ウィンドウ |
| グローバルマックスTcpWindowSize | 65535 (64KB) | 最大 TCP ウィンドウサイズ |
| TcpNumコネクション | 16777214の特長 | 最高のTCP接続 |
現在のWindows設定(Windows 10/11/Server 2019-2025)
現代Windowsは使用します 受信ウィンドウ自動チューニング 動的にネットワーク条件に基づいて受信バッファを調整する機能。
| スタッフ | 現在の推奨設定 | Description |
|---|---|---|
| 自動チューニングレベル | ノーマル(または10GbE+の非常に実験的) | 動的受信ウィンドウの調整 |
| 受信側スケーリング(RSS) | 対応可能 | CPU間でネットワーク処理を分散 |
| Chimney オフロード | 自動(または現代のNIC上で無効) | NIC ハードウェアへの TCP オフロード |
| ネットDMA | バリアフリー | ダイレクトメモリアクセス(非推奨) |
| TCPグローバルパラメータ | 以下のコマンドを参照してください。 | システム全体のTCP設定 |
| 輻輳プロバイダ | CUBIC(またはニューレノフォールバック) | 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
レジストリTweaks(高度な - 注意を使用して)
# 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)
macOSバッファチューニング
レガシーmacOS設定(Circa 2009 - Mac OS X 10.5/10.6)
| Parameter | Legacy Value (2009) | Description |
|---|---|---|
| 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 (disabled) | TCPウィンドウのスケーリング |
現在の macOS 設定 (macOS 12-15 Monterey を Sequoia 経由で)
| Parameter | Current Recommended Value | Description |
|---|---|---|
| kern.ipc.maxsockbuf | 8388608 (8メガバイト) | Maximum socket buffer size |
| net.inet.tcp.sendspace | 131072 (128KB) | Default TCP send buffer |
| net.inet.tcp.recvspace | 131072 (128KB) | Default TCP receive buffer |
| net.inet.tcp.autorcvbufmax | 16777216 (16MB) | Maximum auto-tuned receive buffer |
| net.inet.tcp.autosndbufmax | 16777216 (16MB) | Maximum auto-tuned send buffer |
| net.inet.tcp.rfc1323 | 1 (有効) | TCP ウィンドウのスケーリングを有効にする |
| net.inet.tcp.sack(ネッツ) | 1 (enabled) | Enable Selective Acknowledgment |
| net.inet.tcp.mssdfltの | 1440の | デフォルトのTCP最大セグメントサイズ |
| net.inet.tcp.delayed 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 <持続的な設定のための LaunchDaemon の作成
# Create /Library/LaunchDaemons/com.local.sysctl.plist sudo tee /Library/LaunchDaemons/com.local.sysctl.plist <EOF sudo chmod 644 /Library/LaunchDaemons/com.local.sysctl.plist sudo launchctl load /Library/LaunchDaemons/com.local.sysctl.plist Label com.local.sysctl ProgramArguments /usr/sbin/sysctl -w kern.ipc.maxsockbuf=8388608 RunAtLoad 警告: 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'
ワイヤーサメ分析
バッファの問題のこれらの指標を探します。
- TCPゼロウィンドウメッセージ
- TCP Window 更新パケット
- TCP Window 完全な通知
- 低い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)計算
ネットワークに最適なバッファサイズを決定するには、Bandwidth-Delay Products を計算します。
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.
ワークロード固有の推奨事項
| ワークロードのタイプ | 推奨バッファサイズ | 主変数 |
|---|---|---|
| ウェブサーバー(低レイテンシ) | 4-16 MBの | バッファを下げる、より多くの接続、高速応答 |
| データベース サーバー | 16-32マイル | モデレートバッファ、一貫したスループット |
| ファイル転送/バックアップ | 64-128メガバイト | 最大バッファ、高スループット優先度 |
| ビデオストリーミング | 32-64メガバイト | 大きい緩衝、一貫した配達率 |
| HPC/データセンター | 128-256メガバイト | 最高の緩衝、専門にされた輻輳制御 |
| ワイヤレス/モバイル | 2~8 MB | 保存バッファ、可変レイテンシ処理 |
よくある間違いと落札
避けるべき間違い
- 過剰緩衝: 過剰に大きなバッファは、バッファブラート、レイテンシの増加を引き起こす可能性があります
- メモリ制約の無視: 接続数により多重なる大型バッファ。10,000接続と128MBバッファのサーバーは、1.25TBのRAMを必要とします。
- 理由なしでオートチューニングを無効にします。 現代のOSの自動調整は通常、静的な設定よりも優れています
- 変更後にテストしない: 実際のワークロードによるパフォーマンスの改善を常に検証
- NIC バッファの取得: リング バッファの排気はソケットの緩衝とは独立して起こることができます
- 継続的な設定: クライアントとサーバーは、互換性のあるバッファ構成を持っている必要があります
- 無視の混雑制御: BBRとCUBICは、古いアルゴリズムよりも大幅に優れています
ワークフローのトラブルシューティング
- ベースラインの確立: iperf3 または同様のツールで現在のパフォーマンスを測定する
- パケットをキャプチャ: TCP ウィンドウの動作を識別するために tcpdump/Wireshark を使用する
- システム統計情報をチェック: 落下、緩衝排気、再伝達のために見て下さい
- BDPの計算: 理論的に最適なバッファサイズを決定する
- 増分変更を適用します。 一度にすべてを変更しないでください
- 試験と検証: 実際の性能改善の測定
- 時間の上のモニター: 異なる負荷の下で設定が最適であることを確認してください
参照および更に読むこと
- RFC 1323 - 高性能(窓のスケーリング)のためのTCP延長
- RFC 2018 - TCP 選択的承認オプション
- RFC 6928 - TCP の初期ウィンドウを増加させる
- RFC 8312 - CUBIC 混雑制御アルゴリズム
- BBR混雑制御(Google) - https://research.google/pubs/pub45646/
- Linuxカーネルドキュメント - ネットワーク/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 テクニカルチーム