サーバーと仮想マシン

高パケット負荷に対するサーバー・ネットワーク・バッファのチューニング

パケット負荷が高いときは、一貫したネットワークバッファのチューニングに頼っています。なぜなら、カーネル、ソケット、NICのバッファを密接にマッチさせることで、応答時間を短縮し、フレームの損失を避けることができるからです。キュー・ドロップ、再送、PPSピークの測定値を使って、バッファ・サイズ、TCPウィンドウ、キューを、バーストがインターセプトされ、レイテンシが確実に低く保たれるように設定します。.

中心点

バッファサイズ 負荷プロファイルごとに動的に適応
キュー戦略 RX/TXコントロール用
TCPスタック 最新のアルゴリズムで操作する
オフロード およびIRQ分配
モニタリング 意思決定の基礎として

バッファがパフォーマンスを決める理由

帯域幅が広いだけで十分なことはほとんどない。 キュー とソケットのリミットは、リンクよりも早くリミットを設定することが多い。パケットがバーストで到着する場合、カーネルがそれらを素早くスタックに転送するように、十分な大きさの受信バッファと送信バッファでそれらをインターセプトする。小さすぎるバッファは不必要な 再送信 やタイムアウトが発生し、使用可能なPPS容量が大幅に減少する。一方、オーバーサイズのバッファはバッファブロート、つまりCPUや回線に余裕があるにもかかわらず、さらに遅延が発生することになる。設定の基本をコンパクトに説明し、詳細は以下を参照していただきたい。ソケットバッファを理解する, というのも、受信と送信の応答時間を決定するのは、まさにこの調整ネジだからだ。.

負荷プロファイルとモニタリングの賢明な活用

価値を調整する前に、私はハードデータを収集する。指標同時接続、1秒あたりのパケット数、キューのドロップ、再送、CPUソフトIRQ時間。カーブから、ボトルネックがRXパス、TXパス、TCPハンドシェイク、アプリケーションのいずれにあるかを読み取ることができる。NICがCPUリザーブをフルに使った状態でドロップを示した場合、受信キューが小さすぎるか、割り込みの分散が好ましくないことを指摘します。インターフェイスエラーを伴わない再送が多い場合は、TCPスタック、輻輳制御、バッファのスモールオブジェクトをチェックします。これらが症状が明確であれば、全面的にメモリーを増やすのではなく、特定のカーネルパラメーターを用いて次のステップに進む価値がある。.

効果のあるLinuxパラメータ

ピーク時の負荷については、集中管理された カーネル値 を適度に上方修正し、レイテンシを検証する。スタックがダイナミックに成長できるように、最大値とオートチューニングのトリプル（rmem/wmem）の両方を調整するようにしている。ソケットとネットワークインターフェースのバックログサイズは、ユーザーランドが短時間ブロックした場合のドロップを防ぐ。接続が適切に切れるように、ワークロードごとにタイムアウト値を短くしたり伸ばしたりしている。以下の表は、私がテストフィールドで実際のパターンと比較し、運用中に測定した開始点を示している。.

パラメータ	効果	開始値	ヒント
net.core.rmem_max	マックスだ。. RXバッファソケットあたり	16M-32M	小包装が多い場合は高めを選択
net.core.wmem_max	マックスだ。. TXバッファソケットあたり	16M-32M	クライアントからのAckが遅れる
net.ipv4.tcp_rmem	カー・チューニング RX [最小/最大］	4096 87380 33554432	最大マッチング数 rmem_max
net.ipv4.tcp_wmem	カー・チューニング TX [最小/最大］	4096 65536 33554432	最大マッチング数 wmem_max
net.core.netdev_max_backlog	カーネルバックログ RX用	8192–65536	RXバーストの決め手
net.ipv4.tcp_fin_timeout	期間フィン州	15-30	少ないTIME_WAIT占有率
net.ipv4.tcp_congestion_control	のアルゴリズム輻輳制御	bbr/キュービック	RTT/PPSに従った検査

ネットワーク・インターフェースでのキュー管理

NICのパスでは、最初に 受け取る- なぜなら、RXリングがフルになると即座にドロップにつながるからである。最近のドライバでは、CPUコアごとに複数のRX/TXキューを持つことができるため、並列性が高い場合でもレイテンシが平滑化される。私は、リングサイズを拡張しすぎないようにし、GRO/LROが作業負荷に合っているかどうかをチェックする。小さなパケットと低レイテンシーが重要な場合は、過剰な合体処理を無効にしたり、より厳しい割り込みタイマーを設定したりします。より深く掘り下げたい場合は、以下を参照してほしい。受信キューと送信キュー日常生活における限界、リング、合体効果をうまく分類している。.

TCPスタックの微調整

多くのセッションが同時に進行することで、調和の取れたセッションになる。 ウィンドウサイズ なぜなら、小さすぎるウィンドウはRTTプロダクトを利用しないからです。私は一貫してウィンドウのスケーリングを有効にし、ネットワークパスに応じてbbrまたはcubicを選択し、再送レートとグッドプットを検証する。適度なキープアライブ間隔を持つ持続的接続は、3ウェイハンドシェイクのオーバーヘッドを顕著に減少させる。また、ACKの遅延、初期輻輳ウィンドウ、SYNバックログにも注意を払い、ピーク時でもサーバーが許容できるようにします。微調整の簡単な紹介は TCPウィンドウのスケーリング, これは、RTT、帯域幅、ソケットバッファの間のダイナミクスを目に見えるものにする。.

ハードウェア・オフロードとCPU分散

スタックから離れ、私は創造する オフロード NICのチェックサム、TSO/TSO6、UFO、GRO、GSO は、パケットあたりの CPU 作業を軽減します。ミニフレームを使用するワークロードでは、大きなアグリゲーションがレイテンシを顕著に増加させる可能性があるため、私はGRO/GSOを厳密にチェックします。RSS、RPS、RFSは、RXストリームをコアに均等に分配し、ソフトIRQホットスポットを排除する。私は、IRQをCPUセットに適切に固定し、ユーザーランドワーカーをデータストリームの近くに保つ。これにより アロケーション スケジューラーの負担を軽減し、応答時間の一貫性を高める。.

典型的な作業負荷に対するチューニング

多くの小規模なウェブサイトを持つ古典的なウェブサイトの場合 対象物 私は低レイテンシー、適度なRX/TXリング、無駄のないキープアライブ値に重点を置いている。APIバックエンドは、短いタイムアウト、よりアグレッシブなSYNバックログ、ソケットバッファの信頼性の高い自動チューニングによって恩恵を受ける。ライブストリーミングでは、高い送信バッファ、安定したTXリング、中程度のRTT用にカスタマイズされた輻輳制御が必要です。ゲームサーバーは、最大データレートの代わりに、タイトなバッファ、タイトな合体タイマー、可能な限り低いキューイング遅延を必要とします。CDNノードは、大きなウィンドウを実行しつつ、AQMや厳格なキュー規律によってバッファブロートを制限することで、スループットとレイテンシーのバランスをとっています。.

反復的アプローチと負荷テスト

でパラメータを変更する。 ステップ そして各ラウンドの後に再現可能な負荷テストをセットアップする。これにより、netdev_max_backlogとrmem_maxのどちらがより大きな効果をもたらすかを認識することができます。その後、中央値とP95のレイテンシー、PPS、ドロップ、再送信を比較し、最適な組み合わせを生産的に展開します。短いスパイクは連続的な負荷とは異なる限界を示すので、一時的なピークは別にチェックします。この規律正しい 手続き メモリ要件の増加やタイムアウトの遅延といった副作用を防ぐ。.

パフォーマンスの罠を避ける

最も一般的な罠はこう呼ばれる。 バッファブロート寛大すぎるバッファはドロップを隠すが、待ち時間を大幅に増加させる。そのため、特にHTMLフラグメントやJSONのような小さなリプライについては、Goodputだけでなく、待ち時間のターゲットに重点を置いています。また、接続が確立されたときにバーストがキャンセルされないように、SYNクッキーとバックログ制限にも注意を払っています。過度の割り込み合体は、ベンチマークでは良い数字に見えますが、現実にはユーザーは遅延を感じます。の制限を超えるような人は キュー リング、バックログ、ドロップの関係を理解したければ、多くの実践的なレポートにあるように、それらのつながりを見てみるのが一番だ。.

キャッシュとキープアライブとの相互作用

ネットワーク・チューニング効果キャッシュ、圧縮、接続の再利用に同時に取り組んだときだけです。Timme Hostingは、ブラウザのキャッシュ、GZIP、およびキープアライブ時間の延長の効果を強調しており、これは測定ではっきりとわかります。Raidboxesは、CPUのボトルネックのためにバッファが空にならないように、十分なサーバーリソースが基礎となることを思い出させてくれます。Hosttechは、負荷が高すぎる場合に適用される制限を指摘し、最適化または性能の向上を要求している。全体として、TCPの微調整、バッファの設定、アプリケーションの最適化を組み合わせることで、パフォーマンスが顕著に向上します。短い同時アクセス時の応答時間。.

実用限界値と測定ポイント

手始めに私が目指しているのは rmem_max netdev_max_backlogは16kから64kのエントリーを選択し、NICのRX/TXリングはドライバの推奨に従ってスケーリングする。lspci, ethtool -g and -k で、どのオフロードとリング・サイズが利用可能かをチェックする。SYNバックログについては、単に上限値を利用するのではなく、アプリケーションの実際の受け入れスループットに対応する値を設定する。以下は依然として重要である。測定各変更の後、レイテンシ・パーセンタイル、PPS、ドロップ、SoftIRQ負荷、アプリのエラーコードをコンテキストで収集する。.

小区画と大区画の詳細

小包装の挑戦 ピーピーエス-そのため、私は合体を注意深く減らし、IRQ配分をシャープにしている。大きなパケットは、ターゲットMTUを超えず、フラグメンテーションのリスクがない限り、TSO/GSOの恩恵を受ける。負荷が混在している場合、私は中間の方法を見つけます：適度なバッファ、適応的合体、RTTが変化してもきれいに動作する輻輳制御です。TCP_NODELAYはレイテンシが重要なフローに選択的に使用し、バルク転送にはバンドルすることを好む。この差別化された治療は、どの負荷パターンもインスタンス全体を支配しないことを保証する。.

慎重にコンフィギュレーションを展開する

実際のところ、私は新しい設定まず、ステージング・ノードで現実的なテストを行います。その後、徐々に本番サーバーでアクティベートし、テレメトリーを注視します。待機時間や再送信が意図せず増えてしまった場合に備えて、ロールバックプランを用意しています。スクリプト化されたプレイブックにパラメーターを集め、すべての変更が追跡できるようにしています。こうして リスク そして、驚きを引き起こすことなく、測定可能な利益を達成する。.

箇条書きのないチェックリスト

私はいつも透明なものから始める。 ターゲット レイテンシとスループットについて、PPSの目標値と許容可能なエラーレートを定義する。その後、実際の値を測定し、NIC、カーネルのバックログ、ソケットバッファ、TCPスタックのボトルネックを特定します。その後、適度な開始値を設定し、それを文書化し、一定のシナリオでA/B負荷テストを実施します。その後、パーセンタイルとドロップを検査し、スモールステップで調整し、テストを繰り返します。最後に、最適な値をsysctlとethtoolプロファイルに恒久的に固定する。 一貫性 は保証されたままだ。.

VMとコンテナでの操作

仮想化環境でも同じように調整するが、特に注意するのは、次のことだ。 ヴァーチオ/ホスト-パスのコストとホストとゲスト間のボトルネックの可能性。私は複数のキューを持つ準仮想化ドライバ（virtio-net）を好み、vhost-netを介してハイパーバイザー上でオフロードを有効にします。レイテンシが重要な場合は SR-IOV コピーコストとコンテキスト・スイッチングを削減するためである。コンテナはカーネルとNICの設定を継承するが、以下のような制限がある。 somaxconn, ユーザーランドのバーストピークがネームスペースのエッジで失敗しないように、ポッド/サービスごとにオープンファイルとcgroupバジェットを適切に設定します。重要: ホスト上のRX/TXリングとIRQアフィニティは、ゲストシステムの配置と一致させる必要があります。.

NUMA、IRQアフィニティ、ビジーポーリング

マルチソケット・サーバーでは、私はデータを NUMAローカル私は、NICのRSSキューを、アプリケーション・プロセスが実行されているのと同じNUMAドメインのコアにバインドしている。RPS/RFSとXPSは、キャッシュヒットを増加させ、ソフトIRQホットスポットを減少させるフロー・アフィニティ・パスを制御する。私は固定IRQマスクを作成し、irqbalanceが限られた範囲で介入することだけを許可している。レイテンシーを極端に下げるには ビジー・ポーリング (net.core.busy_read/busy_poll)は、ウェイクアップを節約できるため、いくつかのソケットで選択的に使用する。さらに、net.core.netdev_budgetとnet.core.netdev_budget_usecsは、NAPIポーリングごとにどれだけの作業が行われるかに影響する。RXバーストがスタックせず、他のタスクがCPUを確保できるように、慎重に調整している。.

MTU、MSS、パスMTUの検出

クリーン エムティーユー-ジャンボフレームを有効にする前に、ホスト、スイッチ、アップストリームを調整する。フラグメントが発生したり、PMTUディスカバリーがブロックされたりすると、再送とレイテンシが増加する。そのため、MSSクランピングをパスに合わせて設定し、クリティカルなルートのDFフラグをチェックします。混合トラフィック（VPN、オーバーレイネットワーク）については、オーバーヘッドを計算し、実効MTUを一定に保つことで、GRO/TSOもGSOもつまずかないようにしている。キューイング遅延が支配的でマイクロバッチが望ましくない場合、小さい MTU は WAN シナリオでも役立ちます。.

UDP/QUICおよび非TCPワークロード

すべての負荷がTCPというわけではない。 UDP 再送がスタックで欠落しているので、rmem/wmemとソケット・バッファをより寛大にし、NICのUDP-GRO/GSOオプションをチェックする。QUICについては、キューイング遅延が少ないこと、タイミングが安定していること、そして必要であれば、次のことに注意している。. ECN, 最近の実装はクリーンなシグナリングに反応している。UDPはバックログを受け入れないので、RXリング、ネットデブのバックログ、RSS経由の公平な配信に重点を置いている。テレメトリ花火（syslog、メトリクスプッシュ）については、制御トラフィックがユーザーデータを置き換えないように、送信側でスロットルをかけるか、優先キューを使う。.

アクティブキュー管理、qディスク、ペーシング

宛先 バッファブロート これを系統的に回避するために、私はAQMを備えたqdisc（CoDelベースの亜種など）や、フローを分離してペース配分するFQベースのディシプリンに頼っている。BBRや最新のキュービックと組み合わせることで、不必要にスループットを低下させることなく、バーストをスムーズにすることができる。重要なのは、qdiscレイヤーをハードウェアに逆らわせないことです：NICがすでに大きく合体していたり、オフロードをバンドルしている場合、私は保守的なAQMパラメータを選択し、ハードウェアのキューが実際のボトルネックになっていないことを確認します。優先順位付けされたサービス（例えばコントロールパス）については、レイテンシの厳しい小さなバンドが役に立ちます。.

観測可能性を深める

古典的なカウンターに加え、私が頼りにしているのは エスツール (リング、ドロップス、コアレスティング・スタッツ）、, ss (ソケットテレメトリー）、, エヌスタット (IP/TCPエラー）、, ドロップウオッチ (パケットはどこで失われるのか?)とターゲットを絞った eBPF プローブ。アプリケーションのメトリクスとカーネルの値を比較します。NICエラーなしで再送が増加した場合、その原因は多くの場合、輻輳パスまたは上記のタイムアウトの不具合にあります。RX、アプリタイム、TXのレイテンシ・パーセンタイルを別々に記録し、測定値を保持しています。 再現可能 (同一ペイロード、ウォームアップフェーズ、一定のランダムシード）。高い並列度のもとでは、コアあたりのSoftIRQ時間とランキューの長さを見て、スケジューリングの影響と実際のネットワークのボトルネックを分けている。.

セキュリティー、回復力、接続の衛生管理

私は、欠陥や悪意のある行動によって引き起こされる負荷のピークに対してエッジを確保する： SYNクッキー 私は、SYNバックログを現実的な寸法に保ち、アプリケーションがピークを受け入れられるかどうかをチェックする。システムが（DNATなどで）Conntrackを使用する場合は、次のように設定する。 nf_conntrack-エッジのレートリミッタとNICのハードウェアフィルタはRXリングを保護する。エッジのレートリミッタとNICのハードウェアフィルタはRXリングを保護する。同時に、I/Oピークがバッファリング作業を打ち消す可能性があるため、クリティカルパスでの高価なロギングを減らします。.

アプリケーションとソケット関連のチューニング

アプリ側では SO_REUSEPORT, リスナーをコアに分散させ、リストバックログの一貫性を somaxconn. .十分なワーカーキャパシティを持つコヒーレントなアクセプトパスは、カーネルのバックログが隠しバッファとして悪用されるのを防ぎます。待ち時間が重要な RPC については、以下のように選択的にテストします。 TCP_NODELAY, 私はバルクオブジェクトのバンドルにこだわる。TCP Fast Openは、適切なシナリオにおいて、非常に多くの短い接続に役立ちます - ただし、ミドルボックスの互換性がチェックされている場合に限ります。非常に多くの小さな書き込みを生成するサーバーは、io_uringベースのI/Oとシスコールの負荷軽減から部分的に恩恵を受ける。.

エネルギープロファイルとカーネルの詳細

注 CPU-Cステート と周波数ガバナー：深いスリープ状態はエネルギーを節約するが、ウェイクアップ時間がかかる。予測可能な負荷ピークに対しては、高性能ガバナーに切り替え、目標レイテンシーに達するまでディープCステートを制限しています。NIC側では、割り込みレートやタイマーをシフトさせる省エネ機能をチェックしている。カーネル側では、特別なアプライアンスが干渉しない限り、SACKやタイムスタンプなどのTCP機能をアクティブに保ち、クリーンなシグナリングをサポートするネットワークパスでのECNの使用をチェックする。sysctlセットをバージョン管理し、カーネル／ドライバーの状態を一貫したものに保つ。わずかなズレがオートチューニングの動作を変え、結果を歪めることがある。.

簡単にまとめると

効果的なサーバー・ネットワーク・バッファのチューニングは、ハード・ネットワーク・バッファに基づく。指標, 目標とするカーネルとTCPの設定、そしてクリーンなNICコンフィギュレーション。私は、ソケットの自動チューニング、適切なRX/TXリング、最新の輻輳制御、およびバーストピークを遮断し、応答時間を一定に保つための適切なオフロードを組み合わせています。WordPress、WooCommerce、APIを使用するホスティングシナリオでは、キャッシュ、圧縮、キープアライブとともに顕著な効果を発揮します。テストし、ログに記録し、小さなステップで繰り返すことで、より低いレイテンシでより高いPPS容量を確実に達成することができます。これにより、高負荷下でもシステムを稼動させることができます。 レスポンシブ エラーの発生頻度も低い。.