mysql trödelt ohne ende

[sys_op]

hallo

ich habe unter xampp auf einem windows-laptop ein php-script am laufen, dass mir ca 20.000 artikel-datensätze verwaltet. dabei werden natürlich einige abfragen gemacht, die unter xampp auch problemlos laufen. (laptop mit 1GB ram und 2 GIG cpu
nun habe ich das ganze auf meinem debian rechner installiert (apache, mysql php) und muss feststellen, dass ich abfragezeiten von bis zu 50 sek habe, wo mein xampp gerade mal 1 sekunde braucht. pc (2x 2,2 GIG cpu 2GIG ram) mysql läuft in der standard konfiguration ohne änderungen.

jetzt stehe ich etwas daneben und bin ratlos, woran das liegen könnte. ich weiss nicht mal, wo ich ansetzen soll. über phpmyadmin komme ich problemlos auf die datenbank, es ist alles so wie es sein sollte, einzig die abfragezeiten sind mir schleierhaft.

die logs zeigen mir garnichts merkwürdiges.

hat jemand eine idee ?

[neuss]

hat jemand eine idee ?

Jede Menge, aber ins blaue zu raten habe ich keine Lust
Stell deine Frage bitte genauer.

gruss neuss

[sys_op]

naja, die genauere frage wäre dann ca so:
woran kann es liegen, dass auf einem rechner, der doppelten power hat abfragen ca 60 mal so lange dauern wie auf dem laptop..

da ich weder weiss, wo ich ansetzen soll, noch was ich hier auszugsweise an config-dateien posten könnte tu ich mir etwas schwer mehr infos zu geben.
die grundkonfiguration des apache und des mysql-servers entspricht den standardvorgaben der installation, will sagen, ich habe null angepasst oder verändert. da es sich um eine testumgebung handelt, muss ich auch keine sicherheitseinstellungen o.ä. machen. da die abfragen abgearbeitet werden, stelle ich mal sachlich fest, apache und sql laufen, allerdings mysql nicht mit der geschwindigkeit, die ich gewohnt bin

[pluvo]

Welche Debian-Pakete, welches Debian, etc...

[sys_op]

uupps, wo du recht hast, hast du natürlich recht...

ist ein etch mit den originalen paketen mysql server 5

[ckoepp]

Sowas kann auch an deinen SQL-Abfragen liegen. Gerade bei schlechten JOINS kann es eng werden...

Schau dir mal das mysql-Slow-Querry-Log an. Steht da was drin?

[sys_op]

hallo

nein, das log gibt es nicht. die queries sind zwar relativ heftig, da daten kreuz und quer zusammengesucht werden, aber sie laufen wie gesagt rund auf dem xampp (max 1 sekunde wartezeit bis zum seitenaufbau). auf dem debian brauchen die selben abfragen mit den selben daten ca 60 bis 100 sek.

aufgefallen ist mir, dass der mysqld fast 50% der cpu frisst und sich nicht wirklich weiter bewegt.

ps.
habe mal zum testen ein sql-forum installiert, das braucht auch ewig bis sich was bewegt.

[schorsch_76]

Huhu,

ich hab auf ein paar Perl Scripte welche eine MySQL5 DB verwenden. Ich habe anfangs keinerlei Indexe gehabt und die Abfragen waren grauenhaft langsam. Ich habe dann in die Mysql Konsole ein paar der potentiel lansamen Abfragen per EXPLAIN aufdröseln lassen und dann entsprechnde Indexe erzeugt was die Abfrage um Faktor 100 beschleunigt hat.

Gruß

schorsch

[ckoepp]

nein, das log gibt es nicht.

...dann solltest du es aktivieren. mySQL kann dir am besten sagen was los ist.

[sys_op]

hallo

erst mal danke für die rege anteilnahme.
log ist eingeschalten, es kommt allerdings nur der select befehl, den ich ja ohnedies schon kenne. dass hier die datenbank gefordert wird, ist mir bewusst, leider muss ich aber mit den informationen (tabellen) leben, die der kunde zur verfügung stellen kann.

dass man mein select vielleicht besser machen könnte will ich garnicht bestreiten, allerdings finde ich es nach wie vor verwunderlich, dass der selbe select befehl auf einem xampp (winxp-home) weniger als 1 sek. braucht und auf dem debian-server fast 100 sek.
ich habe ja auch kein problem mit einem select befehl an sich, der funktioniert auf gut 60 rechnern (laptops) die alle mit einem xampp ausgestattet sind. keiner der laptops hat ein problem mit der ausgabe (zumindest habe ich seit 1 jahr nichts gegenteiliges gehört), alle arbeiten den select befehl innerhalb knapp 1 sekunde ab.

bis ich zu debian gewechselt bin, habe ich mit suse gearbeitet (bis 9.2) und habe die scripte dort auch entwickelt. auch da liefen die selects fehlerfrei, wenn sie auch etwas länger gebraucht haben als unter windows (sollen es maximal 1.5 - 2 sekunden gewesen sein). es war aber alles im erträglichen bereich.
nun muss ich das script etwas verändern, der kunde wünscht eine weitere spalte. die installation verläuft (wie ja auch schon auf den 60 Laptops) ohne jedes problem, ratzfatz sind die daten in der datenbank. nur die abfrage, mit der alle daten zusammengesucht werden will nicht mehr. wie gesagt, die selbe abfrage, die es auf einem (60) xampp(s) problemlos tut.

nun könnte ich zwar das ganze unter windows erledigen, aber das kann ja der sinn meines neuen debian pc's nicht sein.
das install script legt die datenbank an, erzegt die tabellen und legt die daten an. in der datenbank wird also quasi nichts von hand gemacht. die eigentliche funktion liegt nun darin, aus den einzelnen tabellen eine anzeige zu generieren, die nach vertretergebieten gefiltert ausgegeben wird, also eigentlich nichts wildes.

ps.
das einzieg, was ich als sicher verändert annhemen kann, ist die mysql version. da es wohl auf dem debian eine neuere version als unter suse 9.2 geben wird.

[Sarem_Avuton]

Hallo,

kannst ja mal "tuning-primer" script probieren ob das was Ausspuckt. Zu finden z.B. http://day32.com/MySQL/

Grüße Jörg

[ckoepp]

das einzieg, was ich als sicher verändert annhemen kann, ist die mysql version. da es wohl auf dem debian eine neuere version als unter suse 9.2 geben wird.

Das ist auch das Einzige das Einfluss darauf haben kann

Evtl. solltest du die Puffergröße in mySQL erhöhnen und die Prozesse beobachten. Vielleicht ist ein X-Lock aktiv und dann ist's kein Wunder wenn deine Anfrage etwas braucht.
Schau dir die Infos in mySQL genau an und vergleiche die internen Infos (such mal in der mySQL Doku - die kann man irgendwie abrufen) auf dem Server mit deinen des Laptops.

[sys_op]

hallo

ich muss das nochmal aus der versenkung kramen.
mir ist aufgefallen, dass, wenn ich den select prozess durchlaufen lasse, offensichtlich irgend ein cache angelegt wird. die abfrage geht beim zweiten mal (wenn ich also nocheinmal auf die selbe abfrage klicke) in einem affen tempo von statten. kann es eventuell an der anlage dieses caches liegen ?

so, ich konnte den fehler nun eingränzen, es liegt am group befehl. ohne group by läuft die kiste rund.