![\"Linux](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nF\u0151 optimaliz\u00e1l\u00e1sok: <\/p>\n
- \n
- A libreactor k\u00f3d optimaliz\u00e1l\u00e1sa. Az alapot a Techempower R18-as verzi\u00f3ja k\u00e9pezte, amelyet \u00fagy jav\u00edtottak, hogy elt\u00e1vol\u00edtott\u00e1k a processzor magok sz\u00e1m\u00e1t korl\u00e1toz\u00f3 k\u00f3dot (az optimaliz\u00e1l\u00e1s 25-27%-kal gyors\u00edtotta a m\u0171k\u00f6d\u00e9st), a GCC-ben az «-O3» (5-10%-os n\u00f6veked\u00e9s) \u00e9s «-march-native» (5-10%-os n\u00f6veked\u00e9s) opci\u00f3kkal t\u00f6rt\u00e9nt ford\u00edt\u00e1s, a read\/write h\u00edv\u00e1sok recv\/send h\u00edv\u00e1sokkal val\u00f3 helyettes\u00edt\u00e9se (5-10%) \u00e9s a pthreads haszn\u00e1lat\u00e1nak k\u00f6lts\u00e9geinek cs\u00f6kkent\u00e9se (2-3%). Az optimaliz\u00e1l\u00e1s ut\u00e1ni \u00e1ltal\u00e1nos teljes\u00edtm\u00e9nyn\u00f6veked\u00e9s 55% volt, m\u00edg a forgalom a 224k req\/s-r\u0151l 347k req\/s-re n\u0151tt.\n
- A spekulat\u00edv utas\u00edt\u00e1sv\u00e9grehajt\u00e1sb\u00f3l ered\u0151 sebezhet\u0151s\u00e9gek v\u00e9delm\u00e9nek letilt\u00e1sa. A kernel bet\u00f6lt\u00e9sekor haszn\u00e1lt «nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off» param\u00e9terek 28%-kal n\u00f6velt\u00e9k a teljes\u00edtm\u00e9nyt, m\u00edg a forgalom 347k req\/s-r\u0151l 446k req\/s-re emelkedett. A «nospectre_v1» (v1 Spectre v\u00e9delme + SWAPGS) param\u00e9ter \u00f6n\u00e1ll\u00f3an 1-2%-os n\u00f6veked\u00e9st eredm\u00e9nyezett, a «nospectre_v2» (v2 Spectre v\u00e9delme) 15-20%-os n\u00f6veked\u00e9st, a «pti=off» (Spectre v3\/Meltdown) 6%-ot, a «mds=off tsx_async_abort=off» (MDS\/Zombieload \u00e9s TSX Asynchronous Abort) pedig 6%-ot. A L1TF\/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass \u00e9s SRBDS t\u00e1mad\u00e1sok v\u00e9delmi be\u00e1ll\u00edt\u00e1sait \u00e9rintetlen\u00fcl hagyt\u00e1k, mivel nem befoly\u00e1solt\u00e1k a teljes\u00edtm\u00e9nyt, mivel nem keresztezt\u00e9k a tesztelt konfigur\u00e1ci\u00f3t (p\u00e9ld\u00e1ul specifikusak voltak a) KVM<\/a>, a be\u00e1gyazott virtualiz\u00e1ci\u00f3 \u00e9s m\u00e1s CPU-modellek).\n
- Az audit\u00e1l\u00e1si mechanizmusok letilt\u00e1sa \u00e9s a rendszerh\u00edv\u00e1sok blokkol\u00e1sa az «auditctl -a never,task» parancs \u00e9s a «—security-opt seccomp=unconfined» opci\u00f3 megad\u00e1s\u00e1val a docker kont\u00e9ner ind\u00edt\u00e1sakor. Az \u00f6sszes\u00edtett teljes\u00edtm\u00e9nyn\u00f6veked\u00e9s 11% volt, m\u00edg a forgalom 446k req\/s-r\u0151l 495k req\/s-re n\u0151tt.\n
- Az iptables\/netfilter letilt\u00e1sa a hozz\u00e1juk kapcsol\u00f3d\u00f3 kernel modulok elt\u00e1vol\u00edt\u00e1s\u00e1val. A t\u0171zfal lekapcsol\u00e1s\u00e1nak \u00f6tlet\u00e9t, amelyet a specifikus szervermegold\u00e1s nem haszn\u00e1lt, a profiloz\u00e1si eredm\u00e9nyek indokolt\u00e1k, mivel a nf_hook_slow funkci\u00f3 v\u00e9grehajt\u00e1s\u00e1ra 18% id\u0151t ford\u00edtottak. Megjegyzend\u0151, hogy a nftables hat\u00e9konyabban m\u0171k\u00f6dik, mint az iptables, de az Amazon Linuxban tov\u00e1bbra is az iptables haszn\u00e1latos. Az iptables letilt\u00e1sa ut\u00e1n a teljes\u00edtm\u00e9nyn\u00f6veked\u00e9s 22% volt, a throughput pedig 495k req\/s-r\u0151l 603k req\/s-ra n\u0151tt.\n
- A processzor-k\u00e9szletek k\u00f6z\u00f6tti migr\u00e1ci\u00f3 cs\u00f6kkent\u00e9se a CPU-cache hat\u00e9konyabb kihaszn\u00e1l\u00e1sa \u00e9rdek\u00e9ben. Az optimaliz\u00e1l\u00e1s a libreactor folyamatok CPU-hoz val\u00f3 hozz\u00e1rendel\u00e9se (CPU Pinning) \u00e9s a h\u00e1l\u00f3zati kernelkezel\u0151k r\u00f6gz\u00edt\u00e9se (Receive Side Scaling) szintj\u00e9n val\u00f3sult meg. P\u00e9ld\u00e1ul letiltott\u00e1k az irqbalance-t, \u00e9s a sorok explicit CPU-hoz rendel\u00e9s\u00e9t \u00e1ll\u00edtott\u00e1k be a \/proc\/irq\/$IRQ\/smp_affinity_list f\u00e1jlban. A libreactor folyamat \u00e9s a bej\u00f6v\u0151 csomagok h\u00e1l\u00f3zati sor\u00e1nak kezel\u00e9s\u00e9re egyedi BPF-kezel\u0151t haszn\u00e1ltak, amely a SO_ATTACH_REUSEPORT_CBPF jelz\u0151 be\u00e1ll\u00edt\u00e1s\u00e1val lett csatlakoztatva a socket l\u00e9trehoz\u00e1sakor. A kimen\u0151 csomagok sor\u00e1nak CPU-hoz val\u00f3 rendel\u00e9s\u00e9nek \u00e9rdek\u00e9ben a \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus be\u00e1ll\u00edt\u00e1sait m\u00f3dos\u00edtott\u00e1k. Az \u00f6sszes\u00edtett teljes\u00edtm\u00e9nyn\u00f6veked\u00e9s 38% volt, a throughput pedig 603k req\/s-r\u0151l 834k req\/s-ra n\u0151tt.\n
- Az interrupci\u00f3k feldolgoz\u00e1s\u00e1nak optimaliz\u00e1l\u00e1sa \u00e9s polling haszn\u00e1lata. Az ENA meghajt\u00f3ban az adaptive-rx m\u00f3d bekapcsol\u00e1sa \u00e9s a sysctl net.core.busy_read manipul\u00e1l\u00e1sa 28%-kal n\u00f6velte a teljes\u00edtm\u00e9nyt (a forgalom 834k req\/s-r\u0151l 1.06M req\/s-re emelkedett, m\u00edg a k\u00e9sleltet\u00e9s 361μs-r\u0151l 292μs-ra cs\u00f6kkent).\n
- A h\u00e1l\u00f3zati verem f\u00f6l\u00f6sleges blokkol\u00e1s\u00e1hoz vezet\u0151 rendszerszolg\u00e1ltat\u00e1sok letilt\u00e1sa. A dhclient letilt\u00e1sa \u00e9s a IP address<\/a> k\u00e9zi be\u00e1ll\u00edt\u00e1s 6%-os teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st eredm\u00e9nyezett, a throughput pedig 1.06M req\/s-r\u0151l 1.12M req\/s-ra n\u0151tt. A dhclient teljes\u00edtm\u00e9nyre gyakorolt hat\u00e1s\u00e1nak oka a raw-socket haszn\u00e1lat\u00e1val v\u00e9gzett forgalomelemz\u00e9s.\n
- A Spin Lock probl\u00e9m\u00e1ja. A h\u00e1l\u00f3zati stack m\u00f3dos\u00edt\u00e1sa «noqueue» be\u00e1ll\u00edt\u00e1sra a sysctl «net.core.default_qdisc=noqueue» \u00e9s «tc qdisc replace dev eth0 root mq» parancsok seg\u00edts\u00e9g\u00e9vel 2%-os teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st eredm\u00e9nyezett, m\u00edg a forgalom 1.12M req\/s-r\u0151l 1.15M req\/s-re n\u0151tt.\n
- A v\u00e9gs\u0151 finom\u00edt\u00e1sok, mint a GRO (Generic Receive Offload) letilt\u00e1sa az \u201eethtool -K eth0 gro off\u201d paranccsal, \u00e9s a TCP torl\u00f3d\u00e1skezel\u00e9si algoritmus cser\u00e9je Cubic-r\u00f3l Reno-ra a sysctl \u201enet.ipv4.tcp_congestion_control=reno\u201d be\u00e1ll\u00edt\u00e1ssal. A teljes teljes\u00edtm\u00e9nyn\u00f6veked\u00e9s 4% volt. Az \u00e1tereszt\u0151k\u00e9pess\u00e9g 1,15M req\/s-r\u00f3l 1,2M req\/s-ra n\u0151tt. <\/ul>\n
A m\u00e1r v\u00e9grehajtott optimaliz\u00e1ci\u00f3kon k\u00edv\u00fcl a cikk olyan m\u00f3dszereket is t\u00e1rgyal, amelyek nem hozt\u00e1k meg a v\u00e1rt teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st. P\u00e9ld\u00e1ul nem voltak hat\u00e9konyak: <\/p>\n
- \n
- A libreactor k\u00fcl\u00f6n ind\u00edt\u00e1sa nem mutatott teljes\u00edtm\u00e9nybeli k\u00fcl\u00f6nbs\u00e9get a kont\u00e9nerben t\u00f6rt\u00e9n\u0151 ind\u00edt\u00e1shoz k\u00e9pest. Nem volt hat\u00e1sa a writev send-re, a maxevents n\u00f6vel\u00e9se az epoll_wait-ben, \u00e9s a verzi\u00f3kkal \u00e9s GCC z\u00e1szl\u00f3kkal v\u00e9gzett k\u00eds\u00e9rleteknek (a hat\u00e1s csak az \u201e-O3\u201d \u00e9s \u201e-march-native\u201d z\u00e1szl\u00f3k eset\u00e9ben volt \u00e9szlelhet\u0151).\n
- A Linux kernel 4.19-es \u00e9s 5.4-es verzi\u00f3ra val\u00f3 friss\u00edt\u00e9se, az SCHED_FIFO \u00e9s SCHED_RR \u00fctemez\u0151k haszn\u00e1lata, a sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 \u00e9s clocksource=tsc manipul\u00e1l\u00e1sa nem hatott a teljes\u00edtm\u00e9nyre.\n
- Az ENA illeszt\u0151programban az Offload m\u00f3dok (szegment\u00e1l\u00e1s, scatter-gather, rx\/tx ellen\u0151rz\u0151 \u00f6sszeg) enged\u00e9lyez\u00e9se, az \u201e-O3\u201d z\u00e1szl\u00f3val val\u00f3 ford\u00edt\u00e1s, valamint az ena.rx_queue_size \u00e9s az ena.force_large_llq_header param\u00e9terek alkalmaz\u00e1sa nem befoly\u00e1solta.\n
- A h\u00e1l\u00f3zati veremben v\u00e9grehajtott v\u00e1ltoz\u00e1sok nem vezettek teljes\u00edtm\u00e9nyn\u00f6veked\u00e9shez:\n