nicht angemeldet
MySQL beschleunigen oder parallel laufen lassen?
Hallo,
ich hoffe hier fachkundigen Rat von Euch zu erhalten, ich habe folgendes Problem:
wir sind gerade mit unserer Website, die sehr datenbanklastig ist, auf einen neuen Server umgezogen, der zwei Prozessoren mit je zwei Kernen hat und deutlich mehr leistet als der alte.
Versprochen haben wir uns natürlich in unserer Naivität einen Performanceschub. Nun stellen wir ernüchtert fest, dass letztendlich alles weiterhin an MySQL hängt und dieses voll ausgelastet ist. Es scheint, als würde sich die Maschine größtenteils langweilen und nur auf MySQL warten.
Frage nun: was tun?
Zwei Trivialitäten sein mal vorweg als bekannt gegeben:
1. wir müssen den Code weiter optimieren, um weniger MySQL Abragen zu erzeugen und so die Last zu mindern.
2. wir könnten zwei Maschinen mit separaten Datenbanken fahren und diese syncen, was uns aber erstmal zu aufwändig erscheint.
Kann man MySQL irgendwie Multithreaded betreiben? Es kann halt einfach nicht sein, dass eine Abfrage den ganzen Server lahmlegt, das ist doch Steinzeit.
Vielen Dank für jede Bilfe und weiterführende Infos.
Gerd
-
[...]
Kann man MySQL irgendwie Multithreaded betreiben? Es kann halt einfach nicht sein, dass eine Abfrage den ganzen Server lahmlegt, das ist doch Steinzeit.
Eine Abfrage legt den Server lahm?
Kann diese optimiert werden?
Sind Indizes entsprechend gesetzt?
Nick
--
--------------------------------------------------
http://www.xilp.eu
XILP Internet Links People
Dein persoenliches privates Netzwerk
aus Freunden, Verwandten, Bekannten und Kollegen.
---------------------------------------------------
Also soviel vorweg: das ist uns schon klar, dass das System und die SQLs die wir abfeuern suboptimal sind. Das Problem ist, dass der Entwickler pleite gegangen ist und es keinerlei Support mehr gibt und wir mit nem undokumentierten System umgehen müssen.
Also schauen wir, was wir _ausser_ nen neuen Programmierer einzuarbeiten noch tun können und da es hauptsächlich an MySQL hängt suchen wir nach Möglichkeiten, ob dieses optimiert bzw. multithreaded laufen kann.
Die "andere" Baustelle, nämlich das System selbst zu optimieren ist so komplex dass es hier nicht weiter thematisiert werden muss...
Gerd
-
Also soviel vorweg: das ist uns schon klar, dass das System und die SQLs die wir abfeuern suboptimal sind. Das Problem ist, dass der Entwickler pleite gegangen ist und es keinerlei Support mehr gibt und wir mit nem undokumentierten System umgehen müssen.
Also schauen wir, was wir _ausser_ nen neuen Programmierer einzuarbeiten noch tun können und da es hauptsächlich an MySQL hängt suchen wir nach Möglichkeiten, ob dieses optimiert bzw. multithreaded laufen kann.
Die "andere" Baustelle, nämlich das System selbst zu optimieren ist so komplex dass es hier nicht weiter thematisiert werden muss...
Der Haken dabei ist, das die Optimierung der SQL-Statements und des Datenmodells (Indizes etc.) wohl eigentlich der Ansatzpunkt fuer eine moegliche denkbare Performancesteigerung ist.
Und ueber ein mehr oder weniger unbekanntes DB-System, was schon suboptimal laeuft, eine Replikation der DB zu stuelpen... ist vermutlich eher ein fragwuerdiges Unterfangen.
Um wieviele Daten (z.B. Datensatzanzahl in einer wichtigen Tabelle) und wieviel Zeitbedarf eines Statements reden wir hier? Sind denn ueberhaupt Indizes definiert? Oder arbeitet das DBMS alle Anfrage rein sequentiell ab?
Nick
--
--------------------------------------------------
http://www.xilp.eu
XILP Internet Links People
Dein persoenliches privates Netzwerk
aus Freunden, Verwandten, Bekannten und Kollegen.
---------------------------------------------------
Die Datenbank selbst läuft recht effektiv, Indizes sind korrekt gesetzt. Es ist, wie die SQLs generiert werden im System und ein daraus resultierender gewaltiger Overhead. Wichtige ständig benötigte Daten werden aus zu vielen Tabellen geholt und müssen umständlich berechnet werden. Wie gesagt, das ist eh eine Baustelle, aber darüber weiss ich Bescheid, das ist halt nicht meine Frage.
Alles was ich mich frage ist, ob man MySQL anpassen, optimieren oder was weiss ich kann, damit die neue Architektur besser genutzt werden kann.
Dank Euch,
Gerd-
Moin!
Alles was ich mich frage ist, ob man MySQL anpassen, optimieren oder was weiss ich kann, damit die neue Architektur besser genutzt werden kann.
MySQL nutzt auch Mehrprozessormaschinen oder mehrere Kerne meines Wissen ganz gut aus.
Aber vielleicht findest Du hier etwas über die Konfiguration von MySQL:
http://www.dell.com/downloads/global/solutions/mysql_network_2800.pdfMFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Seminare, Training, Development
-
-
-
Die "andere" Baustelle, nämlich das System selbst zu optimieren ist so komplex dass es hier nicht weiter thematisiert werden muss...
OK, dann müssten einzelne CPU-lastige SQL-Abfragen identifiziert und dann optimiert werden. Dürfte aber nur möglich sein, wenn das gesamte Datendesign verstanden wird und bearbeitet werden kann OHNE Seiteneffekte befürchten zu müssen. Das muss nicht der Fall sein, eigentlích wird ein Gesamtüberblick benötigt, also lettlich ein globales Systemverständnis.
Warum ich das wunschungemäss thematisiere? - Nun dem Scheitern in die Augen zu sehen ist oft besser als das Scheitern zu ignorieren und damit nur zu verschieben. Ist lieb gemeint. ;)
-
Danke für Deinen Rat.
Was mich so ein bisschen wundert, ist, warum keiner bisher auf die eigentliche Frage einfach nur geantwortet hat:
Gibt es bei MySQL Möglichkeiten dieses für mehrere Prozessoren anzupassen? Da reicht mir schon ein einfaches ja oder nein, wenn es jemand weiss.
Ich möchte garnicht bei null anfangen und jedem erklären warum wir in dieser Situation stecken und dass das System erneuert werden muss ist mir von Anfang an klar gewesen.
Vielen Dank,
Gerd-
Hallo!
Wussten Sie schon, dass MySql Open Source ist?
Gruß
Olli -
Was mich so ein bisschen wundert, ist, warum keiner bisher auf die eigentliche Frage einfach nur geantwortet hat:
Das Beratungsniveau lässt hier manchmal zu Wünschen übrig. Übrigens betrifft das nicht immer nur die Ratgeber, sondern gelegentlich auch mal den Ratsucher.
Dennoch hier die Antwort:
Du gedenkst zwei Datenserver-Instanzen zu fahren um die zwei CPUs zu nutzen, korrekt. Du könntest mal in der MySQL-Dokumentation nachschauen, "www.mysql.com" oder so, ich kenne den MySQL-Server nicht persönlich (nur vom Lesen), es ist aber sehr gut möglich, dass genau das nicht möglich ist.Also, ich versuche jetzt mal Dir beim Lesen der Dokumentation zu helfen:
http://www.mysql.com/
http://dev.mysql.com/doc/
http://dev.mysql.com/doc/refman/5.1/de/index.htmlTja, jetzt würde ich die Fachbrgiffe: CPU und (mehrere) Instanzen erwarten, so gings also erst mal nicht, mal hier schauen:
So, muss jetzt leider weg, die Jungs helfen Dir hier sicher.
-
Moin!
Was mich so ein bisschen wundert, ist, warum keiner bisher auf die eigentliche Frage einfach nur geantwortet hat:
Gibt es bei MySQL Möglichkeiten dieses für mehrere Prozessoren anzupassen? Da reicht mir schon ein einfaches ja oder nein, wenn es jemand weiss.
Die Antwort ist "Nein". MySQL ist schon so multithreaded und multitasked, wie es geht.
Die Lösung zu deinem Problem liegt wirklich in der anscheinend mieserablen Nutzung der Datenbank, nicht im Datenbankprogramm selbst.
Außerdem teilt hier anscheinend nicht jeder deine Problemanalyse. Wenn du den Server extrem aufgebohrt hast im Vergleich zur alten Kiste, mit Multiprozessor- und Multikernsystem, und trotzdem ist die Applikation so lahm, wie vorher, dann hat das Gründe.
Nur mal als Szenario: Angenommen, nur eine einzige, aber extrem suboptimale Abfrage, die riesige Mengen an RAM und, weil RAM nicht reicht, auch noch Swap-Space verbraucht, muß bewältigt werden. Weil Festplatten damals wie heute extrem lahm sind (ob die nun 60 Sekunden brauchen im alten System oder 40 Sekunden im neuen, merkt man nicht), zeigt der Serverwechsel keinerlei merkbare Geschwindigkeitssteigerung. Du kannst diese Abfrage aber auch nicht auf mehrere CPUs aufteilen, denn das Problem ist nicht die Rechenpower, sondern die Wartezeit auf die Festplatte.
Schau dir die CPU-Auslastung am besten mal genauer an. Vermutlich hat ein Kern einer CPU ganz viel zu tun, der Rest langweilt sich.
Eine Performanceverbesserung ist nur hinzukriegen, indem das Performanceproblem analysiert und der Grund für die Probleme erkannt wird. Erst dann kann man geeignete Gegenmaßnahmen ergreifen. Und sowas ist halt nicht mit einem einfachen "ja oder nein" als Antwort auf eine Frage getan, die eine Problemanalyse vorwegnimmt, der man nicht wirklich trauen sollte, wenn man optimale Beratung möchte.
Ebenso behauptest du beispielsweise, alle Indices wären perfekt gesetzt. Hast du das persönlich geprüft? Hast du alle SQL-Statements, die die Datenbank bearbeiten muß, manuell mit EXPLAIN analysiert?
Ich möchte garnicht bei null anfangen und jedem erklären warum wir in dieser Situation stecken und dass das System erneuert werden muss ist mir von Anfang an klar gewesen.
Gut, da hast du dann deine Antwort, wie du die Datenbank schnell kriegst: System neu machen.
Alternativ eben am bestehenden System optimieren - aber eben nicht am Backend "MySQL", sondern an den Queries und den Indices.
Und erst wenn auch dort wirklich alles ausgereizt ist, müssen andere Methoden ran, beispielsweise die Aufsplittung der Datenbank in separate Bereiche. Ungefähr so, wie bei MySpace... http://www.baselinemag.com/print_article2/0,1217,a=198614,00.asp
- Sven Rautenberg
--
"Love your nation - respect the others."
-
-
-
-
-
Hi,
- wir müssen den Code weiter optimieren, um weniger MySQL Abragen zu erzeugen und so die Last zu mindern.
ja. Und davor müsst ihr das DB-Layout optimieren - also Tabellenstrukturen, Indexe und auch die SQL-Statements, die ihr ausführt.
Kann man MySQL irgendwie Multithreaded betreiben? Es kann halt einfach nicht sein, dass eine Abfrage den ganzen Server lahmlegt, das ist doch Steinzeit.
Bis zum Beweis des Gegenteils sehe ich hier die Schuld nicht in der Datenbank, sondern in ihrer Nutzung. MySQL kann ohne Weiteres auch mit großen Datenmengen und komplexen Strukturen schnell arbeiten, selbst wenn die Hardware nicht auf dem neuesten Stand ist. Kümmere Dich also nicht um die Dinge, mit denen Du gerade mal ein paar Prozent besser werden kannst, sondern um die, mit denen ein paar Prozent der Laufzeit _übrig bleiben_.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes -
Nun stellen wir ernüchtert fest, dass letztendlich alles weiterhin an MySQL hängt und dieses voll ausgelastet ist. Es scheint, als würde sich die Maschine größtenteils langweilen und nur auf MySQL warten.
Ein bekanntes Problem, Datenserver werden falsch programmiert, nestimmte Entwickler kriegen Geräte mit beliebiger Leistung in die Knie.
Frage nun: was tun?
Datenzugriff optimieren, "Messen und Verstehen" so zu sagen.
Zwei Trivialitäten sein mal vorweg als bekannt gegeben:
- wir müssen den Code weiter optimieren, um weniger MySQL Abragen zu erzeugen und so die Last zu mindern.
Trara! - Wobei ich weniger die Anzahl der Abfragen überprüfen wollen würde, sondern deren Auführgeschwindigkeit.
- wir könnten zwei Maschinen mit separaten Datenbanken fahren und diese syncen, was uns aber erstmal zu aufwändig erscheint.
Ihr könntet Eure Probleme auf ganze Serverfarmen ausweiten, "syncen" ist replizieren? ;)
Kann man MySQL irgendwie Multithreaded betreiben? Es kann halt einfach nicht sein, dass eine Abfrage den ganzen Server lahmlegt, das ist doch Steinzeit.
Steinzeit-SW-Entwicklung, ein richtig schlechter (oder zynisch und hinreichend guter) DB-Entwickler kann jede DB und den Zugriff dermassen "aufbohren", dass sehr schnell Schluss ist.