anpera.net

Ich / wir sind mal wieder dabei die Datenbank zu optimieren. Zwar kommt man mit optimalen Queries, Indizes usw schon recht weit, aber eine der fiesesten Performancebremsen ist der ständige schreibende Zugriff auf eine MyISAM Accountstabelle.
Bei jedem Schreibvorgang sperrt MySQL die gesamte Tabelle mit einem Lock und alle nachkommenden Anfragen egal ob lesend oder schreibend müssen warten bis der Lock wieder gelöst wird. Besonders abends wenn hunderte Queries pro Sekunde einprasseln ist das ne üble Bremse. Ich vergleich das immer gerne mit einer Theaterkasse an der 10 Ticketverkäufer sitzen aber alle Kunden stellen sich nur bei einem an.
Mit MySQL Bordmitteln lässt sich da nicht viel machen und das Geld für einen Replikationsserver und Lastausgleich hab ich nicht :-)

Achtung, jetzt die Frage/der Vorschlag.
InnoDB Tabellen unterstützen ja Row-Level Locking das heisst wenn ein Thread einen Account schreibt können alle anderen derweile prima noch auf der Tabelle lesen/schreiben weil eben nur ein Tupel gesperrt wird und keine ganze Tabelle. Aber Row-level Locking ist natürlich viel aufwändiger zu verwalten als Table-Level Locking wie bei MyISAM. Hat da einer Erfahrung mit? Bringt das was? Ich hab wenig Lust das an meinem LifeSystem zu testen und auf meinem Testserver kann ich einfach nicht genug Last erzeugen um wirklich festzustellen obs was bringt oder nicht.

Also: MyISAM vs. InnoDB bei massiven Zugriffen auf eine Tabelle mit vielen Lese+Schreibvorgängen (jeweils ca. 50%). Gegen ganz andere Ideen hab ich auch nix einzuwenden (Nur MySQL ist Pflicht, ein weiterer SQL Server wäre kontraproduktiv)

_________________
Atrahor.de
http://www.atrahor.de/ci_images.php?id=1

Also ich habe seit meiner umstellung auf InnoDB nur gute Erfahrungen gemacht und bin auch froh über die weiteren Funktionalitäten (hier in erster Linie Foreign Keys aber auch transaktionen könnten mal interssant werden).

Soweit ich weiß ist InnoDB im Normalbetrieb spürbar schneller, wesshalb sie auch als Standard-Engine verfügbar ist. Wichtig ist es hier vor allem, ausreichend große Buffer zu wählen.

Leider kann ich dir keine konketen Zahlen bieten, ebensowenig aussagen über Hochlastbetrieb, aber vielleicht kannst du ja troptzdem etwas damit anfangen.

Auric

_________________
Mehr oder minder inaktiv

Ich kann Dir sagen, daß vor InnoDB am Tag max. 150 queries/sekunde durchgingen...
mit InnoDB (nicht für _alle_ Tabellen, sondern nur die stark frequentierten wie accounts, wo auch updates laufen und nicht nur select/insert) bin ich bei >280.

InnoDB ist gut wegen der Transaktionssicherheit, ich hatte aber auch schon (von irgendwoher) böse böse Hardwarefehler (anderes konnte ichs mir nicht erklären) wo dann die ganze Tabelle nicht mehr wiederherstellbar war.... hatte ich zweimal in einem Jahr.

Aber ich glaub die wenigsten nutzen das so stark, also sollte es kein Problem sein.

<--roots for InnoDB

_________________
Entwicklung Lotgd 1.2.2 +nb
1.2.1 +nb ist final

Bugreports/Testing erwünscht, http://nb-core.org

Wichtige Info für Programmierersucher:
viewtopic.php?f=34&t=4285

Ok, ich hab es mal gewagt.
Also der Geschwindigkeitszuwachs ist bei diesem Zugtiff echt deutlich spürbar, obwohl InnoDB laut Benchmarks ja etwa 200-300% langsamer als InnoDB bei einzelnen Abfragen ist. Tja, in dem Fall hat sich das jedenfalls sehr gelohnt.
Ich kann auf dem Live System schwerlich einen Benchmark ausführen, aber den Load+Seitengenerierungszeit kann ich sehr wohl vergleichen.
Vorher : 150 User, Load 5-7, Generierungszeit 0,5-3 Sekunden
Nachher: 150 User, Load 1-3, Generierungszeit 0,1-0,5 Sekunden
Das ist natürlich nicht repräsentativ und muss über einen längeren Zeitraum beobachtet werden, aber die Tendenz ist toll.
Jetzt müssen nur noch ein paar Deadlocks eliminiert werden. In diesem Fall alles Queries die die Accounts Tabelle komplett bearbeiten (alte Sessions entfernen usw.), aber dann bin ich happy. Ich hoffe es ist auch schön robust Und falls nicht gibts ja Backups :-)

_________________
Atrahor.de
http://www.atrahor.de/ci_images.php?id=1

backups....
innodb ist transaction lock-safe...aber um wirklich konsistente innodb backups zu machen bräuchtest eine hotbackup sache...

_________________
Entwicklung Lotgd 1.2.2 +nb
1.2.1 +nb ist final

Bugreports/Testing erwünscht, http://nb-core.org

Wichtige Info für Programmierersucher:
viewtopic.php?f=34&t=4285

die gibt es zwar direkt vom Hersteller, aber nicht ganz kostenlos, glaube ich...

_________________
Mehr oder minder inaktiv

für ne jahreslizenz irgendwas um die 600 dollar oder mehr...

ich hab den gedanken fix verworfen.

_________________
Entwicklung Lotgd 1.2.2 +nb
1.2.1 +nb ist final

Bugreports/Testing erwünscht, http://nb-core.org

Wichtige Info für Programmierersucher:
viewtopic.php?f=34&t=4285