Re: Viele Sockets in "CLOSING", delayed_ack?

Moin,

soweit ich weiß, entspricht "CLOSING"
dem Zustand, in dem Dein Rechner aktiv die Verbindung
mit einem FIN abbauen will, daraufhin von der Gegenstelle
ebenfalls ein FIN erhält, der GgSt ein ACK auf deren
FIN sendet und nun noch auf ein ACK auf das selbst
gesendete FIN wartet.

Ich weiß nicht, wie das in BSD kodiert ist, aber,
gesetzt den Fall, das ACK auf das selbst gesendete
FIN ginge verloren oder der Code wäre in BSD falsch,
müßte eigentlich die Frage sein, ob aus dem Zustand
CLOSING auch über ein Timeout entkommen werden kann.

Dann müßte man nur noch sehen, wie groß das Timeout
ist.

Bevor man zu tief in die Programmierung einsteigt,
würde ich Dir vorschlagen, daß Du Deine Skripte
so umschreibst, daß sie automatisch
1) zählen, wie viele CLOSING sockets da sind.
2) zählen, wie viele ESTABLISHED sind
3) versuchen nachzusehen, wann sockets aus CLOSING entlassen werden,
   indem sie z.B. die Zieladresse der CLOSINGs abspeichern
   und periodisch vergleichen.
4) einen reboot auslösen, wenn die Anzahl der nichtaktiven
   Sockets größer als ? wird (ist brutal, aber wenns geht...)

Damit könnte man die Fragen halbautomatisch klären lassen,
bis vielleicht aus newsgroups oder aus dem Quellkode die
Fragen beantwortet werden.

Gruß
TITUS

Olaf Hoyer wrote:
>
> At 06:28 09.02.00 +0100, you wrote:
> >Ich schrieb:
> > > [...]
> > > Mit einem kleinen Script beobachte ich die Sockets (prinzipiell
> > > netstat -an plus sort und uniq -c). Dabei fällt mir eine lang-
> > > sam zunehmende Anzahl von "CLOSING" auf. Im Moment gerade
> > > (23:15 abends) sieht es so aus:
> > >
> > > 356 CLOSING
> > > 292 TIME_WAIT
> > > 111 ESTABLISHED
> > > 110 FIN_WAIT_2
> > > 13 FIN_WAIT_1
> > > 8 LISTEN
> > > 3 SYN_SENT
> > > 2 LAST_ACK
> >
> >Jetzt, ein paar Tage später, morgens früh um 6:20:
> >
> > 784 CLOSING
> > 84 TIME_WAIT
> > 75 ESTABLISHED
> > 23 FIN_WAIT_2
> > 13 CLOSE_WAIT
> > 8 LISTEN
> > 5 SYN_SENT
> > 4 LAST_ACK
> > 2 FIN_WAIT_1
> > 1 SYN_RCVD
> >
> >Sieht nicht gut aus; die "closing"-Sockets sammeln sich immer
> >mehr an. :-(
> >Hat wirklich keiner eine Idee, was das sein könnte, und was man
> >dagegen tun könnte? Ich fänd es ausgesprochen besch***en, die
> >Kiste deswegen einmal pro Woche zu rebooten oder so... :-(
>
> Moin!
>
> Ok, ich habe mich noch nicht tiefer mit den Details der
> Netzwerkprogrammierung beschäftigt (was ich schon seit zwei Jahren mal tun
> wollte ;-( ), aber habe da folgenden Gedanken:
>
> Ein Socket wird ja aufgemacht, tut etwas/es wird etwas mit ihm getan, dann
> wartet er evtl. mal auf Daten, die rüberkommen. Dabei müßte er ja auch
> entsprechende Timeouts bekommen, wenn er längere Zeit nicht gebraucht wird.
> Und irgendwann wird er eben wieder geschlossen.
>
> wenn man sich obige Figuren mal ansieht, so stellt man fest, daß die
> "Summe" der Sockets ungefähr übereinstimmt. Theorie: Die Kiste tut einiges,
> und nach einiger Zeit beginnt der Aufräumprozess, wenn gerade mal wenig zu
> tun ist, so daß alle Sockets, die gerade mal zu lange nix getan haben, denn
> mal geschlossen werden.... (So ne Art Garbage Collection).
> Abends haben die Kisten wohl noch zu reißen (Nehme an, die Kiste ist ein
> Netzwerkserver/Internet), und morgens, wenn wirklich nix mehr anliegt,
> beginnt sie aufzuräumen...
>
> Obige Figuren zeigen ja auch, daß die Zahl von Sockets, die was tun/warten,
> morgens enorm abgenommen hat, diese werden wahrscheinlich gerade geschlossen.
>
> OK, wie gesagt, in die Tiefen der Netzwerke bin ich noch nicht
> heruntergestiegen, wäre aber zahlenmäßig eine Idee.
>
> Mfg
> Olaf Hoyer
> --------
> Olaf Hoyer www.nightfire.de mailto:Olaf.Hoyer(at)nightfire.de
> FreeBSD- Turning PC's into workstations ICQ:22838075
>
> Liebe und Hass sind nicht blind, aber geblendet vom Feuer,
> dass sie selber mit sich tragen. (Nietzsche)
>
> To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 09 Feb 2000 - 13:37:40 CET