knebb wrote:MySQL 4.1 hat Lockingprobleme, wenn es auf mehreren CPUs läuft. Eine Grenze ist nicht angegeben/ bekannt. Gibt es eine solche Grenze? Ist diese etwa 8 CPUs?
Du kannst auch einmal mit innodb_thread_concurrency experimentieren (in der Annahme, daß Du innodb einsetzt). In vielen Fällen funktioniert es besser, wenn man innodb_thread_concurrency auf 4 setzt, als wenn man es auf größere Werte setzt.
Es ist grundsätzlich BESSER, in die Breite zu skalieren. Daraus schließe ich, daß ein Zuwachs von 100% CPUs lange nicht 100% MySQL-Power erwarten läßt.
Das ist nicht nur bei MySQL, sondern bei jedem System so. In der Regel wächst Deine Systemleistung bei einer Verdoppelung der CPUs nur um einen kleineren Anteil. Als Faustregel gilt: man erreicht die ökonomische Grenze der vertikalen Skalierung, wenn die Leistung bei 100% mehr CPUs nur um 66% wächst.
Das war mir auch klar. Es erklärt aber nicht, warum das System LANGSAMER wird!
Du kannst jedes System mit Lock Waits zum Totalstillstand unter Last bringen.
Genauer: Jedes asynchrone System kann durch Einfügen von Waits zu einem synchronem System umgebaut werden, daher ist jedes synchrone System immer langsamer als das äquivalente asynchrone System. Vertikale Skalierung baut in der Regel synchrone Systeme, horizontale Skalierung baut in der Regel (Ausnahme: MySQL Cluster) baut in der Regel asynchrone Systeme.
Interesting Read:
http://radar.oreilly.com/archives/2006/ ... _1_se.html und folgende Artikel.
In dem Artikel da oben such mal nach "All hail", dann bekommst Du die betreffenden Quotes zum Thema, die ich voll unterschreibe
Web 2.0 applications will require more horsepower with less money than One Database or his big brother One Cluster ('All Hail The Central Cluster') will offer. (After all, a 64-way Mysql Cluster installation is just the budget-friendly version of a Sun E-10000.)
Deine Anwendung ist vielleicht kleiner als 2nd Life, aber das Problem existiert offensichtlich auch schon auf Deiner Ebene. 16way-Maschinen sind aber keine Lösung, so verlockend sie scheinen mögen.
Horizontales Wachstum ist teurer und aufwendiger als vertikales Wachstum ("einfach eine größere Kiste kaufen und neu deployen"), weil es mehr Hirnschmalz und eine Architektur mit "Hacks" erfordert.
Z.B. war bei web.de die Umstellung der Mailer auf asynchrone Anfragen an die Middleware sehr ekelig: Zwar ist irgendwann die Zustellzeit für eine Mail im Mittel auf 1/12tel gefallen (von 250ms auf unter 20ms), aber das hat an gewissen Stellen sechs mal mehr Code erfordert, und asynchrone Corba-Calls sind kein Zuckerschlecken (
http://kris.koehntopp.de/artikel/linuxtag/ hat leider die konkreten Beispiele aus dem gesprochenen Text nicht in den Slides).
Der Punkt ist aber, daß das die _einzige_ Methode war, das schneller und größer zu bekommen, und zwar indem man Abhängigkeiten relaxed hat und Waits eliminiert hat.