Aumentare net.core.somaxconn farà la differenza?

Ho avuto un argomento sul parametro net.core.somaxconn: mi è stato detto che non cambierà nulla se cambiamo il valore predefinito 128.

Credevo che questa potesse essere una prova sufficiente:

"Se l'argomento backlog è maggiore del valore in / proc / sys / net / core / somaxconn, viene troncato silenziosamente a quel valore" http://linux.die.net/man/2/listen

ma non lo è.

Qualcuno conosce un metodo per testimoniare questo con due macchine, seduto su una rete Gbit? Il migliore sarebbe contro MySQL, LVS, apache2 (2.2), memcached.

L'impostazione net.core.somaxconnsu valori più alti è necessaria solo su server con carico elevato in cui la nuova velocità di connessione è così elevata / elevata che avere connessioni 128 (50% in più in BSD: 128 backlog+ 64 half-open) non ancora accettate è considerato normale. O quando è necessario delegare la definizione di "normale" a un'applicazione stessa.

Alcuni amministratori usano in alto net.core.somaxconnper nascondere i problemi con i loro servizi, quindi dal punto di vista dell'utente sembrerà un picco di latenza invece della connessione interrotta / timeout (controllata da net.ipv4.tcp_abort_on_overflowin Linux).

listen(2)dice manuale - net.core.somaxconnagisce solo al limite superiore per un'applicazione che è libera di scegliere qualcosa di più piccolo (di solito impostato nella configurazione dell'app). Anche se alcune app usano semplicemente il listen(fd, -1)che significa impostare il backlog sul valore massimo consentito dal sistema.

La vera causa è una bassa velocità di elaborazione (ad es. Un singolo server di blocco thread) o un numero insufficiente di thread / processi di lavoro (ad esempio software di blocco multi-processo / thread come apache/ tomcat)

PS. A volte è preferibile fallire rapidamente e consentire al bilanciamento del carico di fare il proprio lavoro (riprovare) piuttosto che far attendere l'utente - a tale scopo impostiamo net.core.somaxconnqualsiasi valore e limitiamo il backlog dell'applicazione ad es. 10E impostiamo net.ipv4.tcp_abort_on_overflowsu 1.

PPS. Le vecchie versioni del kernel Linux hanno un brutto bug di troncare il somaxconvalore a 16 bit inferiori (ovvero lanciare il valore su uint16_t), quindi aumentare quel valore a più di quanto 65535possa persino essere pericoloso. Per ulteriori informazioni, consultare: http://patchwork.ozlabs.org/patch/255460/

Se vuoi entrare in maggiori dettagli su tutti gli interni di backlog in Linux, non esitare a leggere: come funziona il backlog TCP in Linux .