In breve

Ottimizzeremo queste aree chiave:

  • Tecniche di offloading NIC
  • TCP_QUICKACK per ridurre la latenza
  • Ottimizzazione di net.core.rmem_max
  • SO_BUSY_POLL per l'efficienza della CPU
  • Strategie per minimizzare i picchi di latenza

La necessità di velocità: Perché 100Gbps?

Prima di addentrarci nei dettagli, affrontiamo la questione principale: Perché 100Gbps? Nel mondo del trading ad alta frequenza, ogni microsecondo conta. Non si tratta solo di vantarsi; si tratta della differenza tra guadagnare milioni e perdere tutto.

Ma raggiungere e mantenere un throughput di 100Gbps non significa solo aggiungere più hardware. Si tratta di ottimizzare il sistema per ottenere il massimo dalle infrastrutture esistenti. Ed è qui che entra in gioco la regolazione del kernel.

Offloading NIC: Lascia che l'hardware faccia il lavoro pesante

Prima di tutto: se non stai sfruttando l'offloading NIC, stai lasciando prestazioni sul tavolo. Le NIC moderne sono in grado di gestire molte attività di rete che altrimenti rallenterebbero la CPU. Ecco come controllare le impostazioni di offload correnti:

ethtool -k eth0

Cerca questi offload chiave:

  • tcp-segmentation-offload (TSO)
  • generic-receive-offload (GRO)
  • receive-side-scaling (RSS)

Per abilitare questi offload, puoi usare:

ethtool -K eth0 tso on gro on

Ma aspetta, c'è di più! Per le reti a 100Gbps, considera di abilitare questi offload avanzati:

  • filtraggio ntuple
  • receive packet steering (RPS)
  • receive flow steering (RFS)

Questi possono ridurre significativamente l'uso della CPU e migliorare la distribuzione dei pacchetti tra i core.

TCP_QUICKACK: Perché la pazienza non è una virtù nel HFT

Nel trading ad alta frequenza, aspettare gli ACK è come aspettare che la vernice si asciughi – nessuno ha tempo per questo. Entra in gioco TCP_QUICKACK. Questa opzione dice al kernel di inviare gli ACK immediatamente, invece di ritardarli.

Per abilitare TCP_QUICKACK a livello di sistema:

echo 1 > /proc/sys/net/ipv4/tcp_quick_ack

Per un socket specifico nella tua applicazione:


int quickack = 1;
setsockopt(socket_fd, IPPROTO_TCP, TCP_QUICKACK, &quickack, sizeof(quickack));

Ricorda che, sebbene questo possa ridurre significativamente la latenza, potrebbe aumentare il traffico di rete. Come per tutte le ottimizzazioni, misura prima e dopo per assicurarti che sia vantaggioso per il tuo caso specifico.

Ottimizzazione di net.core.rmem_max: La dimensione conta

Quando si tratta di buffer di ricezione, più grande è spesso meglio – fino a un certo punto. Il parametro net.core.rmem_max imposta la dimensione massima del buffer di ricezione del socket in byte. Per le reti a 100Gbps, vorrai aumentarlo:

sysctl -w net.core.rmem_max=16777216

Questo imposta il buffer di ricezione massimo a 16MB. Ma non fermarti qui! Vorrai anche regolare questi parametri correlati:


sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

Ricorda, questi cambiamenti sono temporanei. Per renderli permanenti, aggiungili a /etc/sysctl.conf.

SO_BUSY_POLL: Quando l'attesa attiva è una buona cosa

Nel mondo del networking a bassa latenza, a volte il modo migliore di aspettare è non aspettare affatto. Ecco dove entra in gioco SO_BUSY_POLL. Questa opzione del socket permette al kernel di fare busy-poll per i pacchetti in arrivo, invece di affidarsi agli interrupt.

Per abilitare SO_BUSY_POLL nella tua applicazione:


int busy_poll = 50; // Tempo in microsecondi
setsockopt(socket_fd, SOL_SOCKET, SO_BUSY_POLL, &busy_poll, sizeof(busy_poll));

Puoi anche abilitare il busy polling a livello di sistema:


echo 50 > /proc/sys/net/core/busy_poll
echo 50 > /proc/sys/net/core/busy_read

Fai attenzione con questa impostazione, poiché può aumentare l'uso della CPU. È meglio usarla su core di rete dedicati.

Domare la bestia della latenza: Strategie per ridurre i picchi

Anche con tutte queste ottimizzazioni, i picchi di latenza possono ancora presentarsi. Ecco alcune strategie aggiuntive per tenerli a bada:

1. Affinità IRQ

Assicurati che gli interrupt di rete siano gestiti da core CPU dedicati:


echo 2-3 > /proc/irq/YOUR_ETH_IRQ/smp_affinity_list

2. Isolamento CPU

Isola le CPU per i tuoi compiti di rete critici:


isolcpus=2-3 nohz_full=2-3 rcu_nocbs=2-3

Aggiungi questi ai parametri di avvio del kernel.

3. NAPI (New API)

Assicurati che NAPI sia abilitato sulla tua interfaccia di rete:


ethtool -k eth0 | grep "napi-tx-"

4. Ottimizza lo Scheduler

Per compiti sensibili alla latenza, considera l'uso dello scheduler SCHED_FIFO:


struct sched_param param;
param.sched_priority = 99;
pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m);

Mettere tutto insieme: Un approccio olistico

Ricorda, ottimizzare per microservizi a 100Gbps non riguarda solo la regolazione di impostazioni individuali. Si tratta di adottare un approccio olistico all'intero sistema. Ecco alcuni consigli finali per unire tutto:

  • Profilare la tua applicazione per identificare i colli di bottiglia
  • Usare strumenti come perf, flamegraphs ed eBPF per approfondimenti dettagliati
  • Considerare tecniche DPDK o di bypass del kernel per prestazioni estreme
  • Non dimenticare l'I/O di archiviazione – può essere un collo di bottiglia nascosto
  • Effettuare regolarmente benchmark e monitorare il sistema per individuare regressioni precocemente

Conclusione: La ricerca infinita della velocità

Ottimizzare Linux per microservizi a 100Gbps non è per i deboli di cuore. È una danza complessa di capacità hardware, parametri del kernel e ottimizzazioni a livello di applicazione. Ma con le tecniche che abbiamo trattato – dall'offloading NIC a TCP_QUICKACK, dalla regolazione dei buffer al busy polling – ora sei armato della conoscenza per portare il tuo ambiente di trading ad alta frequenza al livello successivo.

Ricorda, la ricerca di una latenza più bassa e di un throughput più alto non è mai veramente finita. Continua a sperimentare, continua a misurare e, soprattutto, continua a spingere i limiti di ciò che è possibile. Chissà? Forse la prossima volta parleremo di ottimizzazione per 400Gbps!

"Nel mondo del trading ad alta frequenza, chi esita è perduto. Ma chi ottimizza il suo kernel domina il mercato." - Anonimo Guru del Kernel Linux

Ora vai e conquista quei pacchetti! E se hai qualche consiglio di ottimizzazione killer, condividilo nei commenti. Dopotutto, nel mondo spietato del HFT, siamo tutti insieme... fino a quando non lo siamo più.