より大きなインスタンスを買う前に、三つの限界のどれに達しているかを決める。ひとつのコアだけが満杯で他が遊んでいるなら、フローごとの暗号処理を示す。転送中にすべてのコアが飽和しているなら、総合的な処理能力を示す。CPUが低いまま再送が増えているなら、経路を示す。それぞれ最初の一手が違い、より大きなインスタンスで解決するのはひとつだけだ。

三つの限界、ひとつの表、三つの対処

LimitReading during a transferFirst move
Single threadone core near 100%, siblings idlespread flows across workers
Aggregate CPUevery core busy, load average climbscapacity, or less work per byte
Path or providerlow CPU, retransmits or steal time highMTU, 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が症状に追従しないままなら、推測で上げるのではなく経路とアプリケーションの確認に戻る。

関連記事