![\"Ottimizzazione](\"\/wp-content\/uploads\/2021\/05\/908fb8d92e84a3e7557af7f6c622298e.png\")
<\/center> <\/p>\nOttimizzazioni principali: <\/p>\n
- \n
- Ottimizzazione del codice libreactor. \u00c8 stata utilizzata come base la versione R18 del set Techempower, che \u00e8 stata migliorata rimuovendo il codice per limitare il numero di core CPU utilizzati (l'ottimizzazione ha consentito di accelerare le prestazioni del 25-27%), compilazione in GCC con le opzioni \u00ab-O3\u00bb (aumento del 5-10%) e \u00ab-march-native\u00bb (5-10%), sostituzione delle chiamate read\/write con recv\/send (5-10%) e riduzione delle spese generali nell'uso di pthreads (2-3%). L'aumento complessivo delle prestazioni dopo l'ottimizzazione del codice \u00e8 stato del 55%, mentre la capacit\u00e0 di elaborazione \u00e8 aumentata da 224k req\/s a 347k req\/s.\n
- Disattivazione della protezione dalle vulnerabilit\u00e0 causate dall'esecuzione speculativa delle istruzioni. L'uso dei parametri al caricamento del kernel \u00abnospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off\u00bb ha permesso di aumentare le prestazioni del 28%, e la capacit\u00e0 di elaborazione \u00e8 aumentata da 347k req\/s a 446k req\/s. Singolarmente, il guadagno dal parametro \u00abnospectre_v1\u00bb (protezione da Spectre v1 + SWAPGS) \u00e8 stato dell'1-2%, \u00abnospectre_v2\u00bb (protezione da Spectre v2) \u2014 15-20%, \u00abpti=off\u00bb (Spectre v3\/Meltdown) \u2014 6%, \u00abmds=off tsx_async_abort=off\u00bb (MDS\/Zombieload e TSX Asynchronous Abort) \u2014 6%. Le impostazioni per la protezione dagli attacchi L1TF\/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass e SRBDS sono rimaste inalterate, in quanto non hanno influenzato le prestazioni, non sovrapponendosi alla configurazione testata (ad esempio, specifiche per KVM<\/a>, virtualizzazione annidata e altri modelli di CPU).\n
- Disattivazione dei meccanismi di audit e blocco delle chiamate di sistema tramite il comando \u00abauditctl -a never,task\u00bb e specificando l'opzione \u00ab--security-opt seccomp=unconfined\u00bb durante l avvio del contenitore docker. L'aumento complessivo delle prestazioni \u00e8 stato dell'11%, mentre la capacit\u00e0 di elaborazione \u00e8 aumentata da 446k req\/s a 495k req\/s.\n
- Disabilitare iptables\/netfilter mediante il caricamento dei moduli kernel correlati. L'idea di disattivare il firewall, non utilizzato in una soluzione server specifica, \u00e8 stata suggerita dai risultati del profiling, che indicano che la funzione nf_hook_slow richiedeva il 18% del tempo. Si nota che nftables funziona in modo pi\u00f9 efficiente rispetto a iptables, ma in Amazon Linux si continua a utilizzare iptables. Dopo aver disattivato iptables, il miglioramento delle prestazioni \u00e8 stato del 22%, mentre la larghezza di banda \u00e8 aumentata da 495k req\/s a 603k req\/s.\n
- Riduzione della migrazione dei gestori tra diversi core CPU per migliorare l'efficienza dell'utilizzo della cache del processore. L'ottimizzazione \u00e8 stata eseguita sia a livello di binding dei processi libreactor ai core CPU (CPU Pinning), sia attraverso il legame dei gestori di rete del kernel (Receive Side Scaling). Ad esempio, \u00e8 stata disattivata irqbalance e sono state impostate esplicitamente le affinit\u00e0 delle code con CPU in \/proc\/irq\/$IRQ\/smp_affinity_list. Per utilizzare lo stesso core CPU per elaborare i processi libreactor e la coda di rete dei pacchetti in ingresso \u00e8 stato utilizzato un gestore BPF personalizzato, connesso tramite l'impostazione del flag SO_ATTACH_REUSEPORT_CBPF durante la creazione del socket. Per legare alle CPU le code dei pacchetti in uscita, sono state modificate le impostazioni in \/sys\/class\/net\/eth0\/queues\/tx-<n>\/xps_cpus. L'incremento totale delle prestazioni \u00e8 stato del 38%, con la larghezza di banda aumentata da 603k req\/s a 834k req\/s.\n
- Ottimizzazione della gestione delle interruzioni e utilizzo del polling. L'attivazione della modalit\u00e0 adaptive-rx nel driver ENA e la manipolazione di sysctl net.core.busy_read hanno permesso di aumentare le prestazioni del 28% (la capacit\u00e0 di elaborazione \u00e8 aumentata da 834k req\/s a 1.06M req\/s, e i ritardi sono diminuiti da 361\u03bcs a 292\u03bcs).\n
- Disabilitazione dei servizi di sistema che portano a blocchi indesiderati nello stack di rete. Disattivare dhclient e installare Indirizzi IP<\/a> manualmente ha portato a un incremento delle prestazioni del 6%, con la larghezza di banda aumentata da 1.06M req\/s a 1.12M req\/s. La causa dell'impatto di dhclient sulle prestazioni \u00e8 stata analizzata tramite il traffico utilizzando un socket raw.\n
- Gestione dello Spin Lock. La modifica dello stack di rete in modalit\u00e0 \u00abnoqueue\u00bb tramite sysctl \u00abnet.core.default_qdisc=noqueue\u00bb e \u00abtc qdisc replace dev eth0 root mq\u00bb ha portato a un aumento delle prestazioni del 2%, e la capacit\u00e0 di elaborazione \u00e8 aumentata da 1.12M req\/s a 1.15M req\/s.\n
- Ottimizzazioni finali minori, come disattivare GRO (Generic Receive Offload) con il comando «ethtool -K eth0 gro off» e sostituire l'algoritmo di controllo della congestione tcp da cubic a reno utilizzando sysctl «net.ipv4.tcp_congestion_control=reno». Il guadagno totale di prestazioni \u00e8 stato del 4%. La larghezza di banda \u00e8 aumentata da 1.15M req\/s a 1.2M req\/s. <\/ul>\n
Oltre alle ottimizzazioni implementate, l'articolo esamina anche i metodi che non hanno portato all'atteso aumento delle prestazioni. Ad esempio, sono risultati inefficaci: <\/p>\n
- \n
- L'esecuzione separata di libreactor non ha mostrato differenze di prestazioni rispetto all'esecuzione all'interno di un container. La sostituzione di writev con send, l'aumento di maxevents in epoll_wait e gli esperimenti con versioni e flag GCC non hanno avuto impatto (l'effetto era visibile solo per i flag «-O3» e «-march-native»).\n
- Non ha influito sulle prestazioni l'aggiornamento del kernel Linux alle versioni 4.19 e 5.4, l'uso dei pianificatori SCHED_FIFO e SCHED_RR, le manipolazioni con sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 e clocksource=tsc.\n
- Nel driver ENA, l'attivazione delle modalit\u00e0 Offload (segmentazione, scatter-gather, checksum rx\/tx), la compilazione con il flag «-O3» e l'applicazione dei parametri ena.rx_queue_size e ena.force_large_llq_header non hanno avuto effetto.\n
- Non hanno portato a un aumento delle prestazioni le modifiche nello stack di rete:\n