Limits

Hallo,
wir betreiben hier für ein Projekt umfangreiches Data Mining bei dem extrem
viele Daten anfallen und aufgewertet werden müssen. Hier wird gerade ein
neuer Server in Betrieb genommen (2x Core Duo XEON), 8x 15.000 SAS SCSI als
RAID 10, 4 GB Ram. Damit haben wir erstmal "Luft" haben, da unser alter
Server 2x XEON, 4x 15.000 SCSI RAID 10, 3 GB Ram bei mehreren
gleichenzeitigen Analysen "langsamer" wird. Das Ram ist scheinbar nicht so
das Problem, da kein Swapping u.ä. auftritt und die wichtigen Indexe in den
Cache passen. Ich selber bin nicht direkt involviert, soll aber
recherchieren was wir tun können wenn auch der neue Server zu langsam wird.
Die Kiste kann auf bis zu 48 oder 64 GB aufgerüstet werden, was dann aber
sehr teuer wird.
Wie kann man sonst noch an das Thema rangehen. Auf das SQL selber habe ich
keinen Einfluss habe mir aber von den Programmierern versichern lassen, dass
da kein (?) Optimierungspotential mehr drin ist, da dort bereits seit sehr
langer Zeit optimiert wurde. Nun kam die Frage auf was man eben noch tun
kann. Hardware ist eine Sache, aber ein Quad Xeon würde höchstwahrscheinlich
gar nichts bringen da z.B. nur max. 2-3 Queries gleichzeitig laufen, die
aber richtig ackern müssen. Ist ein anderes DBMS denkbar wobei die
Programmierer schon abgewunken haben, da viele Teile extrem auf Mysql (z.Z.
4.1.x) optimiert wurden und man bei einem anderen System wieder bei Null mit
der Optimierung beginnen müsste.

Christian

Re: Limits

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Limits

Hi Christian

Christian Schmelzer wrote:
[Ich hab mega-HW, optimale Queries. Was kann ich noch optimieren? Bzw.
wo muss ich beginnen?]

RTM: Chapter 7. Optimization
http://dev.mysql.com/doc/refman/5.1/en/optimization.html

Sorry, ab den Infos aus deiner E-Mail lässt sich IMHO bis hierhin noch
gar nichts aussagen. Keine Ahnung, was ihr da genau macht. Aber die
obige Informationsquelle ist sicher ein schlauer Ansatz.

HTH, Johannes

Re: Limits

Hallo Christian,

> 8x 15.000 SAS SCSI als RAID 10, 4 GB Ram. Damit haben wir erstmal
> "Luft" haben, da unser alter Server 2x XEON, 4x 15.000 SCSI RAID 10, 3
> GB Ram bei mehreren gleichenzeitigen Analysen "langsamer" wird. Das
> Ram ist scheinbar nicht so das Problem, da kein Swapping u.ä. auftritt
> und die wichtigen Indexe in den Cache passen.

Entweder passt alles wichtige in den Cache, dann ist die scsi/raid-Orgie
überflüssig oder das raid hat was zu tun dann kann mehr RAM helfen. So
üppig sind 4GB ja auch nicht.

An der swap-Belegung ist das jedenfalls bei Linux nicht erkennbar.

> Ich selber bin nicht direkt
> involviert, soll aber recherchieren was wir tun können wenn auch der
> neue Server zu langsam wird. Die Kiste kann auf bis zu 48 oder 64 GB
> aufgerüstet werden, was dann aber sehr teuer wird.

Wenn der DB-Prozess die CPU voll auslastet und es immer noch zu lahm
ist, hilft nur eine dickere Kiste. Vorausgesetzt bei der DB gibt es ganz
sicher nichts mehr zu optimieren.


Siegfried
--
http://www.schmidt.ath.cx

Re: Limits

Christian Schmelzer wrote:
> Wie kann man sonst noch an das Thema rangehen.

Eigentlich doch mit den ueblichen Bordmitteln: Zunaechst einmal
rausfinden, wo eigentlich das Nadeloehr ist. Es kann eine einzelne
Platte sein, die gesaettigt ist, es kann die CPU sein, die von der
Applikation her ausgelasteti st, es kann ein doofer Treiber sein, der
Systemseitig die CPU auslastet etc. etc. Was man da nehmen kann, haengt
vom Betriebssystem ab.

Re: Limits

"Christian Schmelzer" wrote:

> wir betreiben hier für ein Projekt umfangreiches Data Mining bei dem extrem
> viele Daten anfallen und aufgewertet werden müssen. Hier wird gerade ein
> neuer Server in Betrieb genommen (2x Core Duo XEON), 8x 15.000 SAS SCSI als
> RAID 10, 4 GB Ram. Damit haben wir erstmal "Luft" haben, da unser alter
> Server 2x XEON, 4x 15.000 SCSI RAID 10, 3 GB Ram bei mehreren
> gleichenzeitigen Analysen "langsamer" wird. Das Ram ist scheinbar nicht so
> das Problem, da kein Swapping u.ä. auftritt und die wichtigen Indexe in den
> Cache passen.

"Alle Indexe passen in 3GB" und "umfangreiches Data Mining" passen
irgendwie nicht so recht zusammen. Datamining impliziert im Gegensatz
zu OLTP ja Datenmengen >> RAM, so daß I/O als typisches Bottleneck
anzusehen ist. Wenn aufwendige Berechnungen dazu kommen, kann durchaus
auch die CPU-Leistung fehlen. Da MySQL pro Query nur eine CPU nutzt,
kann das durchaus zum Hauptproblem werden.

> Ich selber bin nicht direkt involviert, soll aber
> recherchieren was wir tun können wenn auch der neue Server zu langsam wird.

Das was man immer tut:

1. unter realer Last messen
2. die Meßergebnisse interpretieren
3. an der richtigen Schraube drehen

Keiner dieser Schritte ist optional und auch von der Reihenfolge sollte
man besser nicht abweichen.

Die Messung betrifft alle Systemkomponenten, die Einfluß auf die
Gesamtperformance haben (können). Minimum sind CPU-Auslastung,
Verwendung von RAM/Swap. Festplatten-Aktivität. Evtl. das Netzwerk.
Nebenher sollte man auch den MySQL-Server selber monitoren.
SHOW STATUS liefert eine Menge Informationen.

> Auf das SQL selber habe ich
> keinen Einfluss habe mir aber von den Programmierern versichern lassen, dass
> da kein (?) Optimierungspotential mehr drin ist, da dort bereits seit sehr
> langer Zeit optimiert wurde.

Diese Aussage ist selbstverständlich falsch. Die einzige akzeptable
Formulierung wäre: es gibt keine Optimierung, von der wir wissen.

Again: man kann (und muß) das messen. Das slow-log und EXPLAIN sind
genau und extra dafür da.


XL

Re: Limits

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)