[BSD] listen queue overflows: bron?

[Olaf van der Spek]

Ik heb op een FreeBSD 5.2.1-RELEASE server last van listen queue overflows.

code:

# netstat -sz -p tcp
571 listen queue overflows

Betekent dit dat er 571 keer een queue overflow heeft plaatsgevonden of dat er 571 'SYNs' gedropped zijn?
Is er ergens een log waarin staat op welke port het gebeurd?
En weet iemand wat de default listen queue size is?

[ Voor 11% gewijzigd door Olaf van der Spek op 06-09-2004 21:19 ]

[serkoon]

Als een programma listen() aanroept om te gaan luisteren op een poort, wordt er in de kernel een queue gemaakt voor de door de kernel ontvangen verbindingen die nog niet doorgegeven zijn naar de applicatie (bijv. omdat de app ze niet snel genoeg accepteert). Een overflow wil dus zeggen dat er een verbinding niet geaccepteerd is omdat de queue vol was.

De sysctl kern.ipc.somaxconn schijnt volgens listen(2) de harde kernel limiet te zijn op de queue-lengte, maar grote kans dat de meeste applicaties veel lagere getallen gebruiken dan de blijkbaar standaard 128 (op FreeBSD 5.2-CURRENT van paar weken geleden).

Zou zo niet weten hoe je er achter komt om welke app het gaat, het lijkt me dat het gaat om een app die vrij veel connecties/seconde te verwerken krijgt, bijv apache.. Je zult zelf een beoordeling moeten maken of het aantal niet geaccepteerde verbindingen een groot gedeelte is van het totaal en of het dus zinvol is er wat aan te doen..

[TGEN]

Is er dan niet nog een protocol-afhankelijke limit? In de net.inet*.ip*.* trees?

[Olaf van der Spek]

serkoon schreef op 06 september 2004 @ 23:59:
Zou zo niet weten hoe je er achter komt om welke app het gaat, het lijkt me dat het gaat om een app die vrij veel connecties/seconde te verwerken krijgt, bijv apache.. Je zult zelf een beoordeling moeten maken of het aantal niet geaccepteerde verbindingen een groot gedeelte is van het totaal en of het dus zinvol is er wat aan te doen..

Er draait ook een BitTorrent tracker die 100+ c/s verwerkt, dus dat kan de veroorzaker ook zijn.
128 is niet zo veel, maar dat verhogen is ook weer lastig.

[TGEN]

Err, 'sysctl -w kern.ipc.somaxconn 1024' is toch niet moeilijk?

[Olaf van der Spek]

TGEN schreef op 08 september 2004 @ 17:34:
Err, 'sysctl -w kern.ipc.somaxconn 1024' is toch niet moeilijk?

COMPATIBILITY
The -w option has been deprecated and is silently ignored.

Dit werkt wel:

code:

# sysctl kern.ipc.somaxconn=1024
kern.ipc.somaxconn: 128 -> 1024

Maar in sys/socket.h staat:

code:

#define    SOMAXCONN       128

Een redefine en recompile zijn dus wel nodig?

[ Voor 36% gewijzigd door Olaf van der Spek op 08-09-2004 18:29 ]

[TGEN]

Dat is alleen de default; als je het via sysctl kan aanpassen is een recompile niet nodig. Btw, sorry voor mijn typo's, ik bedoelde inderdaad een '=' ertussen, en omdat ik vaker met Net/Open werk dan Free, de -w er ook bij .

[Olaf van der Spek]

Maar applicaties gebruiken toch SOMAXCONN?
Of wordt die parameter van de listen call genegeerd?

[TGEN]

Dat is toch alleen maar de max uitstaande queues per process? Dat is hier het probleem niet volgens mij, maar meer de som der delen, en dus is de kernel limit de lat. Ik zou zeggen, test t .