Gleitz
21st January 2004, 19:10
Hallo miteinander,
wollte mal eine kurz Stellung beziehen auf das die Serverprobleme für das deutsche Doom9-Forum.
Wie ihr wisst, musste ich bei meinem Provider vom Server herunter. Die Leistung reichte einfach nicht mehr aus, um mit der täglich aufkommende Anfragen fertig zu werden.
Nach langem hin und her und mit zig Diskussionen mit anderen Forenbetreibern bin ich zum Entschluss gekommen einen Rootserver zu mieten.
Nach erfolgreicher Installation und ausführlichen Tests bin ich mit dem Forum auf diesen Rootserver umgezogen. Beim produktiven Einsatz vom Server zeigte sich dann leider schnell ein Mangel am System. Im laufe des Tages sammelten sich immer mehr aktive Prozesse an, die eine hohe Prozessorlast erzeugten nicht beendet wurden.
Der Apache Webserver erzeugt in der Regel ein fest definierte Anzahl an Kindprozesse die jeweils mehrere Threadprozesse aufnehmen. Normalerweise wird ein Kindprozess gestoppt und durch einen neuen ersetzt, wenn dieser ein gewisses Zeitlimit überschritten hat. Hier wurden anscheindend eingefrorene Prozesse nicht gestoppt, was dazu führte, das der Webserver ständig von Hand neu gestartet werden musste.
Bei Recheren in den unterschiedlichsten Foren waren mehrere Threads zu diesem Thema ausfindig zu machen. Eines hatten alle gemeinsam, Suse 8.x, Apache und keine Lösung.
Daher entschloss ich mich von Suse auf Debian zu springen und Apache 2 aufzusetzen.
Die Debian installation scheiterte bis jetzt. Bei der Installation über das Netz, werden sogenannte Shell-Scripte benutzt. Egal ob ich jetzt zwei speziell auf Stratos zugeschnitte Shell-Scripte benutze oder direkt die Installation nach der vorgeschlagenen Art von Debian mache. Es kommt immer zum Abstutz beim laden eines ganz bestimmten Programmpaketes.
Damit scheiterte bis heute die Installation von Debian.
Das andere was ich wollte war ja Apache2. Dieser Webserver kann auch mit dem sogenannten Worker-Modul installiert werden. Dieses Worker-Modul ist in der Lage die Anzahl der Kindprozesse dynamisch zu verwalten, hält gleichzeitig eine gewisse Anzahl an Threadprozessen frei um mit einen plötzlichen Ansturm an Abfragen fertig zu werden. Eigentlich Ideal für eine Forensoftware.
php sollte nicht als cgi laufen, sondern als Modul von Apache2, was eine Geschwindigkeitsgewinn von 10% bringen soll.
Als Admin-Software sollte Confixx eingesetzt werden, da diese php als Apachemodul untersützt.
Gleichzeitig sollte MySQL 4.xx eingesetzt werden, da diese Version in der Lage ist Datenbankabfragen zu cachen und eine Forensuche ermöglicht, die nicht die Extra-Datenbänke dafür braucht und die Datenbank selber nicht so sehr belastet.
Apache2 <--> Confixx
Confixx will php als Modul, aber Perl als cgi. Hier musste ich mir erst Wissen aneignen. Apache2 geht sehr komplex mit cgi um und hier waren viele Versuche notwenig um endlich die richtige Konfiguration für das Compilen zu finden.
Confixx <--> php
Die aktuellen php-Versionen prodzieren Fehler in Zusammenarbeit mit Confixx. In jedem php-Script, in denen Einfluss auf Headerdateien genommen wird kommt es zu Fehlern. Diese Fehlerquelle musste erst mal lokalisiert werden. Gleichzeitig die letzte Version gefunden werden, wo das Problem nicht mehr auftritt. Angeblich den Entwicklern von php bekannt und wird in der nächsten Version gefixt. In der aktuellen Beta ist das Problem noch vorhanden.
MySQL <--> ?
Es gibt für die aktulle stabile Version keine Quelldateien mehr. Nur Binaries und RPM-Pakete. Die Dokumentation für die Binärdateien ist lächerlich bis schlecht innerhalb der Pakten, auf den Webseiten von MySQL ist darüber überhaupt nicht zu finden. Ich weis nicht was ich mit diesen Dateien anstellen soll, wie ich diese in das System einbinden soll. Mit den rpm-Pakten spinnt mir Yast herum. Durch die Paketabhängigkeiten werden Module doppelt geladen, nicht überschrieben und alles spinnt herum. :confused:
So das war es jetzt erst mal zum aktuellen Stand.
wollte mal eine kurz Stellung beziehen auf das die Serverprobleme für das deutsche Doom9-Forum.
Wie ihr wisst, musste ich bei meinem Provider vom Server herunter. Die Leistung reichte einfach nicht mehr aus, um mit der täglich aufkommende Anfragen fertig zu werden.
Nach langem hin und her und mit zig Diskussionen mit anderen Forenbetreibern bin ich zum Entschluss gekommen einen Rootserver zu mieten.
Nach erfolgreicher Installation und ausführlichen Tests bin ich mit dem Forum auf diesen Rootserver umgezogen. Beim produktiven Einsatz vom Server zeigte sich dann leider schnell ein Mangel am System. Im laufe des Tages sammelten sich immer mehr aktive Prozesse an, die eine hohe Prozessorlast erzeugten nicht beendet wurden.
Der Apache Webserver erzeugt in der Regel ein fest definierte Anzahl an Kindprozesse die jeweils mehrere Threadprozesse aufnehmen. Normalerweise wird ein Kindprozess gestoppt und durch einen neuen ersetzt, wenn dieser ein gewisses Zeitlimit überschritten hat. Hier wurden anscheindend eingefrorene Prozesse nicht gestoppt, was dazu führte, das der Webserver ständig von Hand neu gestartet werden musste.
Bei Recheren in den unterschiedlichsten Foren waren mehrere Threads zu diesem Thema ausfindig zu machen. Eines hatten alle gemeinsam, Suse 8.x, Apache und keine Lösung.
Daher entschloss ich mich von Suse auf Debian zu springen und Apache 2 aufzusetzen.
Die Debian installation scheiterte bis jetzt. Bei der Installation über das Netz, werden sogenannte Shell-Scripte benutzt. Egal ob ich jetzt zwei speziell auf Stratos zugeschnitte Shell-Scripte benutze oder direkt die Installation nach der vorgeschlagenen Art von Debian mache. Es kommt immer zum Abstutz beim laden eines ganz bestimmten Programmpaketes.
Damit scheiterte bis heute die Installation von Debian.
Das andere was ich wollte war ja Apache2. Dieser Webserver kann auch mit dem sogenannten Worker-Modul installiert werden. Dieses Worker-Modul ist in der Lage die Anzahl der Kindprozesse dynamisch zu verwalten, hält gleichzeitig eine gewisse Anzahl an Threadprozessen frei um mit einen plötzlichen Ansturm an Abfragen fertig zu werden. Eigentlich Ideal für eine Forensoftware.
php sollte nicht als cgi laufen, sondern als Modul von Apache2, was eine Geschwindigkeitsgewinn von 10% bringen soll.
Als Admin-Software sollte Confixx eingesetzt werden, da diese php als Apachemodul untersützt.
Gleichzeitig sollte MySQL 4.xx eingesetzt werden, da diese Version in der Lage ist Datenbankabfragen zu cachen und eine Forensuche ermöglicht, die nicht die Extra-Datenbänke dafür braucht und die Datenbank selber nicht so sehr belastet.
Apache2 <--> Confixx
Confixx will php als Modul, aber Perl als cgi. Hier musste ich mir erst Wissen aneignen. Apache2 geht sehr komplex mit cgi um und hier waren viele Versuche notwenig um endlich die richtige Konfiguration für das Compilen zu finden.
Confixx <--> php
Die aktuellen php-Versionen prodzieren Fehler in Zusammenarbeit mit Confixx. In jedem php-Script, in denen Einfluss auf Headerdateien genommen wird kommt es zu Fehlern. Diese Fehlerquelle musste erst mal lokalisiert werden. Gleichzeitig die letzte Version gefunden werden, wo das Problem nicht mehr auftritt. Angeblich den Entwicklern von php bekannt und wird in der nächsten Version gefixt. In der aktuellen Beta ist das Problem noch vorhanden.
MySQL <--> ?
Es gibt für die aktulle stabile Version keine Quelldateien mehr. Nur Binaries und RPM-Pakete. Die Dokumentation für die Binärdateien ist lächerlich bis schlecht innerhalb der Pakten, auf den Webseiten von MySQL ist darüber überhaupt nicht zu finden. Ich weis nicht was ich mit diesen Dateien anstellen soll, wie ich diese in das System einbinden soll. Mit den rpm-Pakten spinnt mir Yast herum. Durch die Paketabhängigkeiten werden Module doppelt geladen, nicht überschrieben und alles spinnt herum. :confused:
So das war es jetzt erst mal zum aktuellen Stand.