Mangelhafte Serverkapazität?
Mangelhafte Serverkapazität?
Gestern kam es zu starken Problemen auf dem Webserver info3.
Ursache war, daß ein PHP-Skript zur Anmeldung von Kursen eines Instituts (Geschichte der Phil) eine unsägliche hohe Anzahl gleichzeitiger Sessions erlaubte und dabei auch jeweils mehrere MB Speicherplatz belegte.
Der Server war teilweise mit 255 gleichzeitigen, hochlastigen Aufträgen belegt, was auch die CPU-Last auf bis zu 100% trieb.
Es kamen leider zwei Dinge zusammen:
Zum einen wurde von dem Institut unterschätzt, daß sich so viele Studierende gleichzeitig anmelden.
Der Anmeldezeitraum geht zwar bis zum Oktober, man hat jedoch den Fehler gemacht, auf ein First-In-First-Come-Verfahren bei der Registrierung zu setzen und dies auch noch den Leuten mitzuteilen. Kein Wunder also, daß schon vor der offiziellen freischaltung um 12 Uhr der Server zu kochen begann…
In der Statistik sieht man das recht eindrucksvoll:
(In Worten: Von einer durchschnittlichen Zahl an 1861 Hits pro Tag, kam es zu einem Sprung auf 113855 Hits gestern. Sowie einer Steigerung der übertragenden 22.398 kB pro Tag von auf 39.391.844 kB.)
Der andere Fehler war die mangelnde Softwarelösung, die -ursprünglich nur für den kleinen Bereich der Theologie mit einer Handvoll Studierenden gemacht war- nicht auf den Ansturm so einer großen Zahl an gleichzeitigen Anwendern ausgelegt war. So werden laut Information des Kundens beispielsweise in der Anwendung Daten aus der UnivIS-XML-Schnittstelle direkt beim Aufruf ausgelesen, anstelle, daß man diese dann jeweils für eine kurze Zeit lang cacht.
(Wer schonmal XML geparst hat und auch das UnivIS-XML kennt, weiß, wie inperformant gerade solche Anfragen sind).
Gelöst wurde das Problem letzlich dadurch, daß wir das Skript dann auf der info9 laufen ließen, welche etwas stärker war und wo dann auch die Version 5.2.3 von PHP läuft, welche ebenfalls etwas besser mit dem Memory umgeht als die 5.0.5.
(Bei einem der üblichen Standardprovider wäre aber ob der gestrigen einbrechenden Serverlast keine billige Lösung rausgekommen. Jedenfalls hätte für 3,33 Euro pro Monat, die so ein Webauftritt bei uns kostet, kein rein kommerzieller Dienstleister den Finger krum gemacht.
Im Gegenteil ist bekannt, daß einige Provider bei einer solchen Last gleich eine Kündigung aussprechen, wechselt man nicht „freiwillig“ in ein höheres und teueres Housingpaket…)
Eine weitere Lösung ist natürlich immer möglich. Im Rahmen des gestrigen Fehlersuchens haben wir sie auch ergriffen. Die Lösung besteht darin, mittels RLimitCPU und RLimitMEM die verfügbaren Limits pro Webauftritt generell zu beschränken. Bzw. die einzelnen virtuellen Hosts über ein Clusterpark in virtuelle Container verpacken und darin jeweils eine feste, maximal Kapazität geben. So machen es ja auch viele Provider.
Das Problem bei dieser Lösung besteht eben darin, daß auf die Individualität der einzelnen Webauftritte keine Rücksicht mehr genommen wird. Jeder kriegt sein fest gelegtes Stück vom CPU/MEM/PROC-Kuchen und das wars. Egal, wieviel wirklich gebraucht wird. Bei den allermeisten Webauftritten wird so gut wie keine Last erzeugt. Warum sollte also Rechen- und Speicherleistung, die auf der einen Seite vorhanden und ungenutzt ist nicht von anderen Auftritten genutzt werden, die diese gerade brauchen?
(Wenn man sich beide Verfahrensstrategien anschaut und ordentlich vergleicht, kommt man im Prinzip wieder bei der Wartenschlangenmodellen an. {Vorlesungen für Kommunikationssysteme im Hauptstudium Informatik}. Wir haben eine potentiell unendliche Zahl an Jobs, die von einer endlichen Zahl an Systemen bearbeitet werden müssen. Die Jobs sind jedoch unterschiedlich groß. Des weiteren haben wir nur eine begrenzte Größe der Warteschlange.)
Von daher sind statische Container nicht unbedingt sinnvoll, bei einer stark heterogenen Landschaft an Webauftritten, welche wir unterstützen wollen.
Wenn man Provider wäre und Geld verdienen möchte, wäre das natürlich egal – denn da möchte man durch Limitierungen bei den kleinen Paketen ja eben die Kunden dazu verleiten auf teuere Housing-Pakete umzusteigen.
Eine Entlastung wird in Zukunft sicherlich die geplante Lastverteilung via Clustering werden.
Sprich: Wir werden zwar dieselben Rechner haben wie bisher, jedoch werden wir die ein Webauftritt macht, nicht mehr einen einzigen Server zuweisen, sondern ggf. allen.
Man darf hier nur nicht gleich naiv denken, dies ist die Lösung aller Probleme.
Denn wenn ein ausreichend dummes (oder gezielt ausgetüffteltes gemeines) Skript programmiert wurde, wird dieses dann halt nicht mehr nur ein Server belasten, sondern gleich alle.
Ggf. muss man dann doch wieder Limitierungen einfügen – wenn auch hohe.
(Die ersten Schritte dahin wurden ja schon gemacht. Wir sind derzeit dabei, die Server zu vereinheitlichen, indem wir Paketierungen vorantreiben und auf der anderen Seite hat der Auswahlprozess für einen neuen Fileserver begonnen, der die infofs ersetzen muss.
Aber leider dauert all das. )