そのVPNゲートウェイはCPU律速か?まずコア別の負荷を読む
平均値は重要なスレッドを隠す。制御された転送に対してコア別の負荷を読み、経路を除外し、その後は一度の実行につき文書化された設定をひとつだけ変える。
より大きなインスタンスを買う前に、三つの限界のどれに達しているかを決める。ひとつのコアだけが満杯で他が遊んでいるなら、フローごとの暗号処理を示す。転送中にすべてのコアが飽和しているなら、総合的な処理能力を示す。CPUが低いまま再送が増えているなら、経路を示す。それぞれ最初の一手が違い、より大きなインスタンスで解決するのはひとつだけだ。
三つの限界、ひとつの表、三つの対処
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
行は段階ではなく診断として読む。大きなトンネルを一本通すゲートウェイで最も多いのは、ひとつのスレッドが100%で他が遊んでいる状態であり、そのフローの暗号化がひとつのコアで動くからである。転送中に全コアが忙しいなら、そのマシンはすでに出せる限りの仕事をしている。CPUが低いまま再送が増えるなら、プロセッサはデータを落とし続けるネットワークを待っている。
証拠の順に直す。フローをワーカーに分散させるのは一つ目に効き、二つ目には何もしない。大きなインスタンスは二つ目に効き、一つ目では金の無駄になる。MTUや損失の修正だけが三つ目に触れる。 自分がどの行にいるか分かる前に容量を買う のは、当て推量の高価な版だ。
固定されたスレッドと忙しいホストを切り分ける
コア別の使用率から始め、固定されたひとつのコアが平均値の中に隠れないようにする。転送中に一度実行すれば、負荷が平らか山があるかが分かる。どちらの形も情報になるが、山のあるプロファイルは、サンプリング窓が暗号化ではなくスケジューラの活動を捉えたことをよく意味する。
mpstat -P ALL 1 5
忙しいコアをプロセスに、次にスレッドに結びつける。下の追跡実行は親子のスレッドをまとめて保持し、デーモンが接続ごとにフォークする場合に重要だ:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10
カーネルの暗号処理はユーザー空間のプロセスカウンタには決して現れない。スレッドを単独で採取し、その見え方をプロセスの計算と比べる:
top -H -b -n 1 | head -20
ソケットのカウンタは最後に読むのは、CPUを増やしても助かるのかを決めるのがこれだからだ。CPUが平らなまま再送が増えるのはプロセッサの問題ではない。採取中も転送を動かし続け、そうしないと数値は遊んでいるマシンを語る:
ss -ti | grep -E 'retrans|cwnd|rtt'
制御された転送を二度実行する
遊んでいるカウンタは何も証明せず、無作為な端点に対するベンチマークもほとんど証明しない。ひとつのクライアント、ひとつの宛先、実行を許された代表的な転送を選び、同じ窓の中でスループットと対話的な遅延を取る。一括コピーが終わる前にゲートウェイが飽和することはあり、利用者が実際に感じるのは遅延の曲線だ。転送、クライアント数、デーモンの版を数値の横に書く。
複数の並列フローで実行を繰り返す。フローを増やすと伸びるならフローごとの窓、ひとつのコアが固定されたまま平らなら処理を示す。
そのうえで任意の作業負荷を止めて、もう一度繰り返す。同じホスト上のバックアップ、ログ転送、データベースは、トンネルと無関係な忙しい平均を作りうる。ホストが静かなのにCPUが固定されたままなら、証拠はVPNプロセスを指す。下がるなら、隣人を測っていたのであり、ゲートウェイは問題ではなかった。
ハードウェアを買う前に経路を除外する
再送の増加、輻輳窓の縮小、往復時間の増加は、いずれもプロセッサから遠ざかる方向を示す。トンネルのMTUと経路のMTUを比べ、下位のリンクに損失がないか確認し、クライアント自身の上り回線が限界でないことを確かめる。大きなゲートウェイはパケットを落とすリンクを直さず、利用者はどちらの不具合も同じ言葉で語る。再送カウンタが数分で両者を分ける。
仮想サーバーでは、提供事業者の指標をゲスト自身の指標に加える。ステールタイムは、過剰販売がゲストの内側で見える形であり、ゲスト内の調整では取り除けない。ゲストのカウンタはホストを見ないので、きれいなゲストのグラフは健全なホストの証明ではない。
ひとつの変更、ひとつの測定
証拠が支える仮説を選び、支持された設定をひとつだけ変える:ワーカー数、文書化されたオフロード設定、インスタンスの大きさのいずれか。OpenVPNは処理と転送の同じ分け方について性能トラブルシューティングのガイドを公開している: OpenVPNの性能トラブルシューティング。
フラグを信じるのではなく、オフロード設定が実際に有効か確かめ、同じ転送を再実行して同条件で比べる。本当の改善と静かな午後を区別する唯一の方法だ。元に戻せるチェックポイントを残し、二つ目の変更でどれが効いたのか分からなくなるのを防ぐ。一度にひとつの変数は一日では遅く、ひと月では速い。
グラフを良く見せるために認証や暗号スイートを弱めてはいけない。CPUが症状に追従しないままなら、推測で上げるのではなく経路とアプリケーションの確認に戻る。