Re: TCP... manchmal [lang!]

> Nunja, wenn es tatsächlich an einem akuten Mangel an File-
> descriptoren liegt, ist das durchaus erklärlich. Auch um
> eine syslog-Message loszuwerden braucht man einen FD.

Das scheint in der Tat logisch... Sehe ich das aus
Programmiersicht richtig, daß jedesmal, wenn ich ein Filehandle
brauche, OS-seitig dafür ein Deskriptor verbraten wird, bis ich
das Handle wieder schließe???
 
> Richtig. Genau dafür gibt es die Login-classes, siehe die
> manpage login.conf(5), und dort speziell das Resource limit
> ,,openfiles``.

Hmpf. Manpages lesen. Wie immer kein Fehler.
 
> Man kann natürlich beides kombinieren, sozusa-
> gen Login-classes als Gurt und Airbag, und maxfilesperproc
> wäre dann die Knautschzone -- und maxfiles ist die Beton-
> wand hinter der Knautschzone. ;-)

Ha! Belt-and-suspenders! Liegt mir ohnehin :o))
 
> #define NPROC (20 + 16 * MAXUSERS)

> Bei maxusers 64 macht das (20 + 16 * 64) * 2 == 2088, wenn
> mich /usr/bin/bc jetzt nicht anlügt.

Ah! Habe natürlich wieder mal an der völlig falschen Stelle
geschaut... tsts... Trotzdem ulkige Werte, aus denen sich das
zusammensetzt... 20?

> Nunja, bedenke, daß die Anzahl der Prozesse (oder was
> meinst Du mit ,,Instanzen``?)

Ja, na klar. Meinte halt, wenn ein Service mehrfach gestartet ist
(z.B. wegen mehrerer parallel laufender TCP-Verbindungen) - ist
jedesmal im Prinzip dasselbe Programm, wird aber natürlich
jeweils gesondert gehandlet, wobei man natürlich auch fork() etc.
im Hinterkopf behalten muß... Aber natürlich hat man dann jeweils
einen eigenen Prozeß, klar. Also ja, das meinte ich ;o))

> nicht unbedingt einen Rück-
> schluß darauf zuläßt, wieviele Filedescriptoren gebraucht
> werden. Bestes Beispiel wäre Squid: nur ein Prozeß, aber
> er braucht höllisch viele FDs.

Wobei man da auch bei der Konfiguration der Anwendung selbst
Grenzen setzen kann, wenn ich mich recht an das makefile
erinnere...

> Jede offene Datei und jeder offene Socket (d.h. jede Netz-
> werkverbindung, aber auch bereits dann, wenn der daemon nur
> lauscht, aber noch keine Verbindung da ist) braucht einen
> FD. Jede Pipe, auch stdin/stdout/stderr.

_Das_ kann ja aber ganz schön hart werden, oder??? Ich meine,
selbst wenn man nichts in den Logfiles findet, erwartet man bei
einem fatalen Fehler ja irgendwie, das er sich doch auf der
Konsole bemerkbar macht - was er dann ja schlichtweg nicht kann.
Gruselig, die Vorstellung, wenn man nicht weiß, wodran es liegen
könnte.

> Viele Library-
> calls verwenden intern Dateien oder Sockets und ,,verstek-
> ken`` daher die Tatsache, daß sie auf FDs angewiesen sind,
> z.B. syslog() (siehe oben), gethostbyname() etc.

Hm, meinst Du damit, daß durch den Aufruf von Library-Calls durch
die aufgerufenen Funktionen wiederum FDs verbraten werden und auf
diese Weise mehr davon verbraucht werden als man bei der
Entwicklung des Programms selbst unmittelbar denkt?? Scheint mir
schlüssig.

Kann man denn irgendwie feststellen, welcher Prozeß wieviele FDs
an sich klammert? systat? Erwischt man mit lsof in jedem Fall
_alle_ ???

> Das nur so als Beispiel. Der lpd ist nicht dafür bekannt,
> daß er solche Unannehmlichkeiten macht. ;-)

Und wenn schon, brauche ich eh nur auf meinem eigenen Rechner
;o))
 
> Im Zweifelsfall einfach ausprobieren und experimentieren;
> das System kontrolliert unter Last setzen und schauen, wie-
> viele FDs verbraten werden und wo sie bleiben.

Tja, der Witz ist bloß, daß das Phänomen gerade wieder
aufgetreten ist und - zumindest nachdem mir der Login dann
gelungen war, gerade mal 80 Filehandles in Benutzung waren.
Möglich wäre natürlich, daß der Bug sich eben gerade so zeigt,
daß in einer Sekunde (oder einem Tick oder whatever) tierisch
viele FDs benötigt werden, in der nächsten aber alles schon
wieder hoopy und froody ausschaut. Werde mal in einem Xterm ein
Skript in Endlosschleife laufen lassen...

> > versagt hat. Der ebenfalls laufende Apache blieb unbeeindruckt.

> neue, wenn neue Anfragen kommen. Und der Parent-Prozeß
> belegt eine konstante Anzahl von FDs, die er sich gleich
> beim Starten holt.

D.h. sobald der Parentprozeß wieder FDs zur Verfügung hat, kann
er wieder forken und neue aufmachen, wodurch man, wenn das
Problem nur kurz auftaucht, beim Apache überhaupt nix merkt.
Klingt logisch. Mann, woher weißt du das alles? ;o))
 
> Wie gesagt, es kann ein Bug in einem der Programme sein,
> das dann irgendwann Amok läuft, oder das unter bestimmten
> Bedingungen schlicht und ergreifend ,,vergißt``, einmal
> geöffnete Dateien wieder zuzumachen.

Das wird's sein. In einem Moment gierig, im nächsten
superbescheiden. Kenne ich irgendwoher.
 
> > Danke nochmals für die ausführliche Antwort und sorry für das
> > lange Posting,
>
> Das mit der Länge lassen wir gerade nochmal durchgehen ...
> Ein Byte mehr, und die deutschen Backbones wären ernsthaft
> in Gefahr gewesen, zu verstopfen. :-)

Ooch, das schaffen wir schon. Ich werde mal in Zukunft alles
schön als HTML UND plain text schicken, das ist soundso immer
wieder gern gesehen. Und eine 20-Zeilen Signatur schaffe ich auch
noch. Daran verschlucken sich dann zumindest Echelon, Carnivore
und MS Exchange ;o))

Schönen Dank auch für die Erziehung des Menschengeschlechts...

Ciao, Jan

-- 
Radio HUNDERT,6 Medien GmbH Berlin
- EDV -
j.muenther(at)radio.hundert6.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message