Hallo,
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 - 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.) Netware: 2048 Hurd: unbegrenzt - 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). - Aufteilung der Clients an Kindprozesse (möglichst transparent), so daß praktisch durchaus 100000 Clients gehandhabt werden können.
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.
Threads helfen auch nicht weiter: Diese sind zwar auf Linux als eigene Prozesse implementiert, aber das Limit gilt trotzdem für alle zusammen.
Josef
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
On Tue, Oct 22, 2002 at 12:04:41AM +0200, Reinhard Foerster wrote:
Hurd: unbegrenzt
Unbegrenzte Dinge klingen zwar nett, bringen aber jedesmal eine Möglichkeit mehr, den Server klein zu bekommen.
Genau, wenn der Server dafür nicht sehr schlau geschrieben ist, kann man binnen 1/2h ein Programm zum "DOSen" bauen. Dafür braucht man noch nicht mal die ganz dicke Netzanbindung, da man keinen Traffic sondern viele Prozesse auf Serverseite will.
- 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.
Denk mal in eine andere Richtung als HTTP, IRC und Co. Stichwort Flugbuchungssysteme, PPS in sehr großen Firmen etc. Da sind zwar sehr viele Verbindungen offen, aber die greifen nicht alle gleichzeitig Daten ab.
Ich bin bisher auch kein Fan von Threads, wenn es nicht unbedingt nötig ist.
"Richtige" Threads sind zumindest zur Laufzeit billiger als Prozesse.
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.
Naja, viele Leute wissen gar nicht warum sie unbedingt Threads brauchen, das Thema ist nur z.Z. ziemlich sexy...
Eric
On Sat, 26 Oct 2002 12:28:03 +0200, Eric Schaefer wrote:
- 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.
Denk mal in eine andere Richtung als HTTP, IRC und Co. Stichwort Flugbuchungssysteme, PPS in sehr großen Firmen etc. Da sind zwar sehr viele Verbindungen offen, aber die greifen nicht alle gleichzeitig Daten ab.
Solche Low-Traffic-"Verbindungen" für wahnsinnig viele, eher sporadisch kommunizierende Clients würde man vermutlich mit UDP + Bestätigungsnachrichten besser realisieren können, so in Richtung Message Queuing. Der Overhead durch TCP wäre sonst größer als der Payload, von den verschwendeten Ressourcen fürs Verwalten der TCP-Verbindungen auf dem Server ganz zu schweigen. Bei der Lösung brauch man für den Netzwerkteil der Serveranwendung gar keine Threads oder irgendwelches Multiplexen von Verbindungen. Das Serverprogramm schaut sich nur grob an, wozu das eintreffende Paket dient und reicht es dann zur eigentlichen Verarbeitung an einen von mehreren langlaufenden Prozessen weiter.
Reinhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 27 October 2002 08:06, Reinhard Foerster wrote:
On Sat, 26 Oct 2002 12:28:03 +0200, Eric Schaefer wrote:
Denk mal in eine andere Richtung als HTTP, IRC und Co. Stichwort Flugbuchungssysteme, PPS in sehr großen Firmen etc. Da sind zwar sehr viele Verbindungen offen, aber die greifen nicht alle gleichzeitig Daten ab.
Solche Low-Traffic-"Verbindungen" für wahnsinnig viele, eher sporadisch kommunizierende Clients würde man vermutlich mit UDP + Bestätigungsnachrichten besser realisieren können, so in Richtung Message Queuing. Der Overhead durch TCP wäre sonst größer als der Payload, von den verschwendeten Ressourcen fürs Verwalten der TCP-Verbindungen auf dem Server ganz zu schweigen.
Um die Schwächen von UDP (verbindungslos, keine Garantie für Paketlieferung, keine Garantie der Reihenfolge, etc.) willst Du in einer Produktionsumgebung definitiv nicht herumarbeiten! In Produktion lässt Dir niemand die notwendige Zeit, um solche Protokolle auszutesten. Andererseits sind Ressourcen dort nicht das primäre Problem (Du musst nur oft genug betonen, dass es um Produktion geht).
Overhead hast Du bei diesen Systemen sowieso, da stört der TCP-Anteil nicht mehr.
Bei der Lösung brauch man für den Netzwerkteil der Serveranwendung gar keine Threads oder irgendwelches Multiplexen von Verbindungen. Das Serverprogramm schaut sich nur grob an, wozu das eintreffende Paket dient und reicht es dann zur eigentlichen Verarbeitung an einen von mehreren langlaufenden Prozessen weiter.
Also muss das Serverprogramm die Ressourcen (=Verbindungen) intern verwalten, entsprechende Timeouts verwalten, Nachrichten per Message Passing weiterleiten etc.pp. Zusätzlich müssen Client und Server noch Packet-Repeat (inclusive Erkennung von repeated Packets) und diverse andere Algorithmen implementieren, die eigentlich TCP übernehmen könnte - und das alles zusätzlich zu ihrer eigentlichen Aufgabe.
Das Entwicklungsbudget für dieses PPS will ich genehmigt sehen!
Bei PPS sprechen wir über 500-5000 gleichzeitige Verbindungen zum Server, integriertem Failover, Transaktionssicherung (nein, das hat diesmal nix mit Datenbanken zu tun) und erheblichen Kosten, wenn auch nur einige Kleinigkeiten schiefgehen. Da will man so wenig wie möglich selbst implementieren (schon weil die zusätzlichen Tests ein Vielfaches der Entwicklungszeit verschlingen).
Konrad
On Sun, Oct 27, 2002 at 10:54:29AM +0200, Konrad Rosenbaum wrote:
Bei PPS sprechen wir über 500-5000 gleichzeitige Verbindungen zum Server, integriertem Failover, Transaktionssicherung (nein, das hat diesmal nix mit Datenbanken zu tun) und erheblichen Kosten, wenn auch nur einige Kleinigkeiten schiefgehen. Da will man so wenig wie möglich selbst implementieren (schon weil die zusätzlichen Tests ein Vielfaches der Entwicklungszeit verschlingen).
Wetten, daß ich das toppen kann?
NT-Server und Anbindung der Nutzer per (schwache Naturen bitte nicht weiterlesen) Citrix. Teilweise per VPN via Standleitung (ca. 25 Nutzer über 128kbit). Da stellt sich die Frage nach UDP vs. TCP gar nicht. *kübel*
Ich bin gerade dabei, unseren Admin heiß zu machen, daß er mal mit Cross-Over-Office-Server spielt, da könnte man dann auch viel leichter alternative SW anbieten und so das MS-Regime langsam unterwandern. Hintergrund: Diverse Programme sollen nicht auf allen Rechnern installiert sein, weil sie dort nicht oft gebraucht werden und damit auch nur eine geringere Anzahl an Lizenzen nötig ist.
Langsam komme ich mir vor wie ein Evangelist. Vor einiger Zeit hat der Admin nach einer Dialup-Server Variante für zu Hause gesucht. Da hab ich ihn auf fli4l aufmerksam gemacht. Seitdem werden alle Einwahlrechner bei Kundenanlagen mit eben diesem bestückt. Er spielt jetzt auch ab und zu mit SuSE rum und ist schon so weit, daß er Yast (1) nur für die Installation nutzt. Alles andere macht er händisch... Sowas nennt man schleichende Infiltration... ;-)
Eric
On Sun, 27 Oct 2002 10:54:29 +0200, Konrad Rosenbaum wrote:
Solche Low-Traffic-"Verbindungen" für wahnsinnig viele, eher sporadisch kommunizierende Clients würde man vermutlich mit UDP + Bestätigungsnachrichten besser realisieren können, so in Richtung Message Queuing. Der Overhead durch TCP wäre sonst größer als der Payload, von den verschwendeten Ressourcen fürs Verwalten der TCP-Verbindungen auf dem Server ganz zu schweigen.
Um die Schwächen von UDP (verbindungslos, keine Garantie für Paketlieferung, keine Garantie der Reihenfolge, etc.) willst Du in einer Produktionsumgebung definitiv nicht herumarbeiten! In Produktion lässt Dir niemand die notwendige Zeit, um solche Protokolle auszutesten.
Hier im Thread ging es vermutlich erstmal nur um die technische Machbarkeit. Bei den von Joseph gewünschen 100k clients kommt man nicht umhin, neue Wege zu gehen und etwas neues zu bauen. Es ist wenig sinnvoll über mangelde Zeit bei der Produktentwicklung zu reden, wenn noch nichtmal die fürs Produkt nötige Technologie vorhanden ist. Wirtschaftlich zu denken ist ja nett, dazu gehört aber auch eine F+E-Phase. Sowas kostet Zeit und Geld (Echte Zeit, nicht nur beliebig parallelisierbare Mannjahre)
Andererseits sind Ressourcen dort nicht das primäre Problem (Du musst nur oft genug betonen, dass es um Produktion geht).
Ich kann 10 mal laut schreien "Es geht um Produktion". Davon wird die gewünschte Anwendung trotzdem nicht einfacher realisierbar. Bei 100k clients muß man sich sehr genau überlegen, wohin man die CPU-Power steckt. Von der CPU mit 2 GHz im Server bleibt bei (idealistischer) Aufteilung auf 100k pro clients eine 20 KHz-CPU, die einen Client zu versorgen hat. Da mußt du den CPUs so viel wie möglich Arbeit abnehmen.
Overhead hast Du bei diesen Systemen sowieso,
Wie meinst du das? Du meinst, der Rest des Systems ist sowieso Schei*e implemntiert, weshalb man sich bei der Netzanbindung auch keine Mühe mehr geben muß?
da stört der TCP-Anteil nicht mehr.
TCP ist nicht so easy. Für jede Verbindung fällt einiges an Aufwand für die virtuellen 20 kHz-CPUs an.
Bei der Lösung brauch man für den Netzwerkteil der Serveranwendung gar keine Threads oder irgendwelches Multiplexen von Verbindungen. Das Serverprogramm schaut sich nur grob an, wozu das eintreffende Paket dient und reicht es dann zur eigentlichen Verarbeitung an einen von mehreren langlaufenden Prozessen weiter.
Also muss das Serverprogramm die Ressourcen (=Verbindungen) intern verwalten, entsprechende Timeouts verwalten, Nachrichten per Message Passing weiterleiten etc.pp.
Genau. Nur so kann man sich daraf beschränken, lediglich das zu tun, was unbedingt nötig ist. Das Serverprogramm wird beispielsweise sowieso intern eine tabelle aller zur zeit Verbunden Clients halten müssen. Warum sollte ich so eine Info nochmal redundant in der Netzwerkschicht mitführen? Dinge wie die Flußkontrolle von TCP sind völlig sinnlos, wenn nur ab und zu mal ein paar Pakete über die Leitung gehen. Die Checksummen im Header sind ebenfalls unsinnig. Die wird zwar bei GB-Ethernet zum Glück in Hardware gemacht, vergrößert aber unnötigerweise die Übertragungszeit und die nötigen Pufferspeicher.
Zusätzlich müssen Client und Server noch Packet-Repeat (inclusive Erkennung von repeated Packets) und diverse andere Algorithmen implementieren, die eigentlich TCP übernehmen könnte - und das alles zusätzlich zu ihrer eigentlichen Aufgabe.
Ja. Und all die für den Einsatzfall sinnlosen Dinge an TCP kann man weglassen. Es gibt übrigens fertige Bibliotheken für Message Passing, die zumindest auf clientseite eingesetzt werden können.
Das Entwicklungsbudget für dieses PPS will ich genehmigt sehen!
Zeig mir das PPS-System, was zentral 100k clients versorgt. Sowas gibts nicht für 3 Mark 80 beim Händler um die Ecke
Bei PPS sprechen wir über 500-5000 gleichzeitige Verbindungen zum Server,
Du hast (aus Versehen?) einfach die Clientzahl um Faktor 20-200 reduziert. Was machen die anderen 95000 Nutzer, die bei deiner Fertiglösung unter den Tisch fallen? Du willst 20-200 Server statt nur einen hinstellen? Schön, mach das. Nur hast du damit nicht zur Lösung vom Josephs Problem beigetragen. Er wollte eben mit einer Kiste *möglichst* *effektiv* massenhaft clients bedienen, statt massenhaft Rechner hinzustellen, die mit alter Software arbeiten.
integriertem Failover, Transaktionssicherung (nein, das hat diesmal nix mit Datenbanken zu tun) und erheblichen Kosten, wenn auch nur einige Kleinigkeiten schiefgehen.
... buzzwords, die nichts mit der Realisierung der Netzwerkgeschichte zu tun haben.
Ich denke, daß Server mit 100k clients erst dann Verbreitung finden, wenn ein Großteil des IP-Stacks in Silizium relisiert wird. Wenn man sich aber auf heute üblicher Hardware daran versuchen will, 100k clients zu bedienen, würde ich keinesfalls anfangen, mit TCP rumzu- spielen.
Reinhard
-----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
lug-dd@mailman.schlittermann.de
-
Eric Schaefer -
Josef Spillner -
Konrad Rosenbaum -
Reinhard Foerster