63783
Apr 22, 2008, updated at Jul 16, 2008 (UTC)
7523
2
0
MySQL Datenbank unter Windows optimieren
Hallo!
Ich bin seit einiger Zeit schon im Internet auf der Suche nach Informationen zur Optimierung von MySQL-Servern auf Windows-Plattformen.
Ich finde allerdings immer nur Hinweise auf z.B. die Benchmark-Suite unter Linux oder eben den Beispiel-Konfigs wie huge usw.
Was ich bräuchte wäre eine Art HowTo oder Tutorial wo allgemein verständlich erklärt wird, was die einzelnen Konfigurationseinträge bewirken, damit ich die Konfiguration besser auf die jeweilige Datenbankstruktur unserer Kunden anpassen kann.
Szenario ist: Meine Firma vertreibt eine CRM-ERP-Lösung für kleine und mittlere Unternehmen. Im Hintergrund werkelt eine MySQL-Datenbank. Die Datenbanken unserer Kunden sind für MySQL-Verhältnisse eher klein (so im Schnitt 600MB-2GB verteilt auf etwa 140 Tabellen). Als Engine benutzen wir MyISAM. Allerdings ist die Grösse der einzelnen Tabellen von Kunde zu Kunde sehr unterschiedlich. Unsere Kunden haben zumeist kleinere Server mit 1, 2 oder 4gb RAM und Dual-Core Prozessoren.
Mit den einzelnen Beispiel-Konfigs erzielt man ja schon einigermassen passable Ergebnisse, aber ich hätte halt gern etwas mehr Kontrolle über die Einstellungen ohne gleich diverse Schulungen besuchen zu müssen.
Preisfrage: Kennt einer Links zu verständlichen Tutorials, HowTo's o.ä. oder wäre jemand so nett mir allgemein ein paar Tips geben?
Ideal wäre auch wenn es eine Möglichkeit gäbe Benchmarks der Datenbank unter Windows durchzuführen...
Danke für eure Mühe schon mal vorne weg :D
Ich bin seit einiger Zeit schon im Internet auf der Suche nach Informationen zur Optimierung von MySQL-Servern auf Windows-Plattformen.
Ich finde allerdings immer nur Hinweise auf z.B. die Benchmark-Suite unter Linux oder eben den Beispiel-Konfigs wie huge usw.
Was ich bräuchte wäre eine Art HowTo oder Tutorial wo allgemein verständlich erklärt wird, was die einzelnen Konfigurationseinträge bewirken, damit ich die Konfiguration besser auf die jeweilige Datenbankstruktur unserer Kunden anpassen kann.
Szenario ist: Meine Firma vertreibt eine CRM-ERP-Lösung für kleine und mittlere Unternehmen. Im Hintergrund werkelt eine MySQL-Datenbank. Die Datenbanken unserer Kunden sind für MySQL-Verhältnisse eher klein (so im Schnitt 600MB-2GB verteilt auf etwa 140 Tabellen). Als Engine benutzen wir MyISAM. Allerdings ist die Grösse der einzelnen Tabellen von Kunde zu Kunde sehr unterschiedlich. Unsere Kunden haben zumeist kleinere Server mit 1, 2 oder 4gb RAM und Dual-Core Prozessoren.
Mit den einzelnen Beispiel-Konfigs erzielt man ja schon einigermassen passable Ergebnisse, aber ich hätte halt gern etwas mehr Kontrolle über die Einstellungen ohne gleich diverse Schulungen besuchen zu müssen.
Preisfrage: Kennt einer Links zu verständlichen Tutorials, HowTo's o.ä. oder wäre jemand so nett mir allgemein ein paar Tips geben?
Ideal wäre auch wenn es eine Möglichkeit gäbe Benchmarks der Datenbank unter Windows durchzuführen...
Danke für eure Mühe schon mal vorne weg :D
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: 86073
Url: https://administrator.de/contentid/86073
Printed on: April 24, 2024 at 21:04 o'clock
2 Comments
Latest comment
Hi,
Links habe ich leider auch nicht - vielleicht helfen ein paar allgemeine Anmerkungen:
- Bei 2 GB Datenbank und 4 GB Ram im Server können fast alle Tabellen im RAM gehalten werden - gute Bedingungen und nicht "kleine Server". 32Bit-Windows hat den Nachteil, dass ein Prozess normal nur 2 GB Ram verwalten kann und max. 4 GB Ramnutzung insgesamt möglich sind - ausgenommen es wird PAE genutzt und das sehe ich bei MySQL nicht.
- Benutze für einen DB-Server mindestens 5 Platten und einen Raid-Controller, der Raid 0+1 kann. Die 0+1-Kombi bietet optimalen Datendurchsatz. Wenn der Controller auch noch mehrere Kanäle hat, dann sollten die Platten so angebunden werden, dass eine Platte des 0-Raids an einen Kanal und die andere Platte des 0-Raids an den anderen Kanal gebunden wird. Die 1-Raid-Konstruktion analog hierzu. Das gibt maximalen Datendurchsatz auf der Platte.
- Bei den Platten sind SAN-Türme i.d.R. noch performanter als interne SCSI-Raids - mit 2GBit/s FCAL ist ein Performancevorteil von 10-100 gegenüber SCSI möglich.
- Die Festplatten sollten zwar klein und zahlreich, aber schnell wie der Wind sein. 5 x 80 GB mit 15000 U/min sind besser als 2 x 250 GB mit 10000 U/Min. Es hat niemand behauptet, dass ein guter DB-Server billig ist
.
- Wenn noch ein paar Euro über sind, wären noch mehr Platten hilfreich, damit Datenbankdateien und Indexdateien auf unterschiedlichen Raids liegen können. Denkbar wäre bei 5 Platten auch, zwei Mal eine Spiegelung zu fahren, ein Spiegel für die Datenbanken, ein Spiegel für die Indexdateien.
- Die Logdateien sollten auch noch separat auf eine Platte gelegt werden - beispielsweise auf die separate OS-Partition.
- Das Betriebssystem sollte separate Platten haben - auch wenn es denn dann noch ein paar Euronen mehr kostet.
- Transaktionssicherheit ist extrem wichtig, gerade bei CRM - deshalb sollten mal umfangreiche Tests wegen gleichzeitigem Zugriff gemacht werden und eine transaktionssichere Engine wie InnoDB genutzt werden.
- Zitat aus der Doku von MySQL: "InnoDB wurde für maximale Leistung bei der Verarbeitung großer Datenmengen ausgelegt. Es gibt wohl keine andere festplattengestützte Speicher-Engine für relationale Datenbanken, die so effizient mit der CPU umgeht." (http://dev.mysql.com/doc/refman/5.1/de/innodb-overview.html)
- Schaut euch die Indizierung der Tabellen genau an - je weniger gemische Indizes umso besser. Welche Indizies zu setzen sind, hängt deutlich von der Abfrage ab. Wichtige Ergebnisspalten sollten indiziert sein - hier helfen nur Analyse der Queries. Übrigens - es ist nicht Aufgabe des Admins, die Queries umzubauen oder Indizes zu setzen, das sollten schon die Entwickler tun. Hier wird die Performance "verballert", nicht durch einen zu klein dimensionierten Server.
- Schau die Speicherparameter der Indizes an und vergleiche die mit den tatsächlich auf der Platte liegenden Größen der Indexdateien. Nach Möglichkeit sollten die häufig genutzten Indizes im Ram liegen, also Nachschauen welche das sind und bei den my.cnf-Settings schauen, wie der Ram entsprechend angepaßt werden kann.
- Bei den anderen Parametern eine Aussage zu treffen ist schwer - das hängt von der Applikation ab. Wenn es allgemeingültige Superduperperformanceoptionen geben würde, dann würden die Entwickler von MySQL die in die my.cnf zur Verteilung mit einbauen und gut is. Machen sie aber nicht, weil es die nicht gibt - das ist immer von der Anwendung abhängig.
- Manchmal hilft es, auch einen einfachen zusätzlichen Index zu setzen und man bekommt - obwohl mehr Ram gebraucht wird - einen Performanceschub von Faktor 10-100. Das ist applikationsabhängig.
Joa - das würde mir gerade so einfallen.
Grüße Mathias
Links habe ich leider auch nicht - vielleicht helfen ein paar allgemeine Anmerkungen:
- Bei 2 GB Datenbank und 4 GB Ram im Server können fast alle Tabellen im RAM gehalten werden - gute Bedingungen und nicht "kleine Server". 32Bit-Windows hat den Nachteil, dass ein Prozess normal nur 2 GB Ram verwalten kann und max. 4 GB Ramnutzung insgesamt möglich sind - ausgenommen es wird PAE genutzt und das sehe ich bei MySQL nicht.
- Benutze für einen DB-Server mindestens 5 Platten und einen Raid-Controller, der Raid 0+1 kann. Die 0+1-Kombi bietet optimalen Datendurchsatz. Wenn der Controller auch noch mehrere Kanäle hat, dann sollten die Platten so angebunden werden, dass eine Platte des 0-Raids an einen Kanal und die andere Platte des 0-Raids an den anderen Kanal gebunden wird. Die 1-Raid-Konstruktion analog hierzu. Das gibt maximalen Datendurchsatz auf der Platte.
- Bei den Platten sind SAN-Türme i.d.R. noch performanter als interne SCSI-Raids - mit 2GBit/s FCAL ist ein Performancevorteil von 10-100 gegenüber SCSI möglich.
- Die Festplatten sollten zwar klein und zahlreich, aber schnell wie der Wind sein. 5 x 80 GB mit 15000 U/min sind besser als 2 x 250 GB mit 10000 U/Min. Es hat niemand behauptet, dass ein guter DB-Server billig ist
.- Wenn noch ein paar Euro über sind, wären noch mehr Platten hilfreich, damit Datenbankdateien und Indexdateien auf unterschiedlichen Raids liegen können. Denkbar wäre bei 5 Platten auch, zwei Mal eine Spiegelung zu fahren, ein Spiegel für die Datenbanken, ein Spiegel für die Indexdateien.
- Die Logdateien sollten auch noch separat auf eine Platte gelegt werden - beispielsweise auf die separate OS-Partition.
- Das Betriebssystem sollte separate Platten haben - auch wenn es denn dann noch ein paar Euronen mehr kostet
.- Transaktionssicherheit ist extrem wichtig, gerade bei CRM - deshalb sollten mal umfangreiche Tests wegen gleichzeitigem Zugriff gemacht werden und eine transaktionssichere Engine wie InnoDB genutzt werden.
- Zitat aus der Doku von MySQL: "InnoDB wurde für maximale Leistung bei der Verarbeitung großer Datenmengen ausgelegt. Es gibt wohl keine andere festplattengestützte Speicher-Engine für relationale Datenbanken, die so effizient mit der CPU umgeht." (http://dev.mysql.com/doc/refman/5.1/de/innodb-overview.html)
- Schaut euch die Indizierung der Tabellen genau an - je weniger gemische Indizes umso besser. Welche Indizies zu setzen sind, hängt deutlich von der Abfrage ab. Wichtige Ergebnisspalten sollten indiziert sein - hier helfen nur Analyse der Queries. Übrigens - es ist nicht Aufgabe des Admins, die Queries umzubauen oder Indizes zu setzen, das sollten schon die Entwickler tun. Hier wird die Performance "verballert", nicht durch einen zu klein dimensionierten Server.
- Schau die Speicherparameter der Indizes an und vergleiche die mit den tatsächlich auf der Platte liegenden Größen der Indexdateien. Nach Möglichkeit sollten die häufig genutzten Indizes im Ram liegen, also Nachschauen welche das sind und bei den my.cnf-Settings schauen, wie der Ram entsprechend angepaßt werden kann.
- Bei den anderen Parametern eine Aussage zu treffen ist schwer - das hängt von der Applikation ab. Wenn es allgemeingültige Superduperperformanceoptionen geben würde, dann würden die Entwickler von MySQL die in die my.cnf zur Verteilung mit einbauen und gut is. Machen sie aber nicht, weil es die nicht gibt - das ist immer von der Anwendung abhängig.
- Manchmal hilft es, auch einen einfachen zusätzlichen Index zu setzen und man bekommt - obwohl mehr Ram gebraucht wird - einen Performanceschub von Faktor 10-100. Das ist applikationsabhängig.
Joa - das würde mir gerade so einfallen.
Grüße Mathias
Vielen Dank für die sehr ausführliche Antwort!
