3
Literaturempfehlung zu MySQL-Performanceoptimierung
Hallo alle zusammen,
Ich suche Literatur (Bücher, Tutorials etc.) zur serverseitigen Optimierung der MySQL-Performance. Also Auswirkungen der verschiedenen Cache-Parameter bei bestimmten Zugriffsszenarien sowie Ermittlung des konkreten Optimierungsbedarfs.
Das meiste das ich bisher gefunden habe befasst sich mit der scriptseitigen Optimierung, was mir aber erstmal nichts nützt da einige der hier eingesetzten SQL-Clients nur als Binary vorliegen und eh nicht geändert werden können. Diese schicken den MySQL-Server regelmäßig ins Nirvana bei größeren Abfrage-Aktionen. Da diese Abstürze aber nicht jedesmal auftreten sondern eine bestimmte Korrelation zur allgemeinen Lastsituation aufweisen, müsste vermutlich ich die Serverparameter ändern. Ins Blaue hinein per Try&Error-Methode will ich da nicht dran rumschrauben.
Grüße
Cody
Ich suche Literatur (Bücher, Tutorials etc.) zur serverseitigen Optimierung der MySQL-Performance. Also Auswirkungen der verschiedenen Cache-Parameter bei bestimmten Zugriffsszenarien sowie Ermittlung des konkreten Optimierungsbedarfs.
Das meiste das ich bisher gefunden habe befasst sich mit der scriptseitigen Optimierung, was mir aber erstmal nichts nützt da einige der hier eingesetzten SQL-Clients nur als Binary vorliegen und eh nicht geändert werden können. Diese schicken den MySQL-Server regelmäßig ins Nirvana bei größeren Abfrage-Aktionen. Da diese Abstürze aber nicht jedesmal auftreten sondern eine bestimmte Korrelation zur allgemeinen Lastsituation aufweisen, müsste vermutlich ich die Serverparameter ändern. Ins Blaue hinein per Try&Error-Methode will ich da nicht dran rumschrauben.
Grüße
Cody
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 131381
Url: https://administrator.de/contentid/131381
Printed on: April 20, 2024 at 06:04 o'clock
3 Comments
Latest comment
Naja - das Problem ist ja erstmal das Leck zu finden. Denn es gibt leider bei einem SQL-Server nicht "DIE Optimierung". Nen großer Cache ist gut wenn du viele lesende Abfragen hast - wenn dein System aber viele Dinge in die DB schreibt muss immer auch nen Cache-Flush erfolgen was wieder zeit kostet. Gleichzeitig kommt es auf dein OS an -> wenn du z.B. nen Linux hast dann kannst du den Cache aufreissen bis zum Ende - verlierst dafür aber RAM den dein System sonst als Filecache vorhält um die Tabellen nicht jedesmal von der HDD lesen zu müssen.
Was du aber gut machen kannst: Dir z.B. mittels MySQL-Administrator die Randwerte erstmal ansehen: Wieviele Abfragen hast du überhaupt, wieviele Tabellen werden geöffnet usw. (Gern gemachter Fehler bei den Anwendungsprogrammieren: Man öffnet und schließt jedes mal die Verbindung zur DB inkl. kompletten login/logout. DAS kostet natürlich sehr viel Zeit... Oder man öffnet halt für jedes Objekt (in der OO-Programmierung) eine neue Verbindung - wodurch du dann schnell mal einige 100 Connections offen hast obwohl nur 1-2 Leute arbeiten...). Deshalb wird man immer zuerst die Anwendungen ansehen - und DANACH erst den DB-Server selbst anfassen...
Was du aber gut machen kannst: Dir z.B. mittels MySQL-Administrator die Randwerte erstmal ansehen: Wieviele Abfragen hast du überhaupt, wieviele Tabellen werden geöffnet usw. (Gern gemachter Fehler bei den Anwendungsprogrammieren: Man öffnet und schließt jedes mal die Verbindung zur DB inkl. kompletten login/logout. DAS kostet natürlich sehr viel Zeit... Oder man öffnet halt für jedes Objekt (in der OO-Programmierung) eine neue Verbindung - wodurch du dann schnell mal einige 100 Connections offen hast obwohl nur 1-2 Leute arbeiten...). Deshalb wird man immer zuerst die Anwendungen ansehen - und DANACH erst den DB-Server selbst anfassen...
Tach,
also das imho beste Buch zur Performance-Optimierung von MySQL ist das "MySQL Performance" Buch --> http://bit.ly/6SPouj
Hab das hier neben mir liegen und bis jetzt wurde ich noch nicht enttäuscht. Ist von den Percona (http://www.percona.com/) Leuten geschrieben (wohl die Pro's am Markt was Optimierung und Plannung von MySQL angeht).
Ich würde dir allerdings auch erst einmal einen Check des Server's empfehlen. Wie schicken zb die Apps den Server in's Nirvana, steht davon was in den Log's?
MfG
also das imho beste Buch zur Performance-Optimierung von MySQL ist das "MySQL Performance" Buch --> http://bit.ly/6SPouj
Hab das hier neben mir liegen und bis jetzt wurde ich noch nicht enttäuscht. Ist von den Percona (http://www.percona.com/) Leuten geschrieben (wohl die Pro's am Markt was Optimierung und Plannung von MySQL angeht).
Ich würde dir allerdings auch erst einmal einen Check des Server's empfehlen. Wie schicken zb die Apps den Server in's Nirvana, steht davon was in den Log's?
MfG
Hallo!
maretz war schon verdammt nah dran am Problem. Die Anwendung arbeitet mit zwei verschiedenen Datenbanken gleichzeitig, die aber von ein und der selben MySQL-Server-Instanz gehostet werden. Vermutlich wird zwischen beiden Datenbanken mehrmals neu connected. In 99% aller Fälle arbeitet die Anwendung nur mit einzelnen Datensätzen, meistens lesend. Das ist auch gar kein Problem. Es gibt eine Aktion, bei der über den gesamten Datenbestand einer Tabelle iteriert wird und dann pro Datensatz auch noch eine Verbindung zur zweiten Datenbank genutzt wird. Ob da jedesmal eine neue Connection aufgemacht wird oder eine persistente Verbindung neu aufgegriffen wird, kann ich so erstmal nicht sagen.
Langfristig werde ich die beiden Datenbanken zu einer einzigen vereinigen und die Zugriffe versuchen per View bzw. Procedure umzubiegen. Die MySQL-Optimierung soll nur bis dahin überbrücken.
In ferner Zukunft wird dann auch mal hoffentlich die Anwendung angepasst um das Problem grundsätzlich aus der Welt zu schaffen.
Grüße
Cody
maretz war schon verdammt nah dran am Problem. Die Anwendung arbeitet mit zwei verschiedenen Datenbanken gleichzeitig, die aber von ein und der selben MySQL-Server-Instanz gehostet werden. Vermutlich wird zwischen beiden Datenbanken mehrmals neu connected. In 99% aller Fälle arbeitet die Anwendung nur mit einzelnen Datensätzen, meistens lesend. Das ist auch gar kein Problem. Es gibt eine Aktion, bei der über den gesamten Datenbestand einer Tabelle iteriert wird und dann pro Datensatz auch noch eine Verbindung zur zweiten Datenbank genutzt wird. Ob da jedesmal eine neue Connection aufgemacht wird oder eine persistente Verbindung neu aufgegriffen wird, kann ich so erstmal nicht sagen.
Langfristig werde ich die beiden Datenbanken zu einer einzigen vereinigen und die Zugriffe versuchen per View bzw. Procedure umzubiegen. Die MySQL-Optimierung soll nur bis dahin überbrücken.
In ferner Zukunft wird dann auch mal hoffentlich die Anwendung angepasst um das Problem grundsätzlich aus der Welt zu schaffen.
Grüße
Cody
