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

Публикувано е подробно ръководство за настройка на Linux средата за постигане на максимална производителност за обработка на HTTP заявки. Предложените методи позволиха да се увеличи производителността на JSON процесора, базиран на библиотеката libreactor в средата на Amazon EC2 (4 vCPU) от 224 хиляди 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%), заменяйки извикванията за четене/запис с 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 Asynchronous Abort) - 6%. Настройките за защита срещу L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass и SRBDS атаки бяха оставени непроменени, което не се отрази на производителността, тъй като не се пресичаха с тестваната конфигурация (например, специфични за KVM, вложени виртуализация и други CPU модели).
• Деактивиране на механизмите за одит и блокиране на системни повиквания с помощта на командата "auditctl -a never,task" и указване на опцията "--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.
• Намалена миграция на манипулатори между различни процесорни ядра за подобряване на ефективността на използването на кеша на процесора. Оптимизацията беше извършена както на нивото на свързване на процесите на libreactor към ядрата на процесора (CPU Pinning), така и чрез фиксиране на мрежови манипулатори на ядрото (Receive Side Scaling). Например irqbalance беше деактивиран и афинитетът на опашката към процесора беше изрично зададен в /proc/irq/$IRQ/smp_affinity_list. За да се използва едно и също процесорно ядро ​​за обработка на процеса на libreactor и мрежовата опашка от входящи пакети, се използва персонализиран манипулатор на BPF, свързан чрез задаване на флага SO_ATTACH_REUSEPORT_CBPF при създаването на сокета. За да се обвържат опашки от изходящи пакети към процесора, настройките /sys/class/net/eth0/queues/tx-/xps_cpus са променени. Общото увеличение на производителността беше 38%, а пропускателната способност се увеличи от 603k req/s на 834k req/s.
• Оптимизиране на обработката на прекъсванията и използването на анкетиране. Активирането на режима 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 влияе върху производителността, е в анализа на трафика, използвайки необработен сокет.
• Борба със 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“ и замяна на кубичния алгоритъм за контрол на задръстванията с reno, използвайки sysctl „net.ipv4.tcp_congestion_control=reno“. Общото увеличение на производителността е 4%. Пропускателната способност е увеличена от 1.15M req/s на 1.2M req/s.

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

• Стартирането на libreactor отделно не се различава по производителност от работата му в контейнер. Замяната на writev с изпращане, увеличаването на 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 активирането на режими на разтоварване (сегментиране, събиране на разсейване, контролна сума на 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

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