Intern: Hintergründe zum Server-Update
- Ersteller Nero24
- Erstellt am
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Von Dienstag auf Mittwoch Nacht hat unser <a href="http://www.planet3dnow.de/vbulletin/showthread.php?p=2548179#post2548179">Server</a> ein umfassendes Update erhalten (wir <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1164148246">berichteten</a>). Bis auf den Kernel selbst wurde praktisch jedes Software-Paket auf den aktuellen Stand gebracht. Grund dafür waren diverse Unregelmäßigkeiten im Betrieb. Abgesehen davon, dass der Server in den letzten Wochen aufgrund der steigenden Besucherzahl in den Stoßzeiten jeden Tag am Anschlag seiner Leistung gelaufen ist, was sich in zähem Ansprechverhalten des Forums geäußert hat, hatten wir zudem von Beginn an das Problem, dass der Server immer wieder mal zwischendurch für ein paar Minuten praktisch nicht erreichbar war, während er mit unerklärlichen I/O-Aufgaben beschäftigt war. RAM war genügend frei, keine Anwendung, die über Gebühr Last verursachte, trotzdem war das System minutenlang damit beschäftigt, irgendwelche Daten auf den Platten herumzuschaufeln.
Wir hatten damals, als wir das Boot ins Wasser gelassen haben, von Anfang an geplant erst einmal eine Grundinstallation zu machen, damit das Teil überhaupt funktioniert. Wenn die Systemlast irgendwann einmal einen Punkt erreicht, wo es ans Limit geht, würden wir uns auf eine Optimierung auf Software-Seite stürzen. In einer ersten Stufe ist das diese Woche geschehen. Erst wenn per Software nichts mehr herauszuholen ist, werden wir ein Hardware-Upgrade machen - dann aber wieder eines, das uns erneut mindestens 2 Jahre lang über Wasser halten wird.
Die Analyse und Ansatzpunkte waren dabei umfassend. Neben dem bereits erwähnten Update der Pakete war in der Folge davon nötig, die komplette Datenbank zu dumpen und neu einzuspielen, da das neue Format nicht mit dem alten kompatibel war. Beim Zurückspielen fiel dabei auf, dass die Struktur der DB mehrere Fehler aufwies. So waren z.B. - wie auch immer es passieren konnte - einige Daten in als UNIQUE definierten Spalten einer Tabelle doppelt vorhanden. Beim Zurückspielen weigerte sich die DB selbstredend diese Daten wieder einzuspielen. Ergo musste das 3 GB große SQL-File manuell mit einem Editor bearbeitet werden, um die fehlerhaften Einträge zu fixen, was uns etliche Stunden gekostet hat.
Mindestens ebenso viel Aufmerksamkeit wurde dem Feintuning der Apache- und MySQL-Parameter gewidmet. Während die Datenbank bisher mit Ausnahme der Max_Connections auf Default lief, wurden nun die Parameter exakt der verwendeten Hardware und den Eigenschaften der Datenbank angepasst. So wurden z.B. die key_buffers so eingestellt, dass der komplette Table-Index der DB in das RAM passt. Mit ein Grund für die gelegentlichen Aussetzer war der stark schwankende RAM-Bedarf der Anwendungen bei sich schnell ändernden Lasten. Um das zu verhindern, wurden die Parameter so eingestellt, dass viele Threads als Reserve im RAM verbleiben, selbst wenn sie momentan gar nichts zu tun haben. Das verhindert, dass das System von einem plötzlich sich ver-20-fachenden RAM-Bedarf überrascht wird und zu swappen beginnt statt einfach nur Plattencache freizugeben. Zudem haben wir einen PHP-Code Cache installiert, der häufig verwendete PHP-Skripts in fertig interpretierter Form vorhält, damit das System die Skripte nicht immer und immer wieder neu übersetzen muss. Auch die Skripte selbst wurden unter die Lupe genommen. Vor allem das "Forum Aktuell" Skript wurde dabei als kritisch bzgl. Lastschwankungen ausgemacht und komplett neu geschrieben. Last but not least wurde auch das Forum selbst aktualisiert und auf eine neue Suchenfunktion umgestellt.
Das Resultat der Mammutaktion kann sich sehen lassen. Seit den letzten Feintunings am Donnerstag Nacht gab es praktisch keine Lags mehr, keine Slowqueries, keine Aussetzer. Der RAM-Bedarf ist deutlich weniger schwankend als bisher und - was besonders wichtig ist - die Server-Last (load average) konnte auf ein Viertel gesenkt werden, die mittlere CPU-Last immerhin halbiert. Ein teures Hardware-Upgrade konnte damit vorerst vermieden werden. Das wird uns nun bei weiter konstant steigender Besucherzahlen frühestens Ende des nächsten Jahres blühen. Ein weiteres Update ist für Februar geplant, dann jedoch vor Ort im Rechenzentrum. Dann gibt's ein neues BIOS, einen neuen Kernel und fcgi statt mod_php und als Folge davon apache_worker statt apache_prefork.
Was hat nun der Besucher von der ganzen Aktion? Einen deutlich schnelleren Seitenaufbau, keine Lags mehr, keine Aussetzer, keine langen Beiträge mehr, die nochmal getippt werden müssen, weil sie beim Abschicken in einem Timeout verloren gingen. Und natürlich Kapazitäten für weitere nette und sinnvolle Funktionen im Forum. Wir wünschen daher weiterhin viel Spaß und entspannte Stunden im Forum von Planet 3DNow!
Wir hatten damals, als wir das Boot ins Wasser gelassen haben, von Anfang an geplant erst einmal eine Grundinstallation zu machen, damit das Teil überhaupt funktioniert. Wenn die Systemlast irgendwann einmal einen Punkt erreicht, wo es ans Limit geht, würden wir uns auf eine Optimierung auf Software-Seite stürzen. In einer ersten Stufe ist das diese Woche geschehen. Erst wenn per Software nichts mehr herauszuholen ist, werden wir ein Hardware-Upgrade machen - dann aber wieder eines, das uns erneut mindestens 2 Jahre lang über Wasser halten wird.
Die Analyse und Ansatzpunkte waren dabei umfassend. Neben dem bereits erwähnten Update der Pakete war in der Folge davon nötig, die komplette Datenbank zu dumpen und neu einzuspielen, da das neue Format nicht mit dem alten kompatibel war. Beim Zurückspielen fiel dabei auf, dass die Struktur der DB mehrere Fehler aufwies. So waren z.B. - wie auch immer es passieren konnte - einige Daten in als UNIQUE definierten Spalten einer Tabelle doppelt vorhanden. Beim Zurückspielen weigerte sich die DB selbstredend diese Daten wieder einzuspielen. Ergo musste das 3 GB große SQL-File manuell mit einem Editor bearbeitet werden, um die fehlerhaften Einträge zu fixen, was uns etliche Stunden gekostet hat.
Mindestens ebenso viel Aufmerksamkeit wurde dem Feintuning der Apache- und MySQL-Parameter gewidmet. Während die Datenbank bisher mit Ausnahme der Max_Connections auf Default lief, wurden nun die Parameter exakt der verwendeten Hardware und den Eigenschaften der Datenbank angepasst. So wurden z.B. die key_buffers so eingestellt, dass der komplette Table-Index der DB in das RAM passt. Mit ein Grund für die gelegentlichen Aussetzer war der stark schwankende RAM-Bedarf der Anwendungen bei sich schnell ändernden Lasten. Um das zu verhindern, wurden die Parameter so eingestellt, dass viele Threads als Reserve im RAM verbleiben, selbst wenn sie momentan gar nichts zu tun haben. Das verhindert, dass das System von einem plötzlich sich ver-20-fachenden RAM-Bedarf überrascht wird und zu swappen beginnt statt einfach nur Plattencache freizugeben. Zudem haben wir einen PHP-Code Cache installiert, der häufig verwendete PHP-Skripts in fertig interpretierter Form vorhält, damit das System die Skripte nicht immer und immer wieder neu übersetzen muss. Auch die Skripte selbst wurden unter die Lupe genommen. Vor allem das "Forum Aktuell" Skript wurde dabei als kritisch bzgl. Lastschwankungen ausgemacht und komplett neu geschrieben. Last but not least wurde auch das Forum selbst aktualisiert und auf eine neue Suchenfunktion umgestellt.
Das Resultat der Mammutaktion kann sich sehen lassen. Seit den letzten Feintunings am Donnerstag Nacht gab es praktisch keine Lags mehr, keine Slowqueries, keine Aussetzer. Der RAM-Bedarf ist deutlich weniger schwankend als bisher und - was besonders wichtig ist - die Server-Last (load average) konnte auf ein Viertel gesenkt werden, die mittlere CPU-Last immerhin halbiert. Ein teures Hardware-Upgrade konnte damit vorerst vermieden werden. Das wird uns nun bei weiter konstant steigender Besucherzahlen frühestens Ende des nächsten Jahres blühen. Ein weiteres Update ist für Februar geplant, dann jedoch vor Ort im Rechenzentrum. Dann gibt's ein neues BIOS, einen neuen Kernel und fcgi statt mod_php und als Folge davon apache_worker statt apache_prefork.
Was hat nun der Besucher von der ganzen Aktion? Einen deutlich schnelleren Seitenaufbau, keine Lags mehr, keine Aussetzer, keine langen Beiträge mehr, die nochmal getippt werden müssen, weil sie beim Abschicken in einem Timeout verloren gingen. Und natürlich Kapazitäten für weitere nette und sinnvolle Funktionen im Forum. Wir wünschen daher weiterhin viel Spaß und entspannte Stunden im Forum von Planet 3DNow!
Peter1984
Grand Admiral Special
Danke, das ihr euch so ne Mühe macht, auch für uns!
Colonizer
Vice Admiral Special
Danke für die ausführlicheren Hintergründe.
Redphil
Grand Admiral Special
Kann mich dem nur anschließen, finde es sehr positiv, so auch immer mal etwas hinter die Kulissen von p3d schnuppern zu können.
Ist auch ganz gut, wenn man so immermal vor Augen hat, was für Aufwand dort (unentgeltlich) getrieben wird, wieviel Freizeit geopfert etc. .
Auch dafür Danke.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Matzinger
Grand Admiral Special
Super Sache!
Schön zu sehen auch, wie sich der RAM- und CPU-Graph im Vergleich zu vorher "beruhigt" hat
Bei den CPUs sah es ja wirklich so aus, als ob bald auch der 2. CPU 80-100% Last bekommt.
Gruß,
MFR2000
Schön zu sehen auch, wie sich der RAM- und CPU-Graph im Vergleich zu vorher "beruhigt" hat
Bei den CPUs sah es ja wirklich so aus, als ob bald auch der 2. CPU 80-100% Last bekommt.
Gruß,
MFR2000
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Das hatte sie effektiv schon!
Du solltest Dich von der Munin-Kurve nicht irritieren lassen. Die Muninkurve ist nur ein Mittelwert über die letzten 10 Minuten, in denen zwischendurch auch mal 2-3 Sekunden lang überhaupt niemand auf den Server zugreift, was den Durchschnittswert natürlich senkt gegenüber der Realität. Wenn Munin einen Wert von 120 anzeigt, dann bedeutet das mit einem Blick auf die Echtzeit-CPU-Last, dass die beiden CPU praktisch schon permanent zwischen je 75% und 100% Last liegen. In den letzten Tagen war die CPU-Last laut Munin in den Stoßzeiten bei 150. Damit war der Server effektiv voll ausgelastet. 
Arnie_75
Grand Admiral Special
Kann man eigentlich irgendwo eine Art Rangliste der meist besuchten .de Seiten finden? Es würde mich mal interessieren, wie diese Seite im Vergleich zu anderen ganz großen (heise, zdnet, microsoft, etc.) liegt.
![[MTB]JackTheRipper](/data/avatars/m/1/1018.jpg?1596828194){kind=avatar}
[MTB]JackTheRipper
Grand Admiral Special
Beachtlich, wie sich die Serversoftware "tunen" lässt. Mit so viel freiwerdenden Kapazitäten hätte ich nie gerechnet.
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Das kann es nicht geben, weil für eine solche Rangliste jede Seite seine Zugriffszahlen auf die gleiche Weise zählen, offenlegen und über eine genormte Schnittstelle zur Verfügung stellen müsste. Und es gibt ja bekanntlich unzählige Verfahren zu zählen was nun tatsächlich ein Visit ist. Manche Anbieter veröffentlichen auch nicht die Visitors, sondern nur die Page Impressions.
Auf Alexa.com gibt's zumindest ein weltweites Ranking was den Traffic anbelangt (wie auch immer die das wissen wollen wie viel Traffic die einzelnen Websites haben
).http://www.alexa.com/data/details/traffic_details?q=planet3dnow.de&url=planet3dnow.de
Da liegt P3D an 30.762ster Position aller Webseiten weltweit. Die Platzierung anderer Sites kannst Du bequem abfragen, indem Du einfach deren Domainnamen eintippst.
Allerdings ist "Traffic" in meinen Augen ein ziemlich blödes Kriterium für ein Ranking, denn wenn eine Webseite massiv lokal gehostete Downloads anbietet, ist der Traffic natürlich um ein vielfaches größer, als bei de facto stärker besuchten Websites, die keine oder kaum lokale Downloads anbieten.
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.614
- Renomée
- 441
- Standort
- Bayern, am Rande des Wahnsinns
ja, es ist wirklich erstaunlich, was man Softwareseitig tunen kann.
Würde das eingesetzte Board eigentlich auch Dual-Core Opterons unterstützen? bzw wieviel RAM kann man dem guten noch draufpacken? mal so interesse halber.
Würde das eingesetzte Board eigentlich auch Dual-Core Opterons unterstützen? bzw wieviel RAM kann man dem guten noch draufpacken? mal so interesse halber.
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Ja, darum hatten wir uns für dieses Board entschieden. Momentan schieben zwei Opteron 246 mit je 2.0 GHz Taktfrequenz Dienst. Die könnte man - wenn per Software mal nichts mehr geht - gegen zwei Dual-Core Opteron 280 mit je 2x2,4 GHz Taktfrequenz ersetzen und die theoretische Peak-Leistung damit mehr als verdoppeln
4 GB RAM (4x 1 GB) sind drauf. Ebensoviel könnte man noch einmal dazu stecken und damit 8 GB RAM erhalten. Oder man wirft die jetzigen komplett raus und steckt 8x 2 GB RAM hinein. Dann ist die maximale Kapazität von 16 GB RAM erreicht. Software seitig ist das kein Problem, da wir uns ja für die 64-Bit Version von Linux entschieden haben, wo es kein 4 GB Speicherlimit für das System gibt
Beides zusammen (max CPUs und max RAM) würde als Upgrade momentan allerdings ca. 3.400 EUR kosten.
(2x 500 EUR für die CPUs, 8x 300 EUR für die RAMs)
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.614
- Renomée
- 441
- Standort
- Bayern, am Rande des Wahnsinns
klingt ja klasse 
Die Kosten natürlich weniger klasse
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
wo es kein 4 GB Speicherlimit für das System (bzw. 2 GB für eine Anwendung) gibt
3GB, Linux nutzt standardmäßig eine 3:1 Teilung des Adressraums.
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Ok, hatte nur die Windows-Zahlen im Kopf
Betrifft uns aber ja dank x86_64 so oder so nicht Arnie_75
Grand Admiral Special
Das kann es nicht geben, weil für eine solche Rangliste jede Seite seine Zugriffszahlen auf die gleiche Weise zählen, offenlegen und über eine genormte Schnittstelle zur Verfügung stellen müsste. Und es gibt ja bekanntlich unzählige Verfahren zu zählen was nun tatsächlich ein Visit ist. Manche Anbieter veröffentlichen auch nicht die Visitors, sondern nur die Page Impressions.
Auf Alexa.com gibt's zumindest ein weltweites Ranking was den Traffic anbelangt (wie auch immer die das wissen wollen wie viel Traffic die einzelnen Websites haben
http://www.alexa.com/data/details/traffic_details?q=planet3dnow.de&url=planet3dnow.de
Da liegt P3D an 30.762ster Position aller Webseiten weltweit. Die Platzierung anderer Sites kannst Du bequem abfragen, indem Du einfach deren domainnamen eintippst.
Allerdings ist "Traffic" in meinen Augen ein ziemlich blödes Kriterium für ein Ranking, denn wenn eine Webseite massiv lokal gehostete Downloads anbietet, ist der Traffic natürlich um ein vielfaches größer, als bei de facto stärker besuchten Websites, die keine oder kaum lokale Downloads anbieten.
OK, danke.
Stefan Payne
Grand Admiral Special
Beeindruckend, was ein wenig 'Krieg aufm Server' doch so ausrichten kann :O
Jetzt könnt ich noch etwas lästern, über eine bestimmte Partnerseite, aber das lass ich dann mal
Jetzt könnt ich noch etwas lästern, über eine bestimmte Partnerseite, aber das lass ich dann mal
BarBart
Fleet Captain Special
Recht hat er. Mein Vorredner (cologne46)
Wenn man sich so anguckt, wie mit diesem Problem z.B. beim StudiVZ umgegangen wird, dann ist das hier schon richtig erfrischend!
Außerdem möchte auch ich nochmal meinen Dank an die fleisigen Menschen aussprechen die für meine tägliche Dosis Technikverrücktheit befriedigen.
MfG der BarBart
Wenn man sich so anguckt, wie mit diesem Problem z.B. beim StudiVZ umgegangen wird, dann ist das hier schon richtig erfrischend!
Außerdem möchte auch ich nochmal meinen Dank an die fleisigen Menschen aussprechen die für meine tägliche Dosis Technikverrücktheit befriedigen.
MfG der BarBart
Dave Zwieback
Admiral Special
Danke, gute Arbeit Jungs
Gruss
Dave Z
Gruss
Dave Z
sorry aber das ist schon ein bischen noobig was ihr da gemacht habt
es gibt zig guids und threads zum optimalen einstellen des systems und selbst klatscht ihr einfach die software drauf und wartet bis nichts mehr geht
was hat euch da geritten?
faulheit?
ich bin da schon ein bischen enttäscht
und noch ein aspekt wäre wenn ihr schon vor einem jahr die serverlast verringert hättet dann hätte damals auch ein kleinenrer und damit günstigerer server ausgereicht und dieser würde heute wohl auch noch reichen...
wo kommt eigentlich das geld dafür her?
es gibt zig guids und threads zum optimalen einstellen des systems und selbst klatscht ihr einfach die software drauf und wartet bis nichts mehr geht
was hat euch da geritten?
faulheit?
ich bin da schon ein bischen enttäscht
und noch ein aspekt wäre wenn ihr schon vor einem jahr die serverlast verringert hättet dann hätte damals auch ein kleinenrer und damit günstigerer server ausgereicht und dieser würde heute wohl auch noch reichen...
wo kommt eigentlich das geld dafür her?
Ähnliche Themen
