mysql langsam?
- Ersteller Marcs
- Erstellt am
Sascha Ahlers
Legendäres Mitglied
Also, ich kann ja mal in meine Glaskugel schauen, vielleicht sagt sie mir ja was...
Jürgen Auer
Legendäres Mitglied
Da gibt es Möglichkeiten wie Sand am Meer.
Zuwenige Indices, zu viele Indices, die falschen Indices - alleine das ist eine Wissenschaft für sich.
Sperr- und andere Parallelitätsprobleme, zuwenig Speicher, zu langsame Festplatte.
Details kenne ich von mySql ohnehin nicht. Innerhalb von Server-Daten bin ich mal drüber gestolpert, daß dynamische Sortierungen mit Case-Verzweigungen zu einem MaxDop 1 - Ausführungsplan führten, so daß nicht mehrere Kerne gemeinsam genutzt wurden.
Einen externen Db-Server und eine 10-MBit-Netzwerkkarte schließe ich mal aus
Zuwenige Indices, zu viele Indices, die falschen Indices - alleine das ist eine Wissenschaft für sich.
Sperr- und andere Parallelitätsprobleme, zuwenig Speicher, zu langsame Festplatte.
Details kenne ich von mySql ohnehin nicht. Innerhalb von Server-Daten bin ich mal drüber gestolpert, daß dynamische Sortierungen mit Case-Verzweigungen zu einem MaxDop 1 - Ausführungsplan führten, so daß nicht mehrere Kerne gemeinsam genutzt wurden.
Einen externen Db-Server und eine 10-MBit-Netzwerkkarte schließe ich mal aus
Dann heisst es mal weitersuchen
... dachte einfach das vielleicht jemand gerade eine spontane Idee dafür hätte...
Ich kenne mich damit ehrlich gesagt zu wenig aus, habe mit Systemarchitektur nicht viel am Hut.
QUOTE Einen externen Db-Server und eine 10-MBit-Netzwerkkarte schließe ich mal aus
Ist ein 35+ GHz Computercluster mit iSCSI Storage... ist 1Gbit geswitcht (hat man mir mal gesagt)
Ich kenne mich damit ehrlich gesagt zu wenig aus, habe mit Systemarchitektur nicht viel am Hut.
QUOTE Einen externen Db-Server und eine 10-MBit-Netzwerkkarte schließe ich mal aus
Ist ein 35+ GHz Computercluster mit iSCSI Storage... ist 1Gbit geswitcht (hat man mir mal gesagt)
Jürgen Auer
Legendäres Mitglied
QUOTE (easyswiss @ So 2.05.2010, 00:39)Ist ein 35+ GHz Computercluster mit iSCSI Storage... ist 1Gbit geswitcht (hat man mir mal gesagt)
Ich kenne die Details von mySql nicht.
Aber kommt die verwendete mySql-Lizenz überhaupt mit dieser Architektur klar?
Bsp. gibt es beim Microsoft-SqlServer die kostenlose Version - aber die unterstützt nur (wenn ich es richtig in Erinnerung habe) 2 GB Arbeitsspeicher und einen Kern, kann also mehr Hardware gar nicht nutzen.
Es gibt von mySql auch eine Enterprise-Version: Was kann die stattdessen? Alles, was da explizit drinsteht, dürfte die normale Version eher nicht unterstützen.
Grundsätzlich fände ich es eher merkwürdig, eine ISAM - Datenbank (nicht transaktionssicher - der Standard bei mySql) auf einem Cluster zu betreiben.
Und zwischen ISAM und der transaktionssicheren Variante gibt es m.W. nach Performanceunterschiede.
Die Nichtauslastung hört sich eigentlich nach einem zu langsamen Festplattenzugriff an, so daß die CPU auf die Festplatte wartet.
Edit: Oder ist es denkbar, daß man mySql mit entsprechenden Schaltern kompilieren muß, damit bsp. solche Storage-Systeme bzw. sehr großer Arbeitsspeicher effizient unterstützt wird?
Ich kenne die Details von mySql nicht.
Aber kommt die verwendete mySql-Lizenz überhaupt mit dieser Architektur klar?
Bsp. gibt es beim Microsoft-SqlServer die kostenlose Version - aber die unterstützt nur (wenn ich es richtig in Erinnerung habe) 2 GB Arbeitsspeicher und einen Kern, kann also mehr Hardware gar nicht nutzen.
Es gibt von mySql auch eine Enterprise-Version: Was kann die stattdessen? Alles, was da explizit drinsteht, dürfte die normale Version eher nicht unterstützen.
Grundsätzlich fände ich es eher merkwürdig, eine ISAM - Datenbank (nicht transaktionssicher - der Standard bei mySql) auf einem Cluster zu betreiben.
Und zwischen ISAM und der transaktionssicheren Variante gibt es m.W. nach Performanceunterschiede.
Die Nichtauslastung hört sich eigentlich nach einem zu langsamen Festplattenzugriff an, so daß die CPU auf die Festplatte wartet.
Edit: Oder ist es denkbar, daß man mySql mit entsprechenden Schaltern kompilieren muß, damit bsp. solche Storage-Systeme bzw. sehr großer Arbeitsspeicher effizient unterstützt wird?
Bei mir kam es mal vor, dass die Verbindungen zu einer neuen Instanz sehr langsam aufgebaut wurden. Erst nach einigen hundert Verbindungen wurde es schnell. Probier dich mal mit dem Kommandozeilentool einzuloggen und achte auf die benötigte Zeit zum Verbindungsaufbau.
Michael Bieri
Angesehenes Mitglied
Versuch mal das ganze gezielt einzugrenzen. Tests mittels Browser<->PHP<->mySQL sind hier sicherlich nicht besonders hilfreich. Teste den DB Server zuerst lokal, dann vom Frontendserver aus, immer über die Konsole. Guck auch mal was deine DB so macht (mySQL Konsole: SHOW FULL PROCESSLIST). Wichtig wäre hier auch die Anzahl offener Connections die auf "sleep" hängen.
Mit den bis jetzt vorhanden Infos ist es allerdings wirklich ein Fall für die Glaskugel.
Sollte es wirklich die mySQL-Instanz sein die lahmt, wären Angaben zu Virtualisierung, Filesystem, Mountoptionen, Kernel, Netzwerksetup, mySQL-Setup etc. notwendig. Ich gehe aber kaum davon aus dass du sowas öffentlich bereitstellst
Mit den bis jetzt vorhanden Infos ist es allerdings wirklich ein Fall für die Glaskugel.
Sollte es wirklich die mySQL-Instanz sein die lahmt, wären Angaben zu Virtualisierung, Filesystem, Mountoptionen, Kernel, Netzwerksetup, mySQL-Setup etc. notwendig. Ich gehe aber kaum davon aus dass du sowas öffentlich bereitstellst