Linux の最適化により 1.2 秒あたり XNUMX 万の JSON リクエストを処理

HTTP リクエストの処理で最大のパフォーマンスを達成するための Linux 環境のチューニングに関する詳細なガイドが公開されています。 提案された方法により、Amazon EC2 環境 (4 vCPU) の libreactor ライブラリに基づく JSON プロセッサのパフォーマンスを、カーネル 224 を使用した Amazon Linux 2 の標準設定で 4.14 秒あたり 1.2 API リクエストから 436 万リクエスト/秒に向上させることができました。最適化後 79 秒 (XNUMX% 増加)、リクエスト処理の遅延も XNUMX% 減少しました。 提案された方法は libreactor に固有のものではなく、nginx、Actix、Netty、Node.js などの他の http サーバーを使用する場合にも機能します (テストでは libreactor をベースにしたソリューションの方がパフォーマンスが優れていたため、libreactor が使用されました)。

基本的な最適化:

• リブレアクターコードの最適化。 Techempower キットの R18 オプションがベースとして使用され、使用される CPU コアの数を制限するコードを削除して (最適化により作業が 25 ～ 27% 高速化されました)、「-O3」 オプションを使用して GCC でアセンブルすることで改善されました。 (5-10% の増加) および "-march-native" (5-10%)、読み取り/書き込み呼び出しを recv/send に置き換え (5-10%)、pthread 使用時のオーバーヘッドを削減 (2-3%) 。 コード最適化後の全体的なパフォーマンスは 55% 向上し、スループットは 224k req/s から 347k req/s に増加しました。
• 投機的実行の脆弱性に対する保護を無効にします。 カーネルをロードするときにパラメーター「nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off」を使用すると、パフォーマンスが 28% 向上し、スループットが 347k req/s から 446k req/s に増加しました。 これとは別に、パラメータ「nospectre_v1」（Spectre v1 + SWAPGS からの保護）からの増加は 1 ～ 2%、「nospectre_v2」（Spectre v2 からの保護） - 15 ～ 20%、「pti=off」（Spectre v3/Meltdown）でした。 - 6 %、「mds=off tsx_async_abort=off」 (MDS/Zombieload および TSX 非同期中止) - 6%。 L1TF/フォアシャドウ (l1tf=flush)、iTLB マルチヒット、投機的ストア バイパス、および SRBDS 攻撃に対する保護の設定は変更されず、テストされた構成 (KVM 固有、ネストされた構成など) と交差しなかったため、パフォーマンスには影響しませんでした。仮想化などの CPU モデル)。
• 「auditctl -a Never,task」コマンドを使用し、Docker コンテナーの起動時に「--security-opt seccomp=unconfined」オプションを指定して、監査およびシステム コール ブロック メカニズムを無効にします。 全体的なパフォーマンスは 11% 向上し、スループットは 446k req/s から 495k req/s に増加しました。
• 関連するカーネル モジュールをアンロードして、iptables/netfilter を無効にします。 特定のサーバー ソリューションで使用されていないファイアウォールを無効にするという考えは、nf_hook_slow 関数の実行に 18% の時間がかかったというプロファイリング結果から判断されました。 nftables は iptables よりも効率的に動作しますが、Amazon Linux は引き続き iptables を使用することに注意してください。 iptables を無効にした後、パフォーマンスは 22% 向上し、スループットは 495k req/s から 603k req/s に増加しました。
• 異なる CPU コア間でのハンドラーの移行を削減し、プロセッサー キャッシュの使用効率を向上させました。 最適化は、libreactor プロセスを CPU コアにバインドするレベル (CPU ピンニング) と、カーネル ネットワーク ハンドラーのピンニング (受信側スケーリング) の両方のレベルで実行されました。 たとえば、irqbalance が無効になり、CPU へのキュー アフィニティが /proc/irq/$IRQ/smp_affinity_list で明示的に設定されました。 同じ CPU コアを使用して、libreactor プロセスと受信パケットのネットワーク キューを処理するには、カスタム BPF ハンドラーが使用され、ソケットの作成時に SO_ATTACH_REUSEPORT_CBPF フラグを設定することで接続されます。 送信パケットのキューを CPU にバインドするために、設定 /sys/class/net/eth0/queues/tx- が変更されました。 /xps_cpus。 全体的なパフォーマンスは 38% 向上し、スループットは 603k req/s から 834k req/s に増加しました。
• 割り込み処理とポーリングの使用の最適化。 ENA ドライバーでadaptive-rx モードを有効にし、sysctl net.core.busy_read を操作すると、パフォーマンスが 28% 向上しました (スループットは 834k req/s から 1.06M req/s に増加し、レイテンシーは 361μs から 292μs に減少しました)。
• ネットワーク スタック内で不必要なブロックを引き起こすシステム サービスを無効にします。 dhclient を無効にして IP アドレスを手動で設定すると、パフォーマンスが 6% 向上し、スループットが 1.06M req/s から 1.12M req/s に増加しました。 dhclient がパフォーマンスに影響を与える理由は、生のソケットを使用したトラフィック分析にあります。
• スピンロックとの戦い。 sysctl「net.core.default_qdisc=noqueue」および「tc qdisc replace dev eth0 root mq」を介してネットワーク スタックを「noqueue」モードに切り替えると、パフォーマンスが 2% 向上し、スループットが 1.12M req/s から 1.15M req/s に増加しました。要求/秒
• コマンド「ethtool -K eth0 gro off」を使用して GRO (Generic Receive Offload) を無効にし、sysctl「net.ipv4.tcp_congestion_control=reno」を使用してキュービック輻輳制御アルゴリズムを reno に置き換えるなど、最後のマイナーな最適化。 全体的な生産性の向上は 4% でした。 スループットは 1.15 万要求/秒から 1.2 万要求/秒に増加しました。

この記事では、効果があった最適化に加えて、期待されたパフォーマンスの向上につながらなかった方法についても説明します。 たとえば、次のようなことは効果がないことが判明しました。

• libreactor を個別に実行しても、コンテナー内で実行する場合とパフォーマンスに違いはありませんでした。 writev を send に置き換え、epoll_wait の maxevents を増やし、GCC のバージョンとフラグを試しても効果はありませんでした (効果は「-O3」および「-march-native」フラグでのみ顕著でした)。
• Linux カーネルをバージョン 4.19 および 5.4 にアップグレードし、SCHED_FIFO および SCHED_RR スケジューラーを使用し、sysctl kernel.sched_min_granularity_ns、kernel.sched_wakeup_granularity_ns、transparent_hugepages=never、skew_tick=1、および Clocksource=tsc を操作しても、パフォーマンスには影響しませんでした。
• ENA ドライバーでは、オフロード モード (セグメンテーション、スキャッターギャザー、rx/tx チェックサム) を有効にし、「-O3」フラグを使用してビルドし、ena.rx_queue_size および ena.force_large_llq_header パラメーターを使用しても効果はありませんでした。
• ネットワーク スタックを変更してもパフォーマンスは向上しませんでした。
  • IPv6 を無効にする: ipv6.disable=1
  • VLAN を無効にする: modprobe -rv 8021q
  • パッケージのソースチェックを無効にする
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1 (マイナスの影響)
  • net.ipv4.tcp_sack = 0
  • net.ipv4.tcp_dsack=0
  • net.ipv4.tcp_mem/tcp_wmem/tcp_rmem
  • net.core.netdev_budget
  • net.core.dev_weight
  • net.core.netdev_max_backlog
  • net.ipv4.tcp_slow_start_after_idle=0
  • net.ipv4.tcp_moderate_rcvbuf=0
  • net.ipv4.tcp_timestamps=0
  • net.ipv4.tcp_low_latency = 1
  • SO_PRIORITY
  • TCP_NODELAY

  出所： オープンネット.ru