Rêbernameyek hûrgulî li ser birêkûpêkkirina hawîrdora Linux-ê hate weşandin da ku ji bo pêkanîna daxwazên HTTP performansa herî zêde bigihîje. Rêbazên pêşniyar kirin ku bi mîhengên standard ên Amazon Linux 2 re bi kernel 4-ê heya 224 mîlyon daxwazî di her saniyeyê de ji 2 hezar daxwazên API-yê li ser bingeha pirtûkxaneya lîberaktorê ya li hawîrdora Amazon EC4.14 (1.2 vCPU) li ser bingeha pirtûkxaneya JSON-ê gengaz kir. duyemîn piştî xweşbîniyê (zêdebûnek 436%), û di heman demê de bû sedema kêmbûna derengiya daxwazên pêvajoyê ji sedî 79%. Rêbazên pêşniyarkirî ji bo libreactor ne taybetî ne û dema ku serverên http yên din bikar tînin, tevî nginx, Actix, Netty û Node.js dixebitin (libreactor di ceribandinan de hate bikar anîn ji ber ku çareseriya li ser bingeha wê performansa çêtir nîşan da).
Optimîzasyonên bingehîn:
- Optimîzekirina koda libreactor. Vebijarka R18 ji kîta Techempower wekî bingeh hate bikar anîn, ku bi rakirina kodê ve hate çêtir kirin da ku hejmara navikên CPU-yê yên têne bikar anîn sînordar bike (optimîzasyon destûr da ku lezkirina xebatê bi 25-27%), li GCC-ê bi vebijarkên "-O3" kom bibe. (zêdebûnek ji %5-10 ) û "-adar-xwemalî" (5-10%), li şûna bangên xwendin/nivîsandinê bi recv/send (5-10%) û kêmkirina sermayê dema bikaranîna threadan (2-3%). . Zêdebûna performansa giştî piştî xweşbîniya kodê% 55 bû, û berbelav ji 224k req/s gihîşt 347k req/s.
- Parastina li dijî qelsiyên darvekirina spekulatîf neçalak bike. Dema barkirina kernelê bi karanîna pîvanên "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" destûr da ku performansê% 28 zêde bibe û berbi ji 347k req/s berbi 446k req/s zêde bû. Ji hev veqetandî, zêdebûna ji parametreya "nospectre_v1" (parastina ji Specter v1 + SWAPGS) 1-2%, "nospectre_v2" (parastina ji Specter v2) bû - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6%, "mds=off tsx_async_abort=off" (MDS/Zombieload û TSX Asynchronous Abort) - 6%. Mîhengên parastina li dijî L1TF/Foreshadow (l1tf=flush), iTLB multihit, Spekulatîf Store Bypass û êrîşên SRBDS neguherî hatin hiştin, ku bandor li performansê nekir ji ber ku ew bi veavakirina ceribandinê re hevûdu nekirin (mînak, taybetî ji bo KVM, hêlîn virtualkirin û modelên CPU yên din).
- Bi karanîna fermana "auditctl -a qet, task" û destnîşankirina vebijarka "--security-opt seccomp=neconfined" dema ku konteynera dokerê dest pê dike, mekanîzmayên astengkirina lênêrînê û banga pergalê neçalak dike. Zêdebûna performansa giştî 11% bû, û berbiçûk ji 446k req/s derket 495k req/s.
- Bi rakirina modulên kernelê yên têkildar re iptables/netfilter neçalak bike. Fikra neçalakkirina dîwarê dîwarê, ku di çareseriyek serverek taybetî de nehat bikar anîn, ji hêla encamên profîlkirinê ve hate pêşandan, ku li gorî vê yekê fonksiyona nf_hook_slow% 18 ji dema darvekirinê girt. Tê zanîn ku nftables ji iptables bi bandortir dixebite, lê Amazon Linux berdewam dike iptables bikar bîne. Piştî neçalakkirina iptables, zêdebûna performansê% 22 bû, û berbi ji 495k req/s derket 603k req/s.
- Koçberiya hilkêşan di navbera navikên CPU yên cihêreng de kêm kir da ku karbidestiya karanîna cache ya pêvajoyê baştir bike. Optimîzasyon hem di asta girêdana pêvajoyên lîberaktorê bi navgînên CPU (Pinning CPU) û hem jî bi navgîniya hilgirên tora kernelê ve (Receive Side Scaling) hate kirin. Mînakî, irqbalance hate neçalak kirin û girêdana rêzê ya bi CPU re bi eşkere li /proc/irq/$IRQ/smp_affinity_list hate danîn. Ji bo ku hûn heman bingeha CPU-yê bikar bînin da ku pêvajoya lîberactor û rêza torê ya pakêtên hatinî bişopînin, rêvekerek BPF-ya xwerû tê bikar anîn, ku dema çêkirina soketê bi danîna ala SO_ATTACH_REUSEPORT_CBPF ve girêdayî ye. Ji bo girêdana rêzên pakêtên derketinê bi CPU-yê re, mîhengên /sys/class/net/eth0/queues/tx- hatine guhertin. /xps_cpus. Zêdebûna performansa giştî% 38 bû, û berbelav ji 603k req/s derket 834k req/s.
- Optimîzasyona hilgirtina navberê û karanîna dengdanê. Çalakkirina moda adaptive-rx di ajokera ENA de û manîpulekirina sysctl net.core.busy_read performansê% 28 zêde kir (berbiçav ji 834k req/s berbi 1.06M req/s zêde bû, û derengbûn ji 361μs daket 292μs).
- Karûbarên pergalê yên ku dibin sedema astengkirina nehewce di stûna torê de neçalak bikin. Neçalakkirina dhclient û bi desta danîna navnîşana IP-ê bû sedema 6% zêdekirina performansê û berbi ji 1.06M req/s berbi 1.12M req/s zêde bû. Sedema ku dhclient bandorê li performansê dike di analîza trafîkê de bi karanîna soketek xav e.
- Têkoşîna Spin Lock. Veguheztina stika torê bo moda "noqueue" bi riya sysctl "net.core.default_qdisc=noqueue" û "tc qdisc şûna dev eth0 root mq" bû sedema zêdebûna performansê% 2, û rêjeyek ji 1.12M req/s bo 1.15M zêde bû. req/s.
- Optimîzasyonên piçûk ên dawîn, wek neçalakkirina GRO (Generic Receive Offload) bi fermana "ethtool -K eth0 gro off" û guheztina algorîtmaya kontrolê ya kubar bi reno bi karanîna sysctl "net.ipv4.tcp_congestion_control=reno". Zêdebûna hilberîna giştî %4 bû. Rêjeya ji 1.15M req/s berbi 1.2M req/s zêde bû.
Digel xweşbîniyên ku xebitîn, gotar di heman demê de li ser rêbazên ku nebûn sedema zêdebûna performansa hêvîdar jî nîqaş dike. Mînakî, tiştên jêrîn bêbandor derketin:
- Rêvekirina lîberaktorê ji hev cihê di performansê de ji xebitandina wê di konteynerê de cûda nebû. Li şûna nivîsandinê bi şandinê, zêdekirina maxevents di epoll_wait de, û ceribandina bi versiyonên GCC û alayan re ti bandorek nebû (bandor tenê ji bo alayên "-O3" û "-adar-xwecihî" diyar bû).
- Nûvekirina kernel Linux bo guhertoyên 4.19 û 5.4, bikaranîna plansazkerên SCHED_FIFO û SCHED_RR, manîpulekirina sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=tu carî, skew_tick=1 û c bandor li performansê nekir.
- Di ajokera ENA de, çalakkirina modên Offload (segmentation, scatter-cather, rx/tx checksum), avakirina bi ala "-O3", û karanîna parametreyên ena.rx_queue_size û ena.force_large_llq_header ti bandorek nebû.
- Guhertinên di stûna torê de performansê baştir nekir:
- IPv6 neçalak bike: ipv6.disable=1
- VLAN neçalak bike: modprobe -rv 8021q
- Kontrolkirina çavkaniya pakêtê neçalak bike
- net.ipv4.conf.all.rp_filter=0
- net.ipv4.conf.eth0.rp_filter=0
- net.ipv4.conf.all.accept_local=1 (bandora neyînî)
- 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
Source: opennet.ru