come controllare la dimensione dell'anello rx, max_backlog e max_syn_backlog


41

Molto spesso nel corso della risoluzione dei problemi e dell'ottimizzazione delle cose, mi ritrovo a pensare alle seguenti impostazioni del kernel Linux:

net.core.netdev_max_backlog
net.ipv4.tcp_max_syn_backlog
net.core.somaxconn

Altro che fs.file-max, net.ipv4.ip_local_port_range, net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, e net.ipv4.tcp_wmem, che sembra essere il manopole importanti a pasticciare con quando si sta accordando una scatola per alti livelli di concorrenza.

La mia domanda: come posso verificare per vedere quanti elementi ci sono in ciascuna di queste code? Di solito le persone li impostano semplicemente su valori molto alti, ma vorrei registrare quelle dimensioni della coda per aiutare a prevedere i guasti futuri e rilevare i problemi prima che si manifestino in modo evidente per l'utente.


Questa è una domanda fantastica. Sono interessato al problema incast e alle ritrasmissioni TCP ad alta risoluzione.
dhchdhd,

Risposte:


29

Anch'io me lo sono chiesto ed ero motivato dalla tua domanda!

Ho raccolto quanto potrei avvicinarmi a ciascuna delle code che hai elencato con alcune informazioni relative a ciascuna. Accolgo con favore commenti / feedback, qualsiasi miglioramento al monitoraggio rende le cose più facili da gestire!

net.core.somaxconn

net.ipv4.tcp_max_syn_backlog

net.core.netdev_max_backlog

$ netstat -an | grep -c SYN_RECV 

Mostrerà il conteggio globale corrente delle connessioni nella coda, è possibile suddividerlo per porta e inserirlo nelle istruzioni exec in snmpd.conf se si desidera eseguire il polling da un'applicazione di monitoraggio.

A partire dal:

netstat -s

Ti mostreranno con quale frequenza visualizzi le richieste dalla coda:

146533724 packets directly received from backlog
TCPBacklogDrop: 1029
3805 packets collapsed in receive queue due to low socket buffer

fs.file-max

A partire dal:

http://linux.die.net/man/5/proc

$ cat /proc/sys/fs/file-nr
2720    0       197774

Questo file (di sola lettura) fornisce il numero di file attualmente aperti. Contiene tre numeri: il numero di handle di file allocati, il numero di handle di file gratuiti e il numero massimo di handle di file.

net.ipv4.ip_local_port_range

Se è possibile creare un elenco di servizi di esclusione (netstat -an | grep LISTEN), è possibile dedurre quante connessioni vengono utilizzate per l'attività effimera:

netstat -an | egrep -v "MYIP.(PORTS|IN|LISTEN)"  | wc -l

Dovrebbe anche monitorare (da SNMP):

TCP-MIB::tcpCurrEstab.0

Potrebbe anche essere interessante raccogliere statistiche su tutti gli stati visti in questo albero (stabilito / time_wait / fin_wait / etc):

TCP-MIB::tcpConnState.*

net.core.rmem_max

net.core.wmem_max

Dovresti rintracciare / rintracciare il tuo sistema per richieste setsockopt. Non credo che le statistiche per queste richieste vengano tracciate diversamente. Questo non è davvero un valore che cambia dalla mia comprensione. L'applicazione che hai distribuito probabilmente richiederà un importo standard. Penso che potresti 'profilare' la tua applicazione con strace e configurare questo valore di conseguenza. (discutere?)

net.ipv4.tcp_rmem

net.ipv4.tcp_wmem

Per monitorare quanto sei vicino al limite dovresti guardare la media e il massimo dai campi tx_queue e rx_queue da (su base regolare):

# cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:0FB1 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262030037 1 ffff810759630d80 3000 0 0 2 -1                
   1: 00000000:A133 00000000:0000 0A 00000000:00000000 00:00000000 00000000   500        0 262029925 1 ffff81076d1958c0 3000 0 0 2 -1                

Per tenere traccia degli errori relativi a questo:

# netstat -s
    40 packets pruned from receive queue because of socket buffer overrun

Dovrebbe anche monitorare il pool globale di "buffer" (tramite SNMP):

HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Memory Buffers
HOST-RESOURCES-MIB::hrStorageSize.1 = INTEGER: 74172456
HOST-RESOURCES-MIB::hrStorageUsed.1 = INTEGER: 51629704

2

Penso che potresti essere in grado di ottenere quei dati con SystemTap. Ecco il manuale di riferimento di Redhat (pdf) . C'è anche una guida per principianti (pdf) .

Lo strumento sembra abbastanza versatile da permetterti di ottenere quei dati, in particolare probe::netdev.rxsembra qualcosa che ti darà informazioni sulle voci in entrata, ora devi "solo" trovare la dimensione netta della coda nel buffer, o qualcosa che conta le cose lasciando la coda ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.