Welt 14 wird umgezogen

[bwoebi]

@ bwoebi: Wie gesagt, DB auf Ramdisk ginge zwar, davon halte ich aber nicht sonderlich viel, da jeder Reset des Servers die DB zerstören würde. Und um sie konsistent zurück auf die Platte zu kriegen, muss ich alle Tables vorher flushen UND locken und erst nach der Kopie darf ich sie wieder unlocken. Das wäre ziemlich langsam und laggy. Und naja, wenn ich sie nur alle paar Stunden auf die Platten sichere, wäre mir das zu riskant.

Nein...

Ich denke auf eine ramdisk flushen sollte doch kein Problem sein? (was die lagzeit anbelangt)

So hab ich mir das vorgestellt:
- flushen
- locken
- kopie auf der ramdisk anlegen (innerhalb einiger ms)
- unlocken
- von der ramdisk-kopie auf die Platte schreiben
- ramdisk-Kopie löschen

Oder ist ein Table-Lock so lahm auf einer ramdisk?

[Sotrax]

@bwoebi: Ein Flush kann nach wie vor teilweise lange dauern, weil er warten muss bis alle Aktionen fertig sind, um Zweifelsfall muss also auf die langsamste Query gewartet werden die überhaupt gerade im System läuft.

Und weiterhin wären dennoch immer Datenverluste bei einem Reset da. (Und jede Minute die gesamte DB auf die Platte kopieren, naja, ob das schneller wäre ist leider fraglich).

Es gibt noch andere Arten, mit denen man das Verhalten verbessern kann, die sind aber recht komplex und müssen sehr ordentlich getestet werden, weil sich FW selbst dadurch anders verhalten könnte.

[bwoebi]

@Sotrax: während ja noch eine Query läuft sollte es doch keine Last geben?

Und ein Datenverlust von einer Minute ist jetzt kritisch?

Btw. ist ja die db-Kopie ganz im Hintergrund, abgekapselt vom Rest? Sollte keine Last erzeugen die im Spiel sichtbar ist - das ist das worum es mir geht

[Sotrax]

@bwoebi: Wie gesagt, das klappt so nicht, weil man alle tabellen mit read lock flushen muss. Den Lag merkt man deutlich, auch auf Ramdisk. Und jede Minute die komplette DB kopieren ist arg viel, das belastet auch die Platten sehr viel mehr als jetzt. Und bei einer Kopie von Ramdisk auf Ramdisk wird dann irgendwann doch der Speicher knapp bei mehreren Welten.

[bwoebi]

Okay, dann verzeih mir mein Halbwissen… Ich hab noch nie versucht eine derart große und viel gelesen und geänderte Datenbank zu verwalten

[Sotrax]

@bwoebi: Wie gesagt, da gibts nix zu entschuldigen, Problem ist generell, dass es nicht so viele Leute gibt die da mit sehr großen Systemen Erfahrung haben. Besonders weil jede Datenbank und anderes Lastverhalten hat. Was vielleicht für ein Forum super funktioniert, klappt für FW evt. überhaupt nicht. Die Ideen sind ja auch sehr gut, die hier kamen und sehr viel davon haben wir getestet.

Problem ist natürlich auch, dass es bei FW sehr wohl auf schnelle Auslieferung der Seiten ankommt. Ein Lag von einer halben Sekunde ist in einem Forum ab und an völlig egal und interessiert niemand.

Immerhin, einiges konnte verbessert werden, zwar können wir gerade maximal 2-3 Welten auf einem Server betreiben, aber das ist schon ein guter Anfang. Irgendwann werden wir wohl auch mal SSDs testen, damit sollte sich mehr machen lassen. Zumindest wissen wir mittlerweile wo das Problem liegt ^^

[bwoebi]

@Sotrax: Magst du es alle deine Sätze mit "Wie gesagt, " anzufangen?

Ich denke bloß SSDs nutzen heutzutage einfach noch zu schnell ab dafür...? Oder kannste jeden Monat im Schnitt 50 € zahlen nur um SSDs auszuwechseln?

[Blue.Shark]

@Sotrax: Magst du es alle deine Sätze mit "Wie gesagt, " anzufangen?

Wenn er sich wiederholt dann kann das Wort ruhig genutzt werden.

[bwoebi]

Hatte er aber noch nicht gesagt^^

[itgchris]

Immerhin, einiges konnte verbessert werden, zwar können wir gerade maximal 2-3 Welten auf einem Server betreiben, aber das ist schon ein guter Anfang. Irgendwann werden wir wohl auch mal SSDs testen, damit sollte sich mehr machen lassen. Zumindest wissen wir mittlerweile wo das Problem liegt ^^

Du hast doch sicher guten Kontakt mit dem RZ Betreiber? Vielleicht stellt er dir ne gute SAN (Fibre Channel) zur Verfügung das würde I/O Probleme auch lösen ohne das du den Weg über SSDs gehen musst. Natürlich ist das bei Hosting Platformen fast nicht möglich, aber vielleicht ist das ja bei euch drin vor allem Kostengünstig.

1.) Außerdem wäre es möglich InnoDB Platten direkt auf ein RAW Filesystem zu legen, somit hat man diverse Probleme nichtmehr sofern man InnoDB hat.
2.) Zweitens MariaDB verwenden. MariaDB ist wesentlich schneller als MySQL.
3.) Außerdem XFS benutzen. (https://www.facebook.com/note.php?note_ ... 1610933)// http://oss.sgi.com/projects/xfs/training/

Die letzten drei Dinge sind diese Dinge die ich zuerst benutzen würde. Bevor ich irgendwas anderes machen würde.

Btw. High Scale/Availabilty Databases/Websites sind immer schwer zu erreichen, gerade durch teure Manpower scaliert man meist horizontal, sprich man "schmeißt" Server gegen die Probleme. Was meist wesentlich günstiger ist. Das klingt zwar auf lange Zeit beschissen, dass ist aber gerade vielen Kunden egal, denn für Sie zählt meistens der Preis im gerade laufenden Quartal.

[Cembon]

InnoDB ist aber sehr, sehr langsam, merkt man v.a. dann, wenn man 100k Einträge auf einmal einfügen will.^^

[bwoebi]

@itgchris: 1) InnoDB ist lahm und kompliziert zu reparieren (auch wenns backups gibt, es ist trotzdem lästig wenn man es ohne macht).
2) mariaDB wurde jetzt in letzter Zeit besser… Aber auch nicht unbedingt das Wahre (Sotrax meinte mal er habe es schon mal versucht, hätte es jedoch aufgrund diverser Probleme/Nachteile aufgegeben)
3) da weiß ich jetzt nichts… ist mir neu ^^

[Sotrax]

InnoDB habe ich hier testweise auch mal laufen gehabt. Das Problem ist, die DB wird mit InnoDB in etwa doppelt so groß wie in MyISAM. InnoDB ist auch super wenn man Transaktionen braucht, die brauchen wir aber fast nicht in FW. InnoDB hat allerdings in der Tat mehr Einstellungen was das I/O Verhalten anbelangt.

InnoDB ist auch in mancher Hinsicht deutlich schneller als MyISAM, je nach Anwendungsfall. Unterm Strich ists mir aber noch zu groß und bringt mir jetzt noch nicht genug Vorteile zu MyISAM, allerdings kann es durchaus sein, dass wir eines Tages zu InnoDB wechseln. In Tests lief es zumindest (auch wenn die konvertierung leider ewig dauert, länger als eine Stunde ). Auch ist das Verhalten von InnoDB anders, da müsste man sehr ausführliche Langzeittests machen, da mit InnoDB deadlocks auftreten können (ob sie defakto in FW auftreten würden in der Praxis weiß ich nicht).

MariaDB hatten wir in W3/4 lange Zeit am laufen, allerdings gab es dort eher Probleme damit, daher sind wir da wieder zu MySQL gewechselt. Seit MySQL 5.5 wurden auch ein paar Dinge da verbessert, so dass der Vorteil von MariaDB nicht mehr so groß ist. (Zugegeben, das ist auch schon wieder ein Jahr her, MariaDB mag seitdem besser geworden sein).

Dateisysteme haben wir bereits mehrere durchgetestet, leider haben sie keinen großen Unterschied gemacht.

Was I/O mässig bei MyISAM einen riesigen Unterschied macht, ist DELAY KEY WRITES einzuschalten, dann geht die I/O Last um 50% sofort zurück. Allerdings mache ich das eher ungern, weil Flushes der DB dann irre lahm werden und auch ein recovern der DB sehr viel langsamer wird, weil alle Indizes bei einem Crash neu berechnet werden müssen.

@itgchris: Ein paar LUNs auf einem schnellen FibreChannel SAN zu bekommen wäre natürlich das beste, das bietet nur unser RZ anbieter leider nicht an, und da wo es angeboten wird, sind wieder die Server schweineteuer.

@bwoebi: Also SSDs muss ich einfach mal schauen, ich höre eher schlechtes von SSDs in DB Servern in den Foren (teilweise mussten andere betreiber sie im 2 Monatstakt tauschen), aber generell wäre ich durchaus bereit es mal mit einer SSD zu versuchen.

[Sotrax]

@itgchris: Übrigens habe ich es es gerade mal auf XFS umgestellt. Der Artikel ist auf jedenfall interessant, davor war es gerade auf EXT4 und davor auf ReiserFS. Mal schauen

[Sotrax]

Kurzer Statusbericht: W11/12 laufen gerade auf dem alten Server mit XFS ziemlich gut, I/O ist zwar gleich hoch, aber es scheint in der Tat dabei weniger bis gar nicht mehr zu laggen. Ich muss mal noch eine dritte Welt draufziehen um das genauer zu sagen.