Welt 14 wird umgezogen

[Oggy]

habe seit heute mittag heftige lags zusammen mit verbindungseinbrüchen von bis zu einer minute, dann läuft wieder alles flüssig, dann wieder lag oder dc...
inet ist in ordnung & bin ja nicht der einzige mit den lags in der welt :/

[Cembon]

viewtopic.php?f=2&t=51441
Hier werden inzwischen alle Lags wegen dem Umzug gesammelt

[Sotrax]

Welt 14 wird ebenfalls vom aktuellen Server auf einen anderen Server verlegt, um die Lags zu reduzieren.

[Sotrax]

Und schon fertig. Sind die Lags jetzt bereits weniger?

[itgchris]

Also rein von der CPU her würde der Server evt. sogar alle 14 Nummernwelten verkraften, aber das wird von den Festplatten und der I/O her dann nicht mehr gehen

Dann bau das ganze doch auf einen Server mit 2-4 Raid Controller und hau halt da 7-14 Festplatten rein, dann würde das ganze passen.
Oder Lager den Storage und unnötige Sachen auf ein CDN aus. Dann haste mininmale I/O.

Oder du schaust dir Amazon EC2 an. Da könntest wahrscheinlich alles auf eine Instanz packen. Das wäre eh am sinnvollsten, du baust deine Software so das Sie "Clusterfähig" wird. Sodass du quasi alle Server auf eine Instanz packst und bei größerer Last eine zweite Instanz automatisch dazu buchst oder eine dritte, je nachdem. Somit sparst du gerade nachts. Geht natürlich auch bei anderen Cloud Provider. Rackspace z.b.

> http://ontwik.com/python/django-deploym ... plan-moss/
Da steht zwar Django, aber es geht hier nicht nur um Django Deployment sondern Anwendungen @ Scale laufen.
Gibt auch gute deutsche Provider für solche Geschichten.

[Sotrax]

@itgchris: Es ist letztendlich auch eine Kostenfrage. Wir wollen natürlich möglichst maximale Performance bei minimalen Kosten.

EC2 habe ich mir schon genau wie Azure angeschaut, leider ist es wenn mans umrechnet nicht wirklich billiger, gerade der Traffic kostet da halt jeweils noch extra und die Stundenpreise sind hochgerechnet dann auch nicht ohne. Die Cloud-Lösungen sind vor Allem sehr stark, wenn man manchmal enormen Andrang hat und manchmal fast nix los ist. Bei FW lohnen sie sich derzeit eher noch nicht.

Auf dem neuen Server den wir jetzt gerade testen scheint das I/O Problem so groß zumindest nicht mehr vorhanden zu sein, wir setzen da jetzt einfach auf ein anderes Motherboard und andere Festplatten. Ich vermute da fast schon einen Bug.

Eine Lösung wäre sicherlich auch auf SSDs zu gehen, denen vertraue ich dafür aber noch nicht genug (kenne mehrere Firmen, denen die SSDs bei hoher DB Last im Schnitt alle 2 Monate ausgefallen sind, das ist mir einfach noch zu unsicher).

Super ist aber mittlerweile überhaupt die Möglichkeit, dass wir eine Freewar-Welt mit nur 3 Minuten Downtime umziehen können, so sind wir auch in Zukunft flexibel und können sobald sich bessere Angebote ergeben weiter umziehen. Ich werde da den Markt auch im Blick behalten.

Schauen wir erstmal wie viel der neue Server bringt.

[itgchris]

@itgchris: Es ist letztendlich auch eine Kostenfrage. Wir wollen natürlich möglichst maximale Performance bei minimalen Kosten.

EC2 habe ich mir schon genau wie Azure angeschaut, leider ist es wenn mans umrechnet nicht wirklich billiger, gerade der Traffic kostet da halt jeweils noch extra und die Stundenpreise sind hochgerechnet dann auch nicht ohne. Die Cloud-Lösungen sind vor Allem sehr stark, wenn man manchmal enormen Andrang hat und manchmal fast nix los ist. Bei FW lohnen sie sich derzeit eher noch nicht.

Auf dem neuen Server den wir jetzt gerade testen scheint das I/O Problem so groß zumindest nicht mehr vorhanden zu sein, wir setzen da jetzt einfach auf ein anderes Motherboard und andere Festplatten. Ich vermute da fast schon einen Bug.

Eine Lösung wäre sicherlich auch auf SSDs zu gehen, denen vertraue ich dafür aber noch nicht genug (kenne mehrere Firmen, denen die SSDs bei hoher DB Last im Schnitt alle 2 Monate ausgefallen sind, das ist mir einfach noch zu unsicher).

Super ist aber mittlerweile überhaupt die Möglichkeit, dass wir eine Freewar-Welt mit nur 3 Minuten Downtime umziehen können, so sind wir auch in Zukunft flexibel und können sobald sich bessere Angebote ergeben weiter umziehen. Ich werde da den Markt auch im Blick behalten.

Schauen wir erstmal wie viel der neue Server bringt.

Nun relativ Amazon EC2 ist schon recht teuer es gibt aber auch viele alternativen wie z.b. OpenShift oder eben RackSpace. Der Vorteil ist halt, dass du dir keine Probleme über Datenbankperformance etc machen musst, je nachdem wie du halt Deployst. Amazon EC2 kann Kosten sparen aber dazu musst du halt in etwa Wissen wie extrem du eine Instanz belasten kannst mit Freewar z.b. Ab dem Punkt wo du das weisst, kannste ja so ein Ding testen und die Kleinste oder Mittlere Instanzen nehmen die viel. Kostengünstig sind und dann halt neue Zubuchen wenn die Belastung hoch geht.

[Sotrax]

@itgchris: Ich hab nen EC2 Account, finde es aber schon enorm teuer, wenn ich eine Instanz mit 16 GB Ram haben will zahlt man schon irre Summen im Monat wo noch Traffic und Speicherplatz hinzukommt. (Und jeder neue FW Server hat 6 TB Plattenspeicher drin, alleine der ist bei Amazon in der Größe richtig teuer). Dazu kommt, dass der Ping zu Amazon deutlich schlechter als zu den FW Servern ist, da die Server dort halt in Irland stehen.

Auch kommen weitere Kosten hinzu, die bei deutschen Anbeitern viel einfacher und leichter zu machen sind, Stichwort Steuer. Amazon muss man im Ausland bezahlen, man hat also die Mwst nicht direkt drauf, was es auch für den Steuerberater komplexer macht und die muss man noch extra hinzuzählen.

Was bei Amazon aber gut ist, wenn man nur mal kurz für paar Tage eine Instanz braucht. Ich hab da sozusagen eine Reserveinstanz die ich für FW anschalten kann um einen Server notmäßig für ein paar Tage zu verwenden.

Ich werde auf dem alten Server aber auch noch ein paar Tests fahren, da sich die I/O Leistung auch je nach Filesystem ändern kann und andere Filesysteme könnten da evt. auch mehr Performance liefern.

[itgchris]

Was bei Amazon aber gut ist, wenn man nur mal kurz für paar Tage eine Instanz braucht. Ich hab da sozusagen eine Reserveinstanz die ich für FW anschalten kann um einen Server notmäßig für ein paar Tage zu verwenden.

Ich werde auf dem alten Server aber auch noch ein paar Tests fahren, da sich die I/O Leistung auch je nach Filesystem ändern kann und andere Filesysteme könnten da evt. auch mehr Performance liefern.

Nun das mit den VAT ist egal, wir bestellen immer Server aus England, die wollen die VAT auch garnicht haben, ergo musst du das nur angeben das es VAT frei ist. Geht natürlich nur bei Firmenkunden.

Ja z.b. ZFS könnte einiges bringen, auch wenn ich echt nicht weiß warum FW ca. 6 TB Festplattenspeicher hat. Und wie schon erwähnt I/O kannste runterdrücken, wenn du ein günstiges CDN hast, dadurch könntest du dann echt noch einiges gut machen und vielleicht macht ein CDN es günstiger, aber nur vielleicht.

Und ja Amazon kann für kleinere Kunden sehr teuer sein, da ist was dran. Aber es gibt immer Mittel und wege Einsparungen zu machen, denke ich.

Wobei I/O Probleme ja eher nach Probleme im Source Code klingt. An sowas wie Race Conditions schon gedacht? Oder, noch besser du cacht das ganze ein bisschen mehr.

[Sotrax]

@itgchris: Wie gesagt die I/O Probleme sind nur auf der Datenbank, nicht auf den Scripten, die liegen bereits auf einer anderen Platte. Und sie kommen eben nur beim Flush des Servers, sprich es wird alles gut gecached, aber ab und an kommt halt ein Flush wo die Daten aus dem Speicher zurückgeschrieben werden und während dies so ungefähr 0,4 Sekunden dauert, erlebt man einen kleinen Lag.

Seit wir Toshiba statt Seagate Platten im neuen Server einsetzen ist das Problem da großteils zum Glück aber weg. Wir haben da wie gesagt sehr viel versucht, so 100% in den Griff zu kriegen war es auf dem alten Server nicht (wir haben auch den I/O Scheduler geändert und , die nr_request queues angepasst etcetc.). Was ging war den Flush seltener zu machen, das ist möglich dann laggt es z.B. 30 Minuten kein bisschen aber dann kommt eben ein Mega-Lag sobald er alle dirty-pages zurück auf die Platte schreiben muss.

Das was wohl komplett helfen würde ist: Die Datenbank komplett auf eine Ramdisk legen. Ist mir aber viel zu unsicher, wenn bei jedem Server Neustart gleich alles weg ist. Oder eben eine SSD einsetzen, sie allerdings leider noch nicht wirklich zuverlässig sind, wenn man keine Enterprise SSD einsetzt (nach 72 TB schreiben sind die meisten einfach kaputt). Dafür sind SSDs dann noch zu teuer. Sobald diese deutlich billiger zu haben sind, kann ich es damit durchaus mal testen, allerdings befürchte ich halt, dass man bei SSDs mit rechnen muss, dass sie einmal im Jahr auch ausfallen.

Was man auch noch machen könnte wäre ein Raid 0.... will ich aber ebenfalls nicht, weil zu unsicher.

Auch Write-back cache der Platten an und abschalten hilft nicht.

Aber wie gesagt, solange wir auf den ganz neuen Server nur maximal 3 Welten draufpacken ist es soweit ok.

[Gangrils]

@ Sotrax

Bei deinem Text bekomme ich Flausen im Kopf. Kannst du das auch auf Deutsch übersetzen XD

Enterprise habe ich verstanden, da gings aber nicht um das Raumschiff nehme ich an

[Sotrax]

@Gangrils: Muss man zum Glück als Spieler auch nicht verstehen

[bwoebi]

@Sotrax: Datenbanken auf ramdisk? Wie groß ist denn deine Db? Von einer ramdisk kann man evtl. ja zwischen den flushs (ich denke ja, dass flushs auf eine ramdisk eher unter 50 ms liegen sollten? = kein Lag?) alle paar Minuten eine Kopie anlegen und die Kopie dann auf der Festplatte speichern? Denn Kopieren von der ramdisk auf die ramdisk sollte ja superschnell gehen (mit einigen GB/s) und dann kann man ja die Kopie "langsam" auf die Platte kopieren und dann löschen.

@Gangrils: So manches im Leben muss man nicht verstehen?

[Sotrax]

@ 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.

[Flummi]

Dann kann man die Sponsorzeiten ja wieder hochschrauben, herrlich.