深夜2時、アラートが届いた。データベースサーバーのスループットが通常の40%まで落ち込み、レイテンシが急上昇していた。SSHでログを確認しても異常はない。top、iostat、vmstatもすべて正常。最終的にあるコマンドを実行したところ、問題がすぐに判明した——メンテナンス後にスイッチポートがリセットされた影響で、NICが1Gbps full-duplexではなく100Mbps half-duplexで動作していたのだ。そのコマンドがethtoolだった。
これは50人規模のオフィスと小規模データセンターのネットワーク管理で毎週使っているツールだ。複雑なインストールは不要で、ethtoolはほとんどのLinuxディストリビューションに標準搭載されており、ip linkやifconfigでは確認できないNICのあらゆる情報を可視化できる。
Quick Start:5分ですぐに始める
ethtoolがインストールされていない場合はインストールする:
# Debian/Ubuntu
sudo apt install ethtool
# RHEL/CentOS/Rocky Linux
sudo dnf install ethtool
NICの状態をすぐに確認する:
# まずインターフェース名を確認する
ip link show
# NICを確認する(eth0は実際の名前に置き換える:ens3, enp2s0, ...)
sudo ethtool eth0
典型的な出力例:
Settings for eth0:
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
最も重要な3行はSpeed、Duplex、Link detectedだ。本番サーバーでSpeedが100Mb/s、またはDuplexがHalfになっていたら——それはすぐに対処が必要な問題であり、放置は禁物だ。
ethtoolの出力を読み解く
SpeedとDuplex——問題を引き起こしやすいコンビ
Speedは一目でわかるが、問題を引き起こしやすいのに見落とされがちなのがDuplexだ:
- Full-duplex:データの送受信を同時に行う——現代のサーバーでは標準的なモード。
- Half-duplex:トランシーバーのように、一度に片方向しか通信できない。実効スループットは30〜50%に低下し、コリジョンが急増する。
よくあるケース:インフラチームがスイッチを交換した後、誰にも知らせずにデータベースサーバーが急に遅くなった。ethtoolで調べると、新しいスイッチポートのデフォルトがhalf-duplexになっていた。両端を1Gbps full-duplexに固定して、2分で解決した。
Auto-negotiation
Auto-negotiationはNICとスイッチ間でspeed/duplexを自動的にネゴシエートする。ほとんどの場合はそのまま有効にしておけばよい——自動で処理してくれる。ただし、古いスイッチや安価なマネージドスイッチではネゴシエーションが失敗し、ケーブルもポートも1Gbps対応なのにSpeed: 100Mb/sと表示されることがある。その場合は手動で固定するしか解決策がない。
Link detected: no
この表示が出たら——ケーブル断線、抜け、またはスイッチポートがダウンしている。物理的な問題なのにソフトウェアのデバッグに時間を費やさないようにしよう。
ethtoolの実用的なコマンド
ドライバーとファームウェアの確認
sudo ethtool -i eth0
driver: e1000e
version: 3.2.6-k
firmware-version: 3.4.4
bus-info: 0000:00:19.0
supports-statistics: yes
NICで不可解なエラーが発生した場合、まずドライバーバージョンを確認するようにしている。カーネルドライバーのアップデートだけで解決することも多く、それ以上深追いせずに済む。
ネットワークエラー統計の確認
sudo ethtool -S eth0 | grep -E "error|drop|miss|fail"
rx_errors、tx_dropped、rx_missed_errorsなどのカウンタを確認する。これらの値が継続的に増加しているなら——問題はアプリケーションではなく、ハードウェアまたはドライバーレイヤーにある。
SpeedとDuplexの設定
SpeedとDuplexを手動で固定する
auto-negotiationが正常に機能しない場合:
# 1Gbps full-duplexに固定、auto-negotiationを無効化
sudo ethtool -s eth0 speed 1000 duplex full autoneg off
# 100Mbps full-duplexに固定
sudo ethtool -s eth0 speed 100 duplex full autoneg off
# auto-negotiationを再度有効化
sudo ethtool -s eth0 autoneg on
重要:この変更はreboot後に失われる。永続化する方法は後述のTipsセクションを参照。
Wake on LANの有効化/無効化
# WoLを有効化(マジックパケット)
sudo ethtool -s eth0 wol g
# WoLを無効化(不要なサーバーの省電力化)
sudo ethtool -s eth0 wol d
NICのパフォーマンス最適化(上級編)
Ring Buffer——トラフィックバースト時にパケットの生死を決めるバッファ
リングバッファとは、カーネルが処理するまでの間パケットをキューに格納するNIC上のメモリ領域だ。多くのNICのデフォルトは256スロットしかなく——高トラフィックのサーバーではバースト時に数ミリ秒で埋まり、パケットが直接ドロップされ始める。
# 現在のリングバッファを確認
sudo ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
TX: 4096
Current hardware settings:
RX: 256
TX: 256
# リングバッファを最大値まで増加
sudo ethtool -G eth0 rx 4096 tx 4096
あるインシデントの後、データセンター内の全サーバーにこの設定を適用した。ログ集約を処理するサーバーがピーク時に突然パケットをドロップし始めたのだ。RXバッファを256から4096に増加させると——追加ハードウェアなしで問題が完全に解消された。
オフロード機能
最新世代のNICは単なるビット転送にとどまらない——CPUの代わりに多くの重い計算処理も担う。その機能群をオフロードと呼ぶ。現在有効になっている機能を確認しよう:
sudo ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
重要な機能:
- rx/tx-checksumming:NICがCPUの代わりにチェックサムを計算する——有効にすべき。
- tso(TCP Segmentation Offload):NICが大きなTCPセグメントを自動分割する——スループットが大幅に向上。
- gro(Generic Receive Offload):カーネルに渡す前に小さなパケットを結合する——割り込みを削減。
# GROが無効の場合は有効化
sudo ethtool -K eth0 gro on
# TSOを無効化(VM上のvirtual NICで必要になることがある)
sudo ethtool -K eth0 tso off
VMに関する注意:仮想化環境(KVM、VMware)では、一部のオフロード機能がスループット異常を引き起こす可能性がある。原因不明のパフォーマンス低下が見られる場合、VM上ではLROを無効化し、必要に応じてTSOも無効化することが多い。
Coalesce設定——CPU割り込みを削減する
NICにパケットが届くたびにCPUへの割り込みが発生する。毎秒数万パケットを受信するサーバーでは、このオーバーヘッドが無視できない。コアレッシングは複数のパケットを1つの割り込みにまとめ——CPUの割り込み回数を減らし、スループットを目に見えて改善する:
# 現在のcoalesce設定を確認
sudo ethtool -c eth0
# 割り込みコアレッシングを増加(CPU割り込みを削減、レイテンシはわずかに増加)
sudo ethtool -C eth0 rx-usecs 50 tx-usecs 50
知っておくべきトレードオフ:コアレッシングを高くすると→ CPU割り込みが減り、スループットは向上するが、レイテンシがわずかに増加する。バックアップやファイル転送などのスループット重視のワークロードに適している。リアルタイム処理などレイテンシ重視のワークロードでは、値を低く抑えるかデフォルトのままにしよう。
本番環境からの実践的なTips
reboot後も設定を永続化する
ethtoolによるすべての変更はreboot後に失われる。Ubuntu/Debianでnetworkd-dispatcherを使って永続化する方法:
sudo nano /etc/networkd-dispatcher/routable.d/ethtool-tuning.sh
#!/bin/bash
IFACE="eth0"
ethtool -G $IFACE rx 4096 tx 4096
ethtool -K $IFACE gro on tso on
ethtool -C $IFACE rx-usecs 50
sudo chmod +x /etc/networkd-dispatcher/routable.d/ethtool-tuning.sh
RHEL/CentOS(NetworkManager)の場合:
# /etc/sysconfig/network-scripts/ifcfg-eth0に追加
ETHTOOL_OPTS="speed 1000 duplex full autoneg off"
全NICを素早くチェックするスクリプト
新しいサーバーを引き継いだ時やメンテナンス後に即座に実行するために書いたスクリプトだ:
#!/bin/bash
# check-nic-health.sh
for iface in $(ls /sys/class/net | grep -v lo); do
echo "=== $iface ==="
speed=$(ethtool $iface 2>/dev/null | grep Speed | awk '{print $2}')
duplex=$(ethtool $iface 2>/dev/null | grep Duplex | awk '{print $2}')
link=$(ethtool $iface 2>/dev/null | grep "Link detected" | awk '{print $3}')
echo " Speed: $speed | Duplex: $duplex | Link: $link"
rx_err=$(ethtool -S $iface 2>/dev/null | grep rx_errors | awk '{print $2}')
tx_drop=$(ethtool -S $iface 2>/dev/null | grep tx_dropped | awk '{print $2}')
[ -n "$rx_err" ] && echo " RX Errors: $rx_err | TX Dropped: $tx_drop"
echo ""
done
sudo bash check-nic-health.sh
ethtoolを使うべき状況は?
- CPU/ディスク/アプリケーションはすべて正常なのにスループットが異常に低い → 直ちにspeed/duplexを確認する。
- 説明のつかないパケットロスが発生している →
ethtool -Sでエラーカウンタを確認する。 - 新しいサーバーの引き継ぎやスイッチ/ケーブルの交換後 → リンク速度とduplexを確認する。
- 高トラフィック処理サーバー(データベース、プロキシ、ログアグリゲーター)の最適化 → リングバッファとオフロードをチューニングする。
- VMで不可解なスループット低下が発生している → オフロード機能を確認・調整する。
ethtoolは毎日使うツールではないが、必要な時には——ping、ss、iperf3では見つけられない問題の核心を正確に指し示してくれる。次に深夜2時にネットワークの異常が発生して原因不明の場合、SSHでサーバーにログインした後に最初に実行するのはsudo ethtool eth0だ。

