Tuning dei parametri di routing IP Linux – secret_interval e tcp_mem

Abbiamo avuto un piccolo problema di failover con uno dei nostri HAProxy VM oggi. Quando abbiamo scavato in esso, abbiamo trovato questo:

 Jan 26 07:41:45 haproxy2 kernel: [226818.070059] __ratelimit: 10 richiamati soppressi
 Jan 26 07:41:45 haproxy2 kernel: [226818.070064] fuori dalla memory dello slot
 Jan 26 07:41:47 haproxy2 kernel: [226819.560048] Fuori dalla memory di socket
 Jan 26 07:41:49 haproxy2 kernel: [226822.030044] fuori dalla memory di socket

Quale, per questo collegamento , apparentemente ha a che fare con impostazioni di default basse per net.ipv4.tcp_mem . Quindi li abbiamo aumentati di 4 volte dai loro valori predefiniti (questo è Ubuntu Server, non è sicuro se il sapore di Linux sia importnte):

  • Routing basato su port Linux usando il path iptables / ip
  • File scarsamente più grandi (ma ancora scarsi) dopo la copia su una networking
  • Crea un server di file a bassa potenza
  • Qual è la differenza tra apachectl e httpd.worker?
  • Come specificare HELO in output con sendmail?
  • Strumento di backup di file open source per linux
  •  i valori correnti sono: 45984 61312 91968
     i nuovi valori sono: 183936 245248 367872
    

    Dopo di che, abbiamo iniziato a vedere un messaggio di errore bizzarro:

     Jan 26 08:18:49 haproxy1 kernel: [2291.579726] La catena di hash per strada è troppo lunga!
     Jan 26 08:18:49 haproxy1 kernel: [2291.579732] Regola il tuo secret_interval!
    

    Shh .. è un segreto !!

    Questo apparentemente ha a che fare con /proc/sys/net/ipv4/route/secret_interval che imposta il valore predefinito a 600 e controlla la /proc/sys/net/ipv4/route/secret_interval periodica della cache di path

    Il secret_interval indica al kernel quanto spesso spazzare via TUTTE le voci di hash di itinerario, indipendentemente da come sono nuove / vecchie. Nel nostro ambiente questo è generalmente cattivo. La CPU sarà impegnata a ribuild migliaia di voci al secondo each volta che la cache viene eliminata. Tuttavia abbiamo impostato questo per eseguire una volta al giorno per mantenere la perdita di memory a bada (anche se non abbiamo mai avuto uno).

    Mentre siamo lieti di ridurlo, sembra strano consigliare di abbandonare l'integer cache di path a intervalli regolari , piuttosto che semplicemente spingere vecchi valori dalla cache di path più velocemente.

    Dopo alcune indagini, abbiamo trovato /proc/sys/net/ipv4/route/gc_elasticity che sembra essere un'opzione migliore per mantenere la dimensione della tabella di path controllata:

    gc_elasticity può essere meglio descritta come la profondità media della benna che il kernel accetterà prima di iniziare a scadere le voci di hash di path. Ciò contribuirà a mantenere il limite superiore dei routes attivi.

    Abbiamo aggiustato l'elasticità da 8 a 4, sperando che la cache della corsia sia più aggressiva. L' secret_interval non ci sembra corretto. Ma ci sono un sacco di impostazioni e non è chiaro che sono veramente il modo giusto per andare qui.

    • / proc / sys / net / ipv4 / itinerario / gc_elasticità (8)
    • / proc / sys / net / ipv4 / path / gc_interval (60)
    • / proc / sys / net / ipv4 / path / gc_min_interval (0)
    • / proc / sys / net / ipv4 / path / gc_timeout (300)
    • / proc / sys / net / ipv4 / path / segreto_intervallo (600)
    • / proc / sys / net / ipv4 / path / gc_thresh (?)
    • rhash_entries (parametro del kernel, ignoto di default?)

    Non vogliamo rendere peggiorare il routing di Linux, quindi abbiamo paura di confondere alcune di queste impostazioni.

    Può qualcuno informare quali parametri di routing sono meglio sintonizzarsi, per un'istanza HAProxy di traffico elevato?

  • Errore di errore: "Nessun spazio rimasto sul dispositivo" per un determinato nome di file
  • authorization negata su keys_authenticated
  • Creare manualmente dnscache.txt per AWStats
  • Informazioni sul monitoraggio delle connessioni in iptables
  • Intestazioni di errore: ap_headers_output_filter () dopo aver messo l'intestazione della cache nel file htaccess
  • Perché apache rallenta durante la notte?
  • 3 Solutions collect form web for “Tuning dei parametri di routing IP Linux – secret_interval e tcp_mem”

    Non ho mai incontrato questo problema. Tuttavia, si dovrebbe probabilmente aumentare la width della tabella hash per ridurne la profondità. Utilizzando "dmesg", vedrai quante voci attualmente hai:

     $ dmesg | grep '^IP route' IP route cache hash table entries: 32768 (order: 5, 131072 bytes) 

    È ansible modificare questo valore con il parametro rhash_entries row di command di avvio del kernel. Innanzitutto provalo a mano quindi aggiungilo al tuo lilo.conf o grub.conf .

    Ad esempio: kernel vmlinux rhash_entries=131072

    È ansible che tu abbia una tabella hash molto limitata perché hai assegnato poco memory al tuo HAProxy VM (la dimensione del hash route viene regolata in base alla RAM totale).

    Per tcp_mem riguarda tcp_mem , attenzione. Le impostazioni iniziali mi fanno pensare che fosse in esecuzione con 1 GB di RAM, di cui 1/3 potrebbe essere assegnato alle prese TCP. Ora avete assegnato 367872 * 4096 bytes = 1.5 GB di RAM alle prese TCP. Devi essere molto attento a non esaurire la memory. Una regola generale è quella di assegnare 1/3 della memory a HAProxy e un altro 1/3 allo stack TCP e l'ultimo 1/3 al resto del sistema.

    Sospetto che il tuo messaggio "fuori dal socket memory" deriva dalle impostazioni predefinite in tcp_rmem e tcp_wmem . Per impostazione predefinita si dispone di 64 kB allocati in output per ciascun socket e 87 kB in ingresso. Ciò significa un totale di 300 kB per una connessione proxied, solo per buffer di socket. Aggiungi a questo 16 o 32 kB per HAProxy e vedrai che con 1 GB di RAM supporterai solo 3000 connessioni.

    Cambiando le impostazioni predefinite di tcp_rmem e tcp_wmem (parametro medio), è ansible get molto less sulla memory. Ottengo buoni risultati con valori inferiori a 4096 per il buffer di scrittura e 7300 o 16060 in tcp_rmem (5 o 11 segmenti TCP). È ansible modificare queste impostazioni senza riavviare, ma si applicano solo a nuove connessioni.

    Se preferisci non toccare troppo il tuo sysctls , l'ultima versione di HAProxy 1.4-dev8 ti permette di modificare i parametri dalla configuration globale e dal lato (client o server).

    Spero che questo aiuti!

    L' Out of socket memory error è spesso fuorviante. La maggior parte del tempo, sui server che si affacciano sul Internet, non indica alcun problema relativo all'esplosione della memory. Come ho spiegato in più dettagli in un post sul blog , il motivo più comune è il numero di prese orfane. Una presa orfana è una presa che non è associata a un descrittore di file. In certe circostanze, il kernel emetterà l' Out of socket memory error anche se sei di 2 o 4 volte lontano dal limite ( /proc/sys/net/ipv4/tcp_max_orphans ). Ciò accade frequentemente nei servizi rivolti verso Internet ed è perfettamente normale. Il giusto corso d'azione in questo caso è quello di ottimizzare tcp_max_orphans per essere alless 4 volte il numero di orfani che normalmente vedete con il tuo traffico di picco.

    Non ascoltare alcun consiglio che consiglia di sintonizzare tcp_mem o tcp_rmem o tcp_wmem less che tu non conosca veramente quello che stai facendo. Quelli che danno questi consigli in genere non lo fanno. Il loro voodoo è spesso sbagliato o inappropriato per il tuo ambiente e non risolverà il tuo problema. Potrebbe anche rendere peggio.

    Noi sintonizziamo regolarmente alcuni di questi parametri. Il nostro standard per le piattaforms di trading a bassa latenza e ad alto rendimento è:

     net.ipv4.tcp_rmem = 4096 16777216 33554432
     net.ipv4.tcp_wmem = 4096 16777216 33554432
     net.ipv4.tcp_mem = 4096 16777216 33554432
     net.core.rmem_default = 16777216
     net.core.wmem_default = 16777216
     net.core.rmem_max = 16777216
     net.core.wmem_max = 16777216
     net.core.netdev_max_backlog = 30000
     net.core.netdev_max_backlog = 30000
    
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.