PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : MySQL überfordert - Optimierung möglich?



partyface.de
26.01.07, 00:42
Hallo zusammen,

endlich haben wir es geschafft und unsere Seite auf einen neuen Server umgezogen. Alles läuft planlos, nur jetzt wollen wir die MySQL DB so optimieren, dass wir eine bessere Performance hinbekommen.

Wenn ich mir über das phpmyadmin die SQL Laufzeit-Informationen anschaue, fallen besonders die Werte Handler_read_rnd und Handler_read_rnd_next auf:

Handler_read_rnd: 835 M
Handler_read_rnd_next: 4,28 G

Hier noch ein paar Infos zur Auslastung:
Insgesamt ø pro Stunde ø pro Minute ø pro Sekunde
121 M 1,29 M 21,44 k 357,38

Was sind die Ursachen für die hohen Werte bei Handler_read_rnd und Handler_read_rnd_next? Wie kann man das beheben?

Würde mich über einige Tips freuen. Sollten noch weitere Infos notwendig sein, bitte fragen.

vg
Thomas

stefan.becker
26.01.07, 00:46
Datenbanktuning per Ferndiagnose ist bald ein Ding der Unmöglichkeit.

Was ist das für eine Datenbank? Volumen? Wie sind die Indizes? Dauern Abfragen länger als vorher?

partyface.de
26.01.07, 00:50
Was ist das für eine Datenbank? Volumen? Wie sind die Indizes? Dauern Abfragen länger als vorher?

Ist eine MySQL 5.0.18 DB mit insgesamt 20 Tabellen, insg. 4 Mio. Zeilen, 607 MB Daten, 190 MB Indizes...
Indizes sind gesetzt, hoffentlich auch richtig, da fehlt uns ein wenig die Erfahrung.
Die Abfragen dauern bei hohen Zugriffen schon länger.

stefan.becker
26.01.07, 00:55
Tja, und da hörts auf.

Also dazu kann ich nichts per Ferndiagnose sagen.

Da müsst ihr wohl mal Profis ran lassen vor Ort, so aus der Ferne geht das nicht.

Indizes sind also gesetzt.

Ein großes Hin und Herschaufeln von Daten resultiert in der Regel aus "schlechten" Indizes.

Lasst das von Fachleuten untersuchen, alles andere ist vermutlich Kaffesatzleserei.

partyface.de
26.01.07, 01:02
ok... trotzdem danke. Evtl. müssen wir wohl doch auf einen eigenständigen DB-Server umsteigen. Vielleicht ist auch einfach die Last zu hoch und geht nicht mehr auf einem Server.

Jinto
26.01.07, 01:37
hmm, schon die Diskussion vom 3.Januar vergessen?

Weshalb sollte sich die Datenbank auf einem anderen Server anders verhalten? (Aber die Sache hatten wir doch auch schonmal..)

Liefern doch nochmal die Ausgaben von Status und Variablen, wie beim letzten mal.

marce
26.01.07, 07:25
Vor allem können "Profis" auch eines erkennen - und evtl. beheben: schlechtes Datenbank-Design.

stefan.becker
26.01.07, 16:46
Vor allem können "Profis" auch eines erkennen - und evtl. beheben: schlechtes Datenbank-Design.

Genau darum geht es. Ich vermute das als Ursache. Und dazu kann man ohne genaue Kenntnisse der Datenstrukturen und Zugriffspfade absolut nichts sagen.

Am Morgen ein Join und der Tag ist dein Freun (d) :)

partyface.de
26.01.07, 18:06
Liefern doch nochmal die Ausgaben von Status und Variablen, wie beim letzten mal.

www2.partyface.de/sql_tips/status.htm
www2.partyface.de/sql_tips/variablen.htm

partyface.de
26.01.07, 18:07
Vor allem können "Profis" auch eines erkennen - und evtl. beheben: schlechtes Datenbank-Design.

ok, akzeptiert, nur ist das alles nicht so einfach...

marce
26.01.07, 22:46
... aber sowas findet sich problemlos - und sei es über die "Gelben Seiten"...


edit: hab' gerade mal die beiden Links grob überflogen - was dort noch angemeckert wird riecht sehr stark nach DB-Design-Fehlern und ineffizienter Programmierung. Wenn's denn wichtig ist :-) holt euch jemanden - und beschäftigt euch selbst sehr ausgiebig mit der Theorie von DB-Design und Optimierung. Klar kann und wird das ein bisserl was kosten - und wenn es nur eure Zeit und Nerven sind.