Секундэд 1.2 сая JSON хүсэлтийг шийдвэрлэхийн тулд Линуксыг оновчтой болгож байна

HTTP хүсэлтийг боловсруулахад хамгийн их гүйцэтгэлд хүрэхийн тулд Линукс орчныг тохируулах талаар нарийвчилсан гарын авлага нийтлэгдсэн. Санал болгож буй аргууд нь Amazon EC2 орчин (4 vCPU) дахь libreactor номын санд суурилсан JSON процессорын гүйцэтгэлийг 224 цөмтэй Amazon Linux 2-ын стандарт тохиргоотой секундэд 4.14 мянган API хүсэлтээс 1.2 сая хүсэлт болгон нэмэгдүүлэх боломжтой болгосон. оновчлолын дараа хоёрдугаарт (436% -иар өссөн), мөн хүсэлтийг боловсруулахад саатал 79% -иар буурахад хүргэсэн. Санал болгож буй аргууд нь libreactor-д хамаарахгүй бөгөөд nginx, Actix, Netty болон Node.js зэрэг бусад http серверүүдийг ашиглах үед ажилладаг (түүн дээр суурилсан шийдэл нь илүү сайн гүйцэтгэлтэй байсан тул libreactor-ийг туршилтанд ашигласан).

Секундэд 1.2 сая JSON хүсэлтийг шийдвэрлэхийн тулд Линуксыг оновчтой болгож байна

Үндсэн оновчлолууд:

  • Либреакторын кодыг оновчтой болгох. Techempower иж бүрдэлээс R18 сонголтыг үндэс болгон ашигласан бөгөөд ашигласан CPU цөмийн тоог хязгаарлах кодыг устгаснаар сайжруулсан (оновчлол нь ажлыг 25-27% хурдасгах боломжийг олгосон), "-O3" сонголтоор GCC-д угсарсан. (5-10% -иар өссөн) болон "-march-native" (5-10%), унших/бичих дуудлагыг recv/send (5-10%)-аар сольж, pthreads ашиглах үед нэмэлт зардлыг (2-3%) бууруулна. . Кодыг оновчтой болгосны дараа нийт гүйцэтгэлийн өсөлт 55% байсан ба дамжуулах чадвар 224к req/s-ээс 347k req/s хүртэл нэмэгдсэн.
  • Таамаглалын гүйцэтгэлийн эмзэг байдлаас хамгаалах хамгаалалтыг идэвхгүй болгох. Цөмийг ачаалах үед “nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off” параметрүүдийг ашигласнаар гүйцэтгэл 28%-иар нэмэгдэж, дамжуулах чадвар 347к 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/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass болон SRBDS халдлагаас хамгаалах тохиргоог хэвээр үлдээсэн бөгөөд тэдгээр нь шалгагдсан тохиргоотой огтлолцоогүй (жишээлбэл, KVM-д зориулагдсан, үүрлэсэн) учир гүйцэтгэлд нөлөөлөөгүй. виртуалчлал болон бусад CPU загварууд).
  • "auditctl -a never,task" командыг ашиглан аудит болон системийн дуудлагыг хориглох механизмыг идэвхгүй болгож, докерын контейнерийг эхлүүлэх үед "--security-opt seccomp=unconfined" сонголтыг зааж өгнө. Гүйцэтгэлийн нийт өсөлт 11% болж, дамжуулах чадвар 446к 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 цөмүүдийн хооронд зохицуулагчийн шилжилтийг багасгасан. Оновчлолыг CPU-ийн цөмд холбох либректорын процессууд (CPU Pinning) болон цөмийн сүлжээний зохицуулагчийг (Receive Side Scaling) холбох замаар хоёуланг нь гүйцэтгэсэн. Жишээлбэл, irqbalance идэвхгүй болсон бөгөөд CPU-тэй дарааллын хамаарлыг /proc/irq/$IRQ/smp_affinity_list-д тодорхой зааж өгсөн. Либреактор процесс болон ирж буй пакетуудын сүлжээний дарааллыг боловсруулахад ижил CPU-ийн цөмийг ашиглахын тулд сокет үүсгэх үед SO_ATTACH_REUSEPORT_CBPF тугийг тохируулах замаар холбогдсон тусгай BPF зохицуулагчийг ашигладаг. Гарч буй пакетуудын дарааллыг CPU-д холбохын тулд /sys/class/net/eth0/queues/tx- тохиргоог өөрчилсөн. /xps_cpus. Нийт гүйцэтгэлийн өсөлт 38%, дамжуулах чадвар 603k req/s-ээс 834k req/s хүртэл нэмэгдсэн.
  • Тасалдалтай ажиллах, санал асуулгын ашиглалтыг оновчтой болгох. ENA драйверт дасан зохицох-rx горимыг идэвхжүүлж, sysctl net.core.busy_read-ийг удирдсанаар гүйцэтгэлийг 28%-иар нэмэгдүүлсэн (дамжуулах чадвар 834к req/s-ээс 1.06M req/s хүртэл нэмэгдэж, хоцролт нь 361μs-ээс 292μs хүртэл буурсан).
  • Сүлжээний стекийг шаардлагагүй блоклоход хүргэдэг системийн үйлчилгээг идэвхгүй болгох. dhclient-г идэвхгүй болгож, IP хаягийг гараар тохируулснаар гүйцэтгэл 6% нэмэгдэж, дамжуулах чадвар 1.06М req/s-ээс 1.12M req/s хүртэл нэмэгдсэн. Dhclient-ийн гүйцэтгэлд нөлөөлж буй шалтгаан нь түүхий залгуур ашиглан замын хөдөлгөөний шинжилгээ хийх явдал юм.
  • Спингийн түгжээтэй тэмцэх. Сүлжээний стекийг sysctl “net.core.default_qdisc=noqueue” болон “tc qdisc dev eth0 root mq солих”-оор дамжуулан “noqueue” горимд шилжүүлснээр гүйцэтгэл 2%-иар нэмэгдэж, дамжуулах чадвар 1.12 сая req/s-ээс 1.15 сая болж нэмэгдсэн. req/s.
  • “ethtool -K eth0 gro off” командаар GRO (Generic Receive Offload)-ыг идэвхгүй болгох, sysctl “net.ipv4.tcp_congestion_control=reno” ашиглан куб түгжрэлийг хянах алгоритмыг reno-оор солих зэрэг эцсийн жижиг оновчлолууд. Нийт бүтээмжийн өсөлт 4% болсон. Дамжуулах хүчин чадал 1.15 сая рек/с-аас 1.2 сая req/s болж нэмэгдсэн.

Ажилласан оновчлолоос гадна энэ нийтлэлд хүлээгдэж буй гүйцэтгэлийн өсөлтөд хүргээгүй аргуудыг авч үзэх болно. Жишээлбэл, дараахь зүйл үр дүнгүй болсон.

  • Либреакторыг тусад нь ажиллуулж байгаа нь түүнийг саванд ажиллуулахаас гүйцэтгэлийн хувьд ялгаатай байсангүй. 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-source-д нөлөөлсөнгүй.w=tske.
  • 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

сэтгэгдэл нэмэх