In diesem Kapitel geht es um Probleme, wie Sie beim Einsatz als Internet-Server, Fileserver und X-Application Server typischerweise auftreten. Die Ursachen sind hier vielfältig, aber zu beheben, wenn man wiß, wonach man suchen muß.
Zum einen ist es die maximale Zahl der Prozesse von LINUX, die bei 1024 liegt. Als Prozeß unter LINUX können wir z.B. den Apache WWW-Server betrachten. Dieser startet gewöhnlich mit 5 Threads, d.h. er kopiert sich direkt beim Start 5x in das RAM. Jeder Prozeß kann dann entsprechend der Standard - Einstellung bis zu 150 Anfragen von Browsern bedienen. Wenn nun z.B. ein älterer Browser, der nur HTML 1.0 spricht eine HTML Seite mit vielen Grafiken anfordert, dann sind die 150 Anfragen/Prozeß schnell aufgebraucht. Wenn nun aber der Browser HTML 1.1 untertützt, dann werden alle Grafiken und HTML Seiten in einen einzigen Datenstrom verpackt, und der Apache WWW-Server zählt intern also pro Browser nur eine Anfrage.
Ein wesentlicher Unterschied.
Nun unterstützt der Apache WWW-Server hunderte von WWW-Servern, die sich Virtual Server nennen. Es können somit viele Internet-Domains auf einem LINUX Server gehostet werden. Für jede Domain gibt es Log-Files, eine Error-Datei, eine Log-Datei, und optional eine Browser-Datei sowie eine Referrer-Datei. In der Browser-Datei und Referrer-Datei werden der verwendete Client, und in der Referrer-Datei wird abgelegt, von welcher Internet-Seite der Surfer auf die HTML-Seiten geklickt hat. Diese können dann ausgewertet werden, z.B. auch über Cookies. Man kann so ermitteln, welcher Surfer sich wofür bei anderen Websites interessiert hat, und evtl. auch welche Werbeaktion die größte Wirkung gehabt hat.
Die Besitzer der Domains erhalten so wertvole Informationen für den E-Commerce.
Nachdem ca. 50 virtuelle WWW-Server installiert waren, brach die Performance des Apache WWW-Servers völlig ein. Der Grund lag inder maximalen Zahl er sogenannten File-Handles, die beim LINUX Kernel 2.0 noch bei maximal 256 lag. Für jede geöffnete Datei wird ein File-Handle berechnet. Um weitere Datei zu öffnen, müssen andere zuerst geschlossen werden, und dies führte dann zu unerklärlichen Warte-Zuständen beim Apache - WWW-Server.
Bei den Kernel-Versionen 2.2 liegt die Standard - Grenze bei 1024 Filehandles, was im Normalfall für den Betrieb als Internet-Server ausreichen sollte.
Beim Einsatz von LINUX 2.2 als Router in einem Netzwerk mit 100 Usern allerdings brach dann LINUX völlig ein. Es surften ca. 50-80 Personen simultan über eine T-Interconnect Leitung (T-Online mit ADSL 1.5 MBit, 387 DM/Monat+160 DM/GigaByte, kann ich nur empfehlen). Als Proxy-Cache war der hier im Handbuch beschriebene SQUID installiert, der aus zunächst unerklärlichen Gründen zeitweilig zu stehen schien, obwohl die Grafiken und HTML Seiten bereits im Proxy-Cache lagen. Der Grund war schnell gefunden:
Pro Website kann man inzwischen ca. 10-20 kleinere Grafiken zählen. Bei fast 100 Usern waren plötzlich alle 1024 File-Handles verbraucht, und man hatte als Surfer den Eindruck, daß LINUX einfach nur bremst. So war es auch. Nur waren s nicht so sehr die maximale Zahl der Filehandles, sondern diesmal die maximale Zahl an TCP/IP Verbindungen, die ebenfalls bei 1024 liegt. Wenn man jedoch LINUX als Router einsetzt, dann gibt es zu jeder eingehenden Verbindungsanfrage auch einen ausgehende Anfrage, dazwischen liegt dann noch SQUID als PROXY-Cache. Bei 100 Usern können so leicht 1500 Netzwerkverbindungen in Richtung Intranet und recht viele in Richtung Internet geöffnet sein. Damit neue Verbindungen geöffnet werden konnten, mußten andere geschlossen werden. Der Surfer hat somit den Eindruck, daß es nicht richtig vorwärts geht.
LINUX 2.2 als Proxy-Cache mit SQUID bremst sogar eine normale 128 kBit ISDN Leitung aus. Mit der Erhöhung der Zahl der TCP/IP Handles und File-Handles auf 65535 waren nun alle Probleme beseitigt, LINUX antwortete stets äußerst schnell auf Anfragen, im Gegensatz zu dem Standard-Kernel.
Bei dem Einsatz von LINUX als X-Application Server für den Einsatz von alten 486er PC's als X-Windows Terminals offenbarte sich dann noch einanderes Problem. Alle X-Windows Clients binden sich zunächst über NFS an den X-Application Server an, und starten dann den X-Server mit der KDE Oberfläche. Zudem wird noch der Font-Server XFS auf dem Server benötigt, der dann allen X-Clients die Schriftarten für Bildschirm und Drucker zur Verfügung stellt. Bei ca. 540 Fonts, die LINUX bereits standardmäßig besitzt, und 50 X-Clients war plötzlich auch ein getunter LINUX Kernel am Ende. Der Gund lag darin, daß jeder dieser 50 X-Clients entweder via Netscape über einen SQUID Proxy surfte, oder mit StarOffice 5.1a intensiv Schrifen in Briefe, Grafiken und HTML-Seiten eingebaut hat. Pro Client fielen dann ca. 20-30 Filehandels für Schriften, 10-30 Netzwerkverbindungen zum Server und ca. 10-20 Netzwerkverbindungen, vom SQUID Proxy-Server ausgehend, ins Internet an. Dazu kam dann noch der Einsatz von LINUX als SAMBA Server, Print-Server und einige andere Dienste. Insgesammt wurden dann von 50 Surfern knapp tausend Filehandles und mehrere tausend Netzwerk-Verbindungen geöffnet.
Erstaunlicherweise war nicht die CPU am Ende, auch nicht das RAM (256 MByte) oder die Festplatte, sondern immer wieder gab es Grenzen, entweder bei den File-Handles, bei den NFS Handles, den Network-Handles, der maximalen Anzahl der Threads pro Dämon (Apache, SAMBA) u.s.w.
Wir entschließen und nun, alle Grenzen auf 65535 hinaufzusetzen, und kompilierten alle Pakete mit den veränderten Optionen neu. Wir haben nun keine Probleme mehr, auch nicht im direkten Vergleich mit IRIX oder anderen UNIX Derivaten.
Das nächste Problem mit INTEL LINUX ist die maximale Größe der Dateien. Diese liegt, auch nach Patches des Kernels, bei 4 GByte. Unsere Datenbanken, die ca. 1.000.000 Informationen mit je ca. 1500 Bytes enthalten, waren schnell an der Grenze von 2 GByte, der Grenze einer Standard-Distribution. Bei der Sortierung und Auswertung von Daten kommt man schnell an die Grenzen von INTEL LINUX.
Hier bot sich der Einsatz einer DEC-ALPHA mit einer 64 Bit Architektur an. Da nun Windows NT ja nicht mehr diesen Prozessor unterstützt, kann man diese Server nun sehr billig auf dem Gebrauchtmarkt bekommen. Leider unterstützen weder das EXT2 Filesystem, noch das EXT3 oder ReiserFS Datein, die größer als 2 GByte sind. Mit dem etwas gewöhnungsbedürftigen GFS endlich gelang es, LINUX diese Grenze abzugewöhnen. Nun ist es möglich, stundenlang Videos auf der Festplatte (2x20 Gbyte+RAID 1) aufzuzeichnen und schneiden, ohne daß sich irgendwelche Grenzen gezeigt hätten. Einziges Problem: Viele der Werkzeuge der GNU Toolkits, z.B. tar, cpio, u.s.w. sind nicht 64 Bit - fähig. SAMBA und MySQL hingegen sind es. Für TAR kann man die spezielle Variante für Solaris 2.7 vom Server http://www.sunfreeware.com aus dem Internet laden und unter LINUX neu kompilieren.