![\"Otimiza\u00e7\u00e3o](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nPrincipais otimiza\u00e7\u00f5es: <\/p>\n
- \n
- Otimiza\u00e7\u00e3o do c\u00f3digo libreactor. A vers\u00e3o R18 do conjunto Techempower foi utilizada como base e melhorada atrav\u00e9s da remo\u00e7\u00e3o do c\u00f3digo que limita o n\u00famero de n\u00facleos de CPU utilizados (a otimiza\u00e7\u00e3o permitiu um aumento de desempenho de 25-27%), compila\u00e7\u00e3o no GCC com op\u00e7\u00f5es '-O3' (crescimento de 5-10%) e '-march-native' (5-10%), substitui\u00e7\u00e3o de chamadas read\/write por recv\/send (5-10%) e redu\u00e7\u00e3o da sobrecarga ao usar pthreads (2-3%). O ganho total de desempenho ap\u00f3s a otimiza\u00e7\u00e3o do c\u00f3digo foi de 55%, e a capacidade de atendimento aumentou de 224k req\/s para 347k req\/s.\n
- Desativa\u00e7\u00e3o de prote\u00e7\u00e3o contra vulnerabilidades causadas pela execu\u00e7\u00e3o especulativa de instru\u00e7\u00f5es. O uso de par\u00e2metros ao carregar o kernel 'nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off' permitiu um aumento de desempenho de 28%, e a capacidade de atendimento aumentou de 347k req\/s para 446k req\/s. Individualmente, o ganho do par\u00e2metro 'nospectre_v1' (prote\u00e7\u00e3o contra Spectre v1 + SWAPGS) foi de 1-2%, 'nospectre_v2' (prote\u00e7\u00e3o contra Spectre v2) \u2014 15-20%, 'pti=off' (Spectre v3\/Meltdown) \u2014 6%, 'mds=off tsx_async_abort=off' (MDS\/Zombieload e TSX Asynchronous Abort) \u2014 6%. As configura\u00e7\u00f5es para prote\u00e7\u00e3o contra ataques L1TF\/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass e SRBDS foram mantidas inalteradas, pois n\u00e3o afetaram o desempenho, j\u00e1 que n\u00e3o se sobrepuseram \u00e0 configura\u00e7\u00e3o testada (por exemplo, espec\u00edficas para KVM<\/a>, virtualiza\u00e7\u00e3o aninhada e outros modelos de CPU).\n
- Desativa\u00e7\u00e3o dos mecanismos de auditoria e bloqueio de chamadas de sistema usando o comando 'auditctl -a never,task' e especificando a op\u00e7\u00e3o '--security-opt seccomp=unconfined' ao iniciar o cont\u00eainer docker. O ganho total de desempenho foi de 11%, e a capacidade de atendimento aumentou de 446k req\/s para 495k req\/s.\n
- Desativa\u00e7\u00e3o do iptables\/netfilter por meio da descarregamento dos m\u00f3dulos do kernel relacionados. A ideia de desativar o firewall, que n\u00e3o era utilizado na solu\u00e7\u00e3o de servidor espec\u00edfica, foi impulsionada pelos resultados de perfilamento, que mostraram que a execu\u00e7\u00e3o da fun\u00e7\u00e3o nf_hook_slow consumia 18% do tempo. Observa-se que o nftables funciona de maneira mais eficiente do que o iptables, mas o iptables ainda \u00e9 utilizado no Amazon Linux. Ap\u00f3s a desativa\u00e7\u00e3o do iptables, o ganho de desempenho foi de 22%, e a capacidade de processamento aumentou de 495k req\/s para 603k req\/s.\n
- Redu\u00e7\u00e3o da migra\u00e7\u00e3o de manipuladores entre diferentes n\u00facleos de CPU para aumentar a efici\u00eancia do uso do cache do processador. A otimiza\u00e7\u00e3o foi feita tanto no n\u00edvel de vincula\u00e7\u00e3o de processos do libreactor aos n\u00facleos de CPU (CPU Pinning), quanto atrav\u00e9s da fixa\u00e7\u00e3o de manipuladores de rede do kernel (Receive Side Scaling). Por exemplo, foi desativado o irqbalance e feita a configura\u00e7\u00e3o expl\u00edcita dos v\u00ednculos de filas ao CPU em \/proc\/irq\/$IRQ\/smp_affinity_list. Para usar o mesmo n\u00facleo de CPU para processar o processo libreactor e a fila de pacotes de entrada, foi utilizado um manipulador BPF pr\u00f3prio, conectado atrav\u00e9s da configura\u00e7\u00e3o do flag SO_ATTACH_REUSEPORT_CBPF ao criar o socket. Para vincular as filas de pacotes de sa\u00edda ao CPU, foram alteradas as configura\u00e7\u00f5es em \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus. O ganho total de desempenho foi de 38%, e a capacidade de processamento aumentou de 603k req\/s para 834k req\/s.\n
- Otimiza\u00e7\u00e3o do processamento de interrup\u00e7\u00f5es e uso de polling. A ativa\u00e7\u00e3o do modo adaptive-rx no driver ENA e manipula\u00e7\u00f5es com sysctl net.core.busy_read permitiram um aumento de desempenho de 28% (a capacidade de atendimento aumentou de 834k req\/s para 1.06M req\/s, e as lat\u00eancias reduziram de 361\u03bcs para 292\u03bcs).\n
- Desativa\u00e7\u00e3o de servi\u00e7os do sistema que causavam bloqueios desnecess\u00e1rios na pilha de rede. A desativa\u00e7\u00e3o do dhclient e a configura\u00e7\u00e3o endere\u00e7os IP<\/a> manualmente resultaram em um aumento de desempenho de 6%, e a capacidade de processamento aumentou de 1.06M req\/s para 1.12M req\/s. A raz\u00e3o do impacto do dhclient no desempenho foi analisada no tr\u00e1fego usando um socket raw.\n
- Combate ao Spin Lock. A mudan\u00e7a do stack de rede para o modo 'noqueue' via sysctl 'net.core.default_qdisc=noqueue' e 'tc qdisc replace dev eth0 root mq' resultou em um aumento de desempenho de 2%, e a capacidade de atendimento aumentou de 1.12M req\/s para 1.15M req\/s.\n
- Otimiza\u00e7\u00f5es finais menores, como desativar o GRO (Generic Receive Offload) com o comando «ethtool -K eth0 gro off» e substituir o algoritmo de controle de congestionamento cubic por reno usando sysctl «net.ipv4.tcp_congestion_control=reno». O ganho total de desempenho foi de 4%. A largura de banda aumentou de 1.15M req\/s para 1.2M req\/s. <\/ul>\n
Al\u00e9m das otimiza\u00e7\u00f5es que funcionaram, o artigo tamb\u00e9m examina m\u00e9todos que n\u00e3o levaram ao aumento de desempenho esperado. Por exemplo, os seguintes m\u00e9todos foram ineficazes: <\/p>\n
- \n
- A execu\u00e7\u00e3o separada do libreactor n\u00e3o apresentou diferen\u00e7a de desempenho em rela\u00e7\u00e3o \u00e0 execu\u00e7\u00e3o em cont\u00eainer. A substitui\u00e7\u00e3o de writev por send, o aumento de maxevents em epoll_wait e experi\u00eancias com vers\u00f5es e flags do GCC n\u00e3o tiveram impacto (o efeito foi notado apenas para os flags «-O3» e «-march-native»).\n
- A atualiza\u00e7\u00e3o do kernel Linux para as vers\u00f5es 4.19 e 5.4, o uso dos escalonadores SCHED_FIFO e SCHED_RR, e manipula\u00e7\u00f5es de sysctl como kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 e clocksource=tsc n\u00e3o afetaram o desempenho.\n
- No driver ENA, a ativa\u00e7\u00e3o dos modos Offload (segmentation, scatter-gather, rx\/tx checksum), a compila\u00e7\u00e3o com a flag «-O3» e a aplica\u00e7\u00e3o dos par\u00e2metros ena.rx_queue_size e ena.force_large_llq_header n\u00e3o tiveram impacto.\n
- As altera\u00e7\u00f5es no stack de rede n\u00e3o resultaram em aumento de desempenho:\n