![\"Optimizaci\u00f3n](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nOptimizaciones principales: <\/p>\n
- \n
- Optimizaci\u00f3n del c\u00f3digo libreactor. Se utiliz\u00f3 como base la versi\u00f3n R18 del conjunto Techempower, que se mejor\u00f3 eliminando el c\u00f3digo para limitar el n\u00famero de n\u00facleos de CPU utilizados (la optimizaci\u00f3n permiti\u00f3 acelerar el rendimiento en un 25-27%), compilando en GCC con las opciones '-O3' (aumento del 5-10%) y '-march-native' (5-10%), reemplazando las llamadas read\/write por recv\/send (5-10%) y reduciendo la sobrecarga al usar pthreads (2-3%). El aumento total del rendimiento despu\u00e9s de la optimizaci\u00f3n del c\u00f3digo fue del 55%, y la capacidad de respuesta aument\u00f3 de 224k req\/s a 347k req\/s.\n
- Desactivaci\u00f3n de la protecci\u00f3n contra vulnerabilidades causadas por la ejecuci\u00f3n especulativa de instrucciones. El uso de par\u00e1metros al cargar el n\u00facleo 'nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off' permiti\u00f3 aumentar el rendimiento en un 28%, y la capacidad de respuesta aument\u00f3 de 347k req\/s a 446k req\/s. Por separado, el aumento con el par\u00e1metro 'nospectre_v1' (protecci\u00f3n contra Spectre v1 + SWAPGS) fue del 1-2%, 'nospectre_v2' (protecci\u00f3n contra Spectre v2) \u2014 15-20%, 'pti=off' (Spectre v3\/Meltdown) \u2014 6%, 'mds=off tsx_async_abort=off' (MDS\/Zombieload y TSX Asynchronous Abort) \u2014 6%. Se dejaron sin cambios las configuraciones para la protecci\u00f3n contra ataques L1TF\/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass y SRBDS, que no afectaron el rendimiento, ya que no se cruzaron con la configuraci\u00f3n de prueba (por ejemplo, son espec\u00edficas para KVM<\/a>, virtualizaci\u00f3n anidada y otros modelos de CPU).\n
- Desactivaci\u00f3n de los mecanismos de auditor\u00eda y bloqueo de llamadas al sistema mediante el comando 'auditctl -a never,task' y especificando la opci\u00f3n '--security-opt seccomp=unconfined' al iniciar el contenedor docker. El aumento total del rendimiento fue del 11%, y la capacidad de respuesta aument\u00f3 de 446k req\/s a 495k req\/s.\n
- Desactivaci\u00f3n de iptables\/netfilter mediante la descarga de los m\u00f3dulos del n\u00facleo relacionados. La idea de desactivar el cortafuegos, que no se utilizaba en la soluci\u00f3n del servidor espec\u00edfica, fue impulsada por los resultados de la profilaci\u00f3n, los cuales indicaron que la funci\u00f3n nf_hook_slow consum\u00eda el 18% del tiempo. Se se\u00f1ala que nftables opera de manera m\u00e1s eficiente que iptables, pero en Amazon Linux todav\u00eda se utiliza iptables. Tras desactivar iptables, el aumento en el rendimiento fue del 22%, y el ancho de banda aument\u00f3 de 495k req\/s a 603k req\/s.\n
- Reducci\u00f3n de la migraci\u00f3n de manejadores entre diferentes n\u00facleos de CPU para mejorar la eficiencia del uso de la cach\u00e9 de procesador. La optimizaci\u00f3n se realiz\u00f3 tanto a nivel de vinculaci\u00f3n de procesos de libreactor a n\u00facleos de CPU (CPU Pinning), como mediante la fijaci\u00f3n de los manejadores de red del n\u00facleo (Receive Side Scaling). Por ejemplo, se desactiv\u00f3 irqbalance y se establecieron expl\u00edcitamente las vinculaciones de colas a CPU en \/proc\/irq\/$IRQ\/smp_affinity_list. Para utilizar el mismo n\u00facleo de CPU para procesar el proceso libreactor y la cola de red de paquetes entrantes, se implement\u00f3 un manejador BPF propio, conectado mediante la configuraci\u00f3n de la bandera SO_ATTACH_REUSEPORT_CBPF al crear el socket. Para vincular las colas de paquetes salientes a la CPU, se modificaron las configuraciones en \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus. El aumento total en el rendimiento fue del 38%, y el ancho de banda aument\u00f3 de 603k req\/s a 834k req\/s.\n
- Optimizaci\u00f3n del manejo de interrupciones y uso de polling. La activaci\u00f3n del modo adaptive-rx en el controlador ENA y las manipulaciones con sysctl net.core.busy_read permitieron aumentar el rendimiento en un 28% (la capacidad de respuesta aument\u00f3 de 834k req\/s a 1.06M req\/s, y las latencias disminuyeron de 361\u00b5s a 292\u00b5s).\n
- Desactivaci\u00f3n de servicios del sistema que causan bloqueos adicionales en la pila de red. La desactivaci\u00f3n de dhclient y la configuraci\u00f3n IP<\/a> manualmente condujo a un aumento en el rendimiento del 6%, y el ancho de banda aument\u00f3 de 1.06M req\/s a 1.12M req\/s. La raz\u00f3n del impacto de dhclient en el rendimiento se encuentra en el an\u00e1lisis del tr\u00e1fico utilizando un socket en bruto.\n
- Lucha contra el Spin Lock. La transici\u00f3n de la pila de red al modo 'noqueue' a trav\u00e9s de sysctl 'net.core.default_qdisc=noqueue' y 'tc qdisc replace dev eth0 root mq' result\u00f3 en un aumento del rendimiento del 2%, y la capacidad de respuesta aument\u00f3 de 1.12M req\/s a 1.15M req\/s.\n
- Las optimizaciones finales menores, como deshabilitar GRO (Generic Receive Offload) con el comando \u00abethtool -K eth0 gro off\u00bb y cambiar el algoritmo de control de congesti\u00f3n de cubic a reno mediante sysctl \u00abnet.ipv4.tcp_congestion_control=reno\u00bb. El aumento general en el rendimiento fue del 4%. El rendimiento se increment\u00f3 de 1.15M req\/s a 1.2M req\/s. <\/ul>\n
Adem\u00e1s de las optimizaciones implementadas, el art\u00edculo tambi\u00e9n analiza m\u00e9todos que no llevaron al aumento esperado en el rendimiento. Por ejemplo, resultaron ineficaces: <\/p>\n
- \n
- El lanzamiento independiente de libreactor no mostr\u00f3 diferencias en rendimiento en comparaci\u00f3n con el lanzamiento en un contenedor. La sustituci\u00f3n de writev por send, el aumento de maxevents en epoll_wait, y los experimentos con versiones y banderas de GCC no tuvieron efecto (el efecto fue notable solo para las banderas \u00ab-O3\u00bb y \u00ab-march-native\u00bb).\n
- La actualizaci\u00f3n del n\u00facleo de Linux a las versiones 4.19 y 5.4 no afect\u00f3 el rendimiento, al igual que el uso de los schedulers SCHED_FIFO y SCHED_RR, y las manipulaciones de sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 y clocksource=tsc.\n
- En el controlador ENA, la activaci\u00f3n de los modos Offload (segmentaci\u00f3n, scatter-gather, checksum rx\/tx), la compilaci\u00f3n con la bandera \u00ab-O3\u00bb y la aplicaci\u00f3n de los par\u00e1metros ena.rx_queue_size y ena.force_large_llq_header no tuvieron efecto.\n
- Los cambios en la pila de red no llevaron a un aumento del rendimiento:\n