On Mon, 21 Oct 2002 20:09:54 +0200, Josef Spillner wrote:
Ich hab mir folgende Server angeschaut:
- Apache
Standardmäßig nur 256 Verbindungen möglich, skaliert nicht von selbst
Zahl maximal offender FDs zu erhöhen sollte elfen. Was bedeutet "skaliert nicht von selbst"
- Dancer IRCd
Auch hier nur 256 Verbindungen, auf openprojects.net bis zu 4096, skaliert aber ebenfalls nicht von selbst
Das Problem besteht aus 2 Teilen:
- zum einen die geringe Anzahl offener Dateien pro Prozess Unix/Linux: meist 256-1024 (zwar kann man das bei Linux über /proc einstellen, aber das erfordert root-Rechte, und es gibt noch ulimit und /etc/security/limits.conf.)
Dann schreibs in ein initskipt oder setzte den default im Kernel höher.
Netware: 2048 Hurd: unbegrenzt
Unbegrenzte Dinge klingen zwar nett, bringen aber jedesmal eine Möglichkeit mehr, den Server klein zu bekommen.
- 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.
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).
Es gibt genug Verbesserungen für select, für Linux gibts einen Patch, der das von Solaris abgeguckte /dev/poll anbietet, kqueue bei FreeBSD ist eine andere Variante (-->google)
- Aufteilung der Clients an Kindprozesse (möglichst transparent), so daß
praktisch durchaus 100000 Clients gehandhabt werden können.
100000 ist wirklich sehr viel. Das bleiben bei Anbindung per 1GBit/s pro client keine 2 kbyte/s mehr.
Gibt es irgendwo Dokumentation zu speziell diesem Thema?
Zu select/poll-Verbesserungen gibts viel lesbares im Web. Suche mal nach /dev/poll. Interessant als Einstieg ist http://www.kegel.com/c10k.html
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.
Ist halt die einfachste Variante ohne das Serverprogramm anzufassen.
Threads helfen auch nicht weiter: Diese sind zwar auf Linux als eigene Prozesse implementiert, aber das Limit gilt trotzdem für alle zusammen.
Ich bin bisher auch kein Fan von Threads, wenn es nicht unbedingt nötig ist. Auf 1-CPU-Kisten sehe ich dafür wenig Sinn. Die Java-Krankheit mit ein Thread pro Netzverbindung hat IMO die große Threadwelle losgetreten. Irgendwie mußte der fehldesignte Kram ja noch schnell zu bekommen sein.
In linux 2.5 ist wohl gerade NTPL (native posix thread library, molnar+ drepper?) in Arbeit. Ich habe das nicht weiter verfolgt, nur gelesen, daß damit zig tausend Threads pro Sekunde(!!!) erzeugbar sind. Selbst die KSE-Leute von FreeBSD sollen wohl Respekt gezollt haben. KSE wird immer so als ein Killerfeature in FreeBSD-5 verkauft. Irgendwie scheinen schnelle, schlanke Threads richtig wichtig zu werden.
Vielleicht macht mal jemand einen Vortrag über all die Varianten ;-)
Reinhard