Serverprobleme der letzten Tage

Neuerungen am Spiel

Serverprobleme der letzten Tage

Beitragvon Plum am Mi Apr 26, 2006 1:15 pm

Hier die ausführliche Stellungnahme zu den Serverproblemen der letzten Tage:

Was ist passiert?

In den letzten Wochen kam es öfter zu Abstürzen des MySQL-Datenbankservers. Dieser verabschiedete sich unabhängig von der Last oder freien Systemresourcen mit einer unglaublich hilfreichen Fehlermeldung (sinngemäß: "Irgendwas ist kaputt!"). Das war nicht weiter schlimm, da die Datenbank sich selbst umgehend neugestartet hatte. Jedoch kam es dadurch zu "halb" ausgeführten Scripts, die komische Dinge passieren ließen. Zudem werden bei jedem Crash einer Datenbank Indexstrukturen zerstört, die ein schnelles Suchen in der Datenbank ermöglichen.
Nach ausgiebigen Recherchen zu dem Thema habe ich nun den Verursacher des Problems gefunden. Es ist ein Bug in der glibc6 der 64Bit NPLC-Version von Debian. Dieser Bug wurde in der stable Version von Debian-I386 gefixt, leider jedoch nicht für die 64Bit Version (was ich persönlich etwas sinnbefreit finde). Ich bin auf zwei Workarounds gestoßen, die im Netz rumflattern:
1.) installiere Fedora Core
2.) installiere Debian tesing + MySQL 5.0.20
Beides fand ich irgendwie nicht so prickelnd, da beide Distributionen wohl mehr Unstabilität und Sicherheitslöcher bringen, als der Datenbankcrash alle paar Tage, sprich man macht die Sache schlimmer, nicht besser.


Was bedeutet das nun?

Dadurch dass die Indizes zerstört werden, dauern Queries auf die Datebank danach sehr lange, bis die Indizes neu berechnet werden. Das hat zur Folge, dass sich immer mehr unverarbeitete Queries in der Warteschlang aufstapeln, bis die Datenbank diesen nicht mehr Herr wird - fällt die Datebank für eine Minute aus, so hat die Datenbank danach für 10 Minuten ca. 40-50 Mal so viel zu tun, wie im Höchstlastfall. Was die Folge daraus ist, kann sich jeder logisch an den Händen abzählen und wir haben es gestern und auch vorgestern schmerzlich erleben dürfen.
Außerdem quitieren alle zu dem Zeitpunkt des Absturzes laufende Skripst ihren Dienst, was zur Folge hat, dass halbfertig abgearbeite Skripte liegen bleiben, im Klartext heißt das im schlimmste Fall: Rohstoffe werden abgezogen aber keine Schiffe gebaut oder Schiffe werden vom Planeten abgezogen aber nicht mehr in eine Flotte gefüllt.
Im Hochlastbetrieb braucht die Datenbank dann pro Minute Ausfall je eine halbe Stunde um sich von Ihrem "Schluckauf" zu erholen.


Was haben wir nun getan und was werden wir noch tun?

1.) Der erste Schritt war, die Original MySQL Binaries (anstatt der selbst komplilierten Debian Version) aufzusetzen. Diese enthalten statisch verlinkte Libs, wir hoffen also, dass diese Binaries mit einer Bugfreien glibc Version kompiliert wurden. Leider ist momentan die offizlle stabile Version von MySQL 5.0.20 und für die Version 4... gibt es keinen Support mehr. Die Spaßvögel haben teilweise den Syntax ab Version 5 verändert, was zur Folge hat, dass der Code von Earth Lost für dieses Unterfangen an einigen Stellen umgebaut werden musste, was natürlich Zeit in Anspruch nahm und mir eine schlaflose Nacht gebracht hat. Dies ist nun erledigt und wir erhoffen uns, dass die Datenbank nun wieder einigermaßen stabil läuft.
2.) Der schnellere Webserver 2 (auf dem auch ein Teil Datenbank läuft) wurde erstmal vom Netz genommen und kümmert sich jetzt ausschließlich um seine angedachte Arbeit.
3.) Wir haben einen weiteren Server bestellt, der die Webserveraufgaben von Webserver 2 übernehmen soll. Webserver 1 ist zwar nicht an der Leistungsgrenze, jedoch liegen die Latenzzeiten (auch bekannt als Pings) zwischen den beiden Servern bei 5-20ms, was für eine solche Anwendung zu hoch ist und deshalb auch bei geringer Last die Ausführungszeiten der Seiten au
f ca. 800ms steigen lässt.
4.) Wir haben die Storage Engines der einzelnen Tabellen neu überdacht, einige weitere Tabellen wurde von MyISAM auf InnoDB umgestellt und mehr Parallelität zu erreichen.
5.) Wir werden nicht Spielrelevante Tabellen auf einen zweiten Datenbankserver auslagern (dazu gehören zum Beispiel Nachrichten). Davon sollten die User nicht allzuviel merken, jedoch sind hierzu auch viele Anpassungen im Quelltext nötig. (todo)


Was können wir nicht tun?

Der nächste logische Schritt, wäre ein MySQL Master-Slave-System oder einen MySQL-Cluster aufzubauen. Das würde heißen, mehrere Rechner spielen gleichzeitig eine Datenbank. Dies ist aber bei Projekten wie Browsergames nicht möglich, da hier der Read-Write-Ration (als das Verhältnis von lesenden Aktionen zu schreibenden Aktionen) zu gering ist, in diesem Stadium hilft es also nichts, die Last mit Rechenleistung todzuschlagen. Andere Spiele eröffnen dann schlicht und einfach eine neue Galaxie, mit einer völlig unabhängingen Datenbank, damit erledigt sich dieses Problem. Das wollen wir nicht. Wir haben die letzten Wochen überlegt, wie wir weiterhin ein stabiles und vor allem schnelles Earth Lost ermöglichen können - und haben wahrscheinlich einen Kompromiss dieser beiden Ansätze gefunden. Dazu jedoch erst mehr, wenn wir geprüft haben, ob das realisierbar ist und ob es die erhoffte Leistungsverteilung tatsächlich bringt.


Zusammenfassend kann ich nur sagen, dass ein Ausfall wie gestern Abend für alle ärgerlich ist, aber für uns das Team ist es wahrscheinlich noch ärgerlicher als für Euch. Wir können nicht mehr tun, als nus für die Ausfälle zu entschuldigen und entsprechende Maßnahmen zu ergreifen, dass die Performance wieder steigt.

Euer Plum + Team
Ich antworte nicht auf private Nachrichten, wer mit mir aus wichtigen Gründen in Kontakt treten will, der möge doch bitte den Bereich Kommunikation mit dem Team benutzen.

Der Highscore-Platz-1-Button
Benutzeravatar
Plum
Site Admin
Site Admin
 
Beiträge: 4031
Registriert: Di Jul 12, 2005 9:22 am

Zurück zu News

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast