Оптимизация на Linux за обработка на 1.2 милиона JSON заявки в секунда

Публикувано е подробно ръководство за настройване на Linux среда с цел максимална производителност при обработка на HTTP заявки. Предложените методи увеличиха производителността на JSON обработвача, основан на библиотеката libreactor в Amazon EC2 (4 vCPU) от 224 000 API заявки в секунда при стандартни настройки на Amazon Linux 2 с ядро 4.14 до 1.2 милиона заявки в секунда след оптимизация (повишение от 436%), както и намалиха закъсненията при обработка на заявки с 79%. Предложените методи не са специфични за libreactor и работят с други HTTP сървъри, включително nginx, Actix, Netty и Node.js (libreactor беше използван в тестовете, тъй като решението на неговата база показа най-добра производителност).

Основни оптимизации:

• Оптимизация на кода на libreactor. Като основа беше използван вариант R18 от Techempower, който беше подобрен чрез премахване на кода за ограничаване на броя използвани CPU ядра (оптимизацията позволи ускорение с 25-27%), компилиране в GCC с опции "-O3" (повишение от 5-10%) и "-march-native" (5-10%), замяна на извикванията на read/write с recv/send (5-10%) и намаляване на накладните разходи при използване на pthreads (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 Асинхронен Abort) — 6%. Настройките за защита от атаки L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass и SRBDS останаха без промяна, тъй като не повлияха на производителността, тъй като не се пресичаха с тестваната конфигурация (например, специфични за KVM, вложена виртуализация и други CPU модели).
• Изключване на механизмите за одит и блокиране на системните повици с командата "auditctl -a never,task" и задаване на опцията "—security-opt seccomp=unconfined" при стартиране на Docker контейнера. Общото повишение на производителността беше 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 Pinning), така и чрез закрепване на мрежовите обработчици на ядрото (Receive Side Scaling). Например, извършено е изключване на 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.
• Оптимизация на обработката на прекъсвания и използване на полинг (polling). Включването на режима adaptive-rx в драйвера ENA и манипулациите със 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 върху производителността е в анализа на трафика с използване на raw-сокета.
• Борба с Spin Lock. Преминаването на мрежовия стек в режим „noqueue“ чрез sysctl „net.core.default_qdisc=noqueue“ и „tc qdisc replace dev eth0 root mq“ доведе до увеличаване на производителността с 2%, а пропускната способност нарасна от 1.12M req/s до 1.15M req/s.
• Финалните малки оптимизации, като деактивиране на GRO (Generic Receive Offload) с командата «ethtool -K eth0 gro off» и смяна на алгоритъма за контрол на задръстванията от cubic на reno с помощта на sysctl «net.ipv4.tcp_congestion_control=reno». Общото увеличение на производителността е 4%. Пропускателната способност се увеличи от 1.15M req/s до 1.2M req/s.

В допълнение на приложените оптимизации, статията разглежда и методи, които не доведоха до очакван растеж на производителността. Например, се оказаха неефективни:

• Отделният старт на libreactor не се различаваше по производителност от старта в контейнер. Нямаше влияние от смяната на writev с send, увеличаването на maxevents в epoll_wait, експериментите с версиите и флаговете на 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 включването на режимите Offload (segmentation, scatter-gather, rx/tx checksum), компилацията с флаг «-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

  Източник: opennet.ru