-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 21 October 2002 20:09, Josef Spillner wrote:
gibt es irgendwo in der Linux-Welt Server, die gleichzeitig eine hohe Anzahl an Clients bedienen müssen, ohne dabei einzugehen?
Ich hab mir folgende Server angeschaut:
- Apache
Standardmäßig nur 256 Verbindungen möglich, skaliert nicht von selbst
Mit Standard laesst sich nunmal nicht viel machen. Wenn Du die Anzahl der Apache-Prozesse und die Anzahl der erlaubten Verbindungen hochschraubst sollte es gehen.
Das Problem besteht aus 2 Teilen:
- zum einen die geringe Anzahl offener Dateien pro Prozess Unix/Linux: meist 256-1024
Kann man konfigurieren (/proc/irgendwas)
- Zum anderen an der Art der Event-Abfrage Beide oben genannten Server, und auch die meisten anderen, nutzen
select() und bekommen damit massiv Latenzprobleme, wenn z.B. alle Clients sich verabschiedet haben und nur noch an n-1 ter Position einer steckt.
Nimm poll.
Es gibt jetzt 2 Möglichkeiten, das Problem zu lösen:
- Einen eigenen select()-Handler programmieren, welcher eine Liste statt
ein Array verwendet (löst aber nur einen Teil des Problems).
Trotzdem muss der Kernel bei jedem select noch auswerten auf was überhaupt selected wird. Das kann bei 10000 Verbindungen schon erhebliche Ressourcen in Anspruch nehmen.
- Aufteilung der Clients an Kindprozesse (möglichst transparent), so daß
praktisch durchaus 100000 Clients gehandhabt werden können.
Dieser Ansatz wird von den meisten grossen Servern genommen (z.B. Apache).
Gibt es irgendwo Dokumentation zu speziell diesem Thema? Auf den üblichen Hilfeseiten wird immer empfohlen, /proc/sys/fs/file-max mit hohen Werten zu füttern, aber das hat die oben genannten Nachteile.
Suche mit google mal nach dem Mailthread "poll vs. select" (oder so ähnlich) in der Linux-Kernel-Liste. Dieses Problem wurde noch vor dem 2.4er angegangen.
Threads helfen auch nicht weiter: Diese sind zwar auf Linux als eigene Prozesse implementiert, aber das Limit gilt trotzdem für alle zusammen.
Logisch, sie teilen sich ja alle Systemressourcen (ausser Thread-ID und Stack), also auch alle Filedeskriptoren.
Konrad