Hausaufgabe für den kleinen Sysadmin
by Volker Weber
Finden Sie den Fehler in dieser Beweiskette:
Der Beweis ist ganz einfach: wir haben alle Daten aus der Datenbank in eine Installation auf einem externen Server exportiert, so daß die Weblogs aus einem anderen MySQL gefüttert wurden. Sofort verschwanden die Probleme.
Randbedingung: 1 Gig RAM mit Apache und MySQL auf der selben Hardware, 100 k Seitenaufrufe am Tag, Webseite dynamisch aus der Datenbank generiert.
Comments
Also mir fällt als erstes eine gewisse Selbstgefälligkeit auf: "das »wichtigste deutsche Business-Weblog« und um das erste kommerziell erfolgreiche Mac-Weblog"... die Links hinter den Superlativen verweisen nicht etwa auf Quellen, in denen die angesprochenen Seiten gelobt werden, sondern lediglich auf die Seiten selbst. Der Lobende und der Gelobte sind also offenbar hier in Personalunion tätig.
Hint: Ein Wort beginnend mit "a"...
.
Ragnar, bevor Du eine solche Beurteilung abgibst solltest Du das Blog etwas besser kennen. Bei dem Link fehlen die "Ironie-Tags", aber der Grund fuer die Aussage und den so ausgezeichneten Link zu sich selbst findest Du in den Archiven. Und an diversen anderen Stellen in der Deutschen "Blogosphere".
Armin, wenn ich so einen Server fahre, mich dann aufrege, dass der abraucht, viel Wind um das ganze mache und anschließend auch noch so einen "Beweis" wie den obigen führe, dann würde ich nicht mehr auf Ironie sondern auf Arroganz tippen.
Also...
Ich lese ITW in unregelmaessigen Abstaenden seit einiger Zeit, das ganze mit dem "wichtigsten Deutschen Business-Weblog" ist inzwischen eine Art "running gag" der sich seit mehreren Wochen durch das Blog zieht. Der Anfang dazu ist ungefaehr hier, wo das Blog in den Top 100 Business Weblogs als Nummer 1 gelistet wurde. Wenn man diesen Hintergrund kennt dann liest sich dieser Teil des Statements etwas anders. Darauf und auf Ragnars Interpretation habe ich mich bezogen, nichts anderes.
Zu dem "Beweis" den Volker oben zitiert kann, will und habe ich nichts zu sagen. Ich habe keine Ahnung von Datenbanken, deren Performance etc und kann das daher auch nicht beurteilen.
Mir ist der Hintergrund durchaus bekannt. Das Problem scheint mir aber zu sein, dass sich der "running gag" bei IT&W zur Geisteshaltung hochgearbeitet hat. Ansonsten würden sie nicht so viel Wind machen, OHNE mal jemanden zu fragen, der sich mit der Materie AUSKENNT.
Fuer die unbeleckten, wo genau ist der Fehler in der Beweiskette?
Ich will ja hier auch mal was lernen... ;)
Ganz einfach: 100.000 Seiteanbrufe am Tag sind rund 1,2 Abrufe pro Sekunde. Da die Seiten dynamisch erzeugt werden, rechnen wir der Einfachheit halber mal Faktor 4 und kommen so auf rund 5 Datenbankanfragen pro Sekunde. Dazu kommen dann Sonderanfragen, beispielsweise Suchläufe über die gesamte Datenbank etc. Das heisst, ich habe zu jeder gegebenen Minute (ja nach Konfiguration) mindestens 80 Apache-Server und zusätzlich nochmal rund 50-60 MySQL-Instanzen am Start. Ich gehe mal davon aus, dass weder der Apache noch MySQL noch das ebenfalls verwendete PHP optimiert sind. Das bedeutet, die Kiste ist am Swappen, was die Hardware hergibt. Größtes Problem ist dabei MySQL, das versucht, sich entsprechend der Anfragen zu optimieren und einen wachsenden Speicherbereich für temporäre Ergebnistabellen und so weiter anlegt. Irgendwann gibt es aber den Punkt of Total Failure, an dem MySQL einfach das Handtuch schmeisst (out of connection handles, nicht in der Lage, Ergebnisse schnell genug aus dem Swap zu holen etc.). Die eleganteste Lösung ist in solchen Fällen, den MySQL-Server auf eine andere Maschine auszulagern. Das gibt zwar höhere Antwortzeiten, da jetzt alles übers Netzwerkkabel und nicht mehr über den lokalen Bus läuft, was aber vernachlässigbar ist, da selbst eine 10 Mbit/s-Verbindung schneller ist als ein überlasteter, swappender Server. Das dem so ist beweist der "Beweis" hinreichend ;) Weiteres Potenzial für Optimierungen wäre ein Umstellen der von der PHP-Applikation verwendeten MySQL-Schnittstelle von mysql auf mysqli und das Aktivieren der Datenkompression. Muss leider grad weg, Links zum erzielbaren Effekt dann später. Oder in der Zwischenzeit einfach durch meine Seite wühlen und nach "Impressed" suchen.
Stefan hat sicherlich recht. Was mich dann aber doch stutzig macht ist die Tatsache das der 2te MySQL Server angeblich gute Performance erreicht obwohl der Datenaustausch anscheinend über das normale TCPIP Netz des Anbieters läuft. Eigentlich sind solche Konfigurationen meiner Erfahrung nach sehr störanfällig und nicht besonders performant.
Der besagte Anbieter, 1und1 hat im übrigen für höhere Anforderungen auch eine Businessabteilung (Schlund). Kostet natürlich ein paar Euro mehr.
Wenn die Webseite tatsächlich soviel Last/Traffic verursacht verdient der Anbieter sowieso nichts daran. Dann ist es auch nicht verwunderlich wenn eine fristlose Kündigung anstandslos akzeptiert wird.
Es gibt auch Anbieter die schalten solche Server wegen angeblichem AGB Verstoß erst einmal ein paar Tage ab.
Henning, ich weiß das, weil eine von mir betreute Site mal in einer ähnlichen Situation war (weniger Abrufe insgesamt, dafür anscheinend bescheidener programmierte SQL-Abfragen). Nachdem ich den MySQL-Server ausgelagert und die Site auf zwei Web-Server (jaja, Overkill, aber die waren grad verfügbar) aufgeteilt habe, ist das Ding *rasend* schnell. Das liegt unter anderem daran, dass sich die SQL-Statements dank Klartext saugut komprimieren lassen. Insgesamt machen die beiden Web-Server mit ihren Datenbankanfragen einen Sptizentraffic von jetzt rund 300 kByte/s. Das fällt im internen Netz der Provider gar nicht auf. Wobei ich natürlich den Vorteil habe, dass die drei Server im selben Rack stehen, also auch am selben (Gigabit)Switch hängen. Vor der Umstellung auf mysqli war der Spitzentraffic übrigens fast 10 mal so hoch. Den Effekt bei einem Switch von mysql_ auf mysqli_ kannst du hier sehen. Was der weitere Umstieg auf MySQL 5 bringt dann entsprechend hier. PHP und Apache zu optimieren entlastet die Server weiter, und wenn man dann noch einen "Loadbalancer" wie z.B. Pound als - im Vergleich zu etwa Squid - Lösung mit kleinem Footprint einsetzt, dann kann man sogar auf dem einen Web-Server Maintenance machen, während der andere kurzfristig alle User managed und dafür sorgt, dass die Anwender quasi Null Ausfallzeit haben. Insgesamt komme ich so mit einem "Angebot von der Stange" auf Grundkosten von zirka 200 Euro im Monat und bleibe noch deutlich unter dem - leider noch vorhandenen - Traffic-Limit. Aber da die neusten Angebote der Provider eh "unlimited" sind, ist das bei einem anstehenden Wechsel/Umzug inzwischen irrelevant.
Ich tippe auf "dynamisch" ... :-/
Armin, danke für den Hinweis auf die Entstehungsgeschichte dieses "Running Gags". Ich hätte es für sinnvoll gehalten, diesen Link hinter den Text zu legen, anstatt nur auf die Startseite des Blogs zu verlinken. Dann nämlich hätte auch ich verstanden, worum's dabei geht.
Stefan, das mag ja alles richtig sein. Aber kauft man sich nicht gerade deswegen einen Managed Server, um sich um sowas nicht kümmern zu müssen? 1und1 wirbt ja hier ausdrücklich mit "Wir managen die Details" und ""Komplettservice"
Oliver, ich habe widersprüchliche Informationen.
it&w schrieb heute (und dieser Text ist leider schon wieder geändert) sinngemäß, dass die Presseabteilung wohl heute erst mitgekriegt habe, dass da ein Problem vorliegt. Das ist definitiv falsch, weil ich bereits vor vier Tagen eine Anfrage gestellt habe. Die offizielle Antwort passt ebenfalls nicht zu der veröffentlichten Darstellung.
Ich mag derzeit nicht entscheiden, wer Recht hat. Die Gretchenfrage dürfte sein, ob 1&1 dem Betreiber mitgeteilt hat, dass der Server eine zu hohe Last hat und entweder eine andere Software oder ein größerer Server zu nehmen ist.
das ist in der tat die gretchenfrage. denn so wie es bei it&w dargestellt ist und wie ich auch aus eigener erfahrung bestätigen kann, gibt es bei 1und1 keine beratung. da heisst es dann, wir machen mal standardprozedur 1. wenns gut läuft, gibts auch standardprozedur 2. manchmal passiert halt auch nix, wenn man nicht tagelang hinterhertelefoniert.
ich habe mal um reinitialsierung eines selbst gemanagten 1und1 „rootservers“ gebeten. danach hat 1und1 mir eine linux verfsion draufgespielt mit der gar nix mehr ging. später erfuhr ich dann ich dann von der 1und1 hotline: „nee, mit der suse version und der hardware kann das ja auch nicht gehen“. inkompetenz-galore. doof bei einem dienstleister der via werbung kompetenz mit gemanagten servern vorgaukelt.
kurz, bei hohen ansprüchen die über gretchenwebseiten gehen, finger weg von 1und1. nichtsdestotrotz lief die it&w kiste ja über jahre relativ stabil, auch mit extremen spitzenbelastungen.
Volker:
Ist doch vollkommen wurscht, ob der Server zuviel Last hat oder nicht oder werauchimmer fingerpointet.
Wenn man eine Webapplikation fährt, diese bekannt und beliebt wird, und man sich nicht mit Dingen wie Skalierung und Caching auseinandersetzt, dann passiert sowas eben. Das ist der Grund, warum ich noch kein Blog habe. Der ganze Rotz da draussen ist eben Spielzeug. Sorry, wenn ich das so hart sage, aber es gibt kein konsequent durchdachtes skalierfähiges Blogsystem. Alle sind irgendwo nur eine schnelle "0.1" mit nem Haufen Patches.
Wer einen solchen Prototypen betreibt muss dann halt auch in den sauren Apfel beissen und z.B. die Implementation des Cache coden oder beauftragen. Whatever. Die Fingerpointerei macht - wie meist - eh keinen Sinn.
Gruss,
/k
naja, Karsten, ich weiß ja nicht, was bei Volker dahintersteht (hardwaremäßig), aber er hat sicherlich auch einen Megatraffic und starke Belastungen. Dennoch scheint mir der Blog hier sehr stabil zu laufen.
Ich verstehe auch nicht, was für eine Anforderung betreffs der Skalierbarkeit du an Blogsysteme hast?
Außerdem kannst du ja auch nicht davon ausgehen, dass wenn du anfängst zu bloggen die Sache in 0,nix in Ebenen wie it&w kommt ^^
Volker,
wie kommst Du auf 100k Seitenabrufe am Tag? IT&W + Mac Essentials erreichen allerhöchstens 15k, wenn's hoch kommt 20k.
-Muggel
MySql auf zweiten Server auslagern (mysqli hab ich noch nicht getestet, steht aber auf dem Zettel), Bytecode-Cache für PHP und vielleicht mal ein bisschen in den Code schauen und händisch optimieren und gut iss. Wer eine profilierte Site betreibt, der sollte zumindest Engagement mitbringen, da gebe ich Stefan völlig Recht. Und wers nicht kann, fragt jemanden. Ihr kennt den Sesamstraßen-Song? "Wer nicht fragt bleibt dumm."
Und weil man eben jemanden fragt wenn etwas nicht rund läuft, läuft das ganze auf Managed-Servern von 1und1. Die immerhin ab 79,- € im Monat kosten. Und unter anderem "Kostenlosen 24-h-Profi-Support, 7 Tage die Woche" beinhalten. Und deshalb sollte ja wenigstens irgendeine Form von Unterstützung vorhanden sein.
(Nur die beteiligten selber wissen vermutlich was wirklich genau passiert ist.)
Thomas, dieser Support bedeutet, dass jemand die ganze Basissoftware auf dem aktuellen Stand hält. Im Gegensatz zum Rootserver musst Du Dich nicht damit beschäftigen, ständig die neuesten Sicherheitspatches für Linux, MySQL, PHP etc einzuspielen.
Allerdings musst Du Deine Anwendungssoftware selbst betreiben. Und da fängt manchmal das Problem an. Weil Du keinen vollen Zugriff auf den Server hast, kannst Du nicht alles sehen. Wenn Deine eigene Software den Server zu Fall bringt, dann geht die Fingerzeigere los. Wer ist "schuld"?
Mike Muggel, ist das wirklich Dein Name? Naja, egal. 100.000 Seitenaufrufe erreicht it&w leicht. Im Oktober waren es 4 Mio.
