Qual è la formula per determinare quanta memoria consuma un socket sotto Linux?

Sto pianificando alcune capacità e mi chiedevo se esiste una formula che potrei usare per prevedere (dal punto di vista della memoria) quante connessioni TCP potrei gestire sul mio server. Al momento, sono solo preoccupato per i requisiti di memoria.

Alcune variabili che penso verranno mostrate nella formula sono:

• sysctl's net.ipv4.tcp_wmem(valore minimo o predefinito)
• sysctl's net.ipv4.tcp_rmem(valore minimo o predefinito)
• la dimensione delle strutture di dati calzino, sock_common, proto e altre per socket.

Non sono sicuro di quanto tcp_wmem e tcp_rmem siano effettivamente allocati e quando quella memoria è allocata. Al momento della creazione del socket? Su richiesta?

Se è possibile modificare il codice sorgente, utilizzare i dati di rusage per misurare l'RSS e registrare quante connessioni TCP sono in gioco al momento della misurazione.

Se il codice sorgente non può essere modificato, utilizzare l'RSS dell'app di rete come riportato da top o ps e ottenere il numero di connessioni di rete al momento della misurazione da lsof -i.

Raccogli questi dati ogni minuto mentre l'applicazione si sposta attraverso il carico di picco e da questi dati puoi ottenere una formula che collega il numero di connessioni all'utilizzo della RAM.

Naturalmente ci sono molte più cose che potresti misurare, in particolare potresti voler misurare l'utilizzo della RAM del kernel, sebbene le strutture di dati tcp dovrebbero essere prevedibili e calcolabili in anticipo. In ogni caso, dai un'occhiata a questa domanda /server/10852/what-limits-the-ma maximum-number-of-connections-on-a-linux- server per ulteriori informazioni sulla sintonizzazione TCP e come avere una visione chiara di ciò che sta accadendo nello stack di rete.

tcp_mem è più importante perché definisce il comportamento dello stack tcp in termini di utilizzo della memoria. Il buffer di invio e ricezione IMO dovrebbe essere un multiplo di tcp_mem. Ecco un collegamento a una formula per il buffer di ricezione: http://www.acc.umu.se/~maswan/linux-netperf.txt . In breve:

L'overhead è: window / 2 ^ tcp_adv_win_scale (il valore predefinito di tcp_adv_win_scale è 2) Quindi per i parametri predefiniti di linux per la finestra di ricezione (tcp_rmem): 87380 - (87380/2 ^ 2) = 65536. Dato un collegamento transatlantico (150 ms RTT), la prestazione massima finisce a: 65536 / 0.150 = 436906 byte / so circa 400 kbyte / s, che oggi è molto lento. Con le dimensioni predefinite aumentate: (873800 - 873800/2 ^ 2) /0.150 = 4369000 byte / s, o circa 4 MB / s, che è resonabile per una rete moderna. E nota che questo è il valore predefinito, se il mittente è configurato con una finestra di dimensioni maggiori, ridimensionerà felicemente fino a 10 volte questo (8738000 * 0,75 / 0,150 = ~ 40Mbyte / s), abbastanza buono per una rete moderna.

Ecco cosa dice l'articolo su tcp_mem:

Quello che rimuovi è un limite artificiale alle prestazioni del PC, senza quel limite sei limitato dalla larghezza di banda end-to-end disponibile e dalla perdita. Quindi potresti finire per saturare il tuo uplink in modo più efficace, ma tcp è bravo a gestirlo.

IMO un valore tcp_mem medio più grande accelera la connessione alla perdita di meno sicurezza e aumenta leggermente l'utilizzo della memoria.

Puoi monitorare lo stack di rete con:

grep skbuff /proc/slabinfo

David ha fornito un'ottima risposta alla domanda, ma a meno che non si utilizzino esclusivamente LFN , quindi anche su un server basato su eventi, è probabile che i buffer TCP siano solo una piccola parte dell'impronta per connessione.

Per la pianificazione della capacità non c'è sostituto per testare il server e calcolare la regressione dell'utilizzo della memoria in base al carico.