Re: TCP... manchmal [lang!]

Jan Muenther <jan(at)radio.hundert6.de> wrote:
> > Kenne Zope nicht, kann dazu nichts sagen. Tippe auf Bug in
> > Zope.
>
> Ich um ehrlich zu sein auch. Recht merkwürdig finde ich auch, daß
> Zope einfach so die Hufe hochreißt, ohne diese Tatsache in sein
> eigenes Logfile zu schreiben geschweige denn dem syslogd bescheid
> zu sagen. Grr.

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.

> > noch die sysctls kern.maxfiles und kern.maxfilesperproc.
> > Evtl. wäre es sinnvoll, letzteres herunterzusetzen, dann
> > kann schonmal kein einzelner Prozeß sämtliche Filedescrip-
> > toren absorbieren.
>
> Stimmt, das scheint sinnvoll. Kann es sein, daß das standardmäßig
> nicht limitiert ist, d.h. Anzahl der maximal von einem Prozeß zu
> belegenden Filedeskriptoren der Anzahl der gesamten
> Filedeskriptoren gleicht?

Richtig. Genau dafür gibt es die Login-classes, siehe die
manpage login.conf(5), und dort speziell das Resource limit
,,openfiles``.

Der sysctl kern.maxfilesperproc ist sozusagen eher die
Holzhammermethode, denn damit begrenzt Du es systemweit für
jeden Prozeß. Mit Login-classes kannst Du es flexibler
einstellen. 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. ;-)

> Ist bei mir nämlich beides 2088...
> Seltsamer Wert, irgendwie hätte ich da eine Zweierpotenz erwartet
> - kannst Du mir sagen, wie die Anzahl sich bildet bzw. errechnen
> läßt?

Aus /sys/conf/param.c:

   #define NPROC (20 + 16 * MAXUSERS)
   #ifndef MAXFILES
   #define MAXFILES (NPROC*2)
   #endif

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

> > Außerdem ist es keine schlechte Idee, per Login-class die
> > Anzahl der Filedescriptopren für Benutzer zu limitieren,
> > und insbesondere auch für bestimmte Daemonen, von denen
> > man genau weiß, daß sie nicht mehr als eine bestimmte An-
> > zahl benötigen sollten.
>
> Spezielle Vorschläge für solche Kandidaten? Wohl insbesondere
> Daemons, von denen auch nur wenige Instanzen laufen sollten, z.B.
> alles, was irgendwie mit Administration zu tun hat...

Nunja, bedenke, daß die Anzahl der Prozesse (oder was
meinst Du mit ,,Instanzen``?) 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.

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. 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.

> Aber
> trotzdem, für ein paar clevere Beispiele wäre ich dankbar, da ich

Es ist schwierig, konkrete Beispiele anzugeben. Wenn Du
z.B. meinst, daß Dein lpd nie mehr als 5 Druckjobs zugleich
handhaben können muß, könntest Du seine openfiles auf 50
oder so begrenzen. Da hast Du noch Sicherheitsspielraum
drin (50 ist mehr, als er für 5 Jobs braucht), und bei 2088
insgesamt verfügbaren FDs kann er das System nicht ernst-
haft durch Fressen von FDs gefährden.

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

Im Zweifelsfall einfach ausprobieren und experimentieren;
das System kontrolliert unter Last setzen und schauen, wie-
viele FDs verbraten werden und wo sie bleiben.

> Hmmm. Es bleibt rätselhaft, da ich icecast erstmal wieder gekillt
> hatte, aber Zope übers Wochenende leider wieder den Dienst
> versagt hat. Der ebenfalls laufende Apache blieb unbeeindruckt.

Der Apache ist relativ robust, was diese Art von Problemen
betrifft. Selbst wenn seine Childprozesse deswegen ster-
ben (was sie nicht tun sollten), forkt er einfach wieder
neue, wenn neue Anfragen kommen. Und der Parent-Prozeß
belegt eine konstante Anzahl von FDs, die er sich gleich
beim Starten holt.

> > de ich als nächstes mal die MBufs im Auge behalten (siehe
> > ,,netstat -m``).
>
> Sieht ebenfalls (im Augenblick) recht entspannt aus. 133
> augenblicklich, 208 Peak (in welchem Zeitraum eigentlich?), 6144
> maximal...

Das sieht in der Tat entspannt aus.

> jetzt gerade noch einmal alle Daemons angefeuert habe, die
> Clients, die da waren, wieder angemeldet und die verbrauchten
> Filedeskriptoren bleiben stabil bei 188...

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 unterschreibe ich sofort. Aber abhängig von der Konfiguration
> von Client und Daemon kann man natürlich unterschiedliches
> erreichen - außerdem hilft nix gegen dämliche User, die bei
> Warnungen einfach auf Enter hauen und auf Gott vertrauen.

Und dann sofort vom Blitz getroffen werden sollten. Das
größte Sicherheitsrisiko ist, wie so oft, der Mensch ...

> 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. :-)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message