MySQL mit 200% CPU

A

AS-N

New Member
Hallo,

ich habe hier eine SuSE10.3 mit MySQL5, die mir zur zeit folgendes meldet:

Code: 
top - 11:28:41 up 15:54,  1 user,  load average: 21.10, 16.50, 10.22
Tasks: 110 total,   3 running, 107 sleeping,   0 stopped,   0 zombie
Cpu(s): 99.1%us,  0.9%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2075192k total,  1616440k used,   458752k free,   144580k buffers
Swap:  1052248k total,      476k used,  1051772k free,   854456k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3046 mysql     22   0  924m 110m 5120 R  200  5.5  26:50.19 mysqld
    1 root      15   0   740  288  240 S    0  0.0   0:01.41 init
    2 root      11  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:00.02 migration/0
    4 root      34  19     0    0    0 S    0  0.0   0:00.29 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:00.02 migration/1
    6 root      34  19     0    0    0 S    0  0.0   0:00.19 ksoftirqd/1

Eigentlich passiert auf dem server garnicht so viel, zumindest jetzt gerade, aber wo kommt denn die Auslastung her?

--
Ciao
AS-N
 
200% ist ja Lustig. ;)
Ich tippe mal auf ein amoklaufendes Query. Einfach über den Konsolen MySQL-Client das Query beenden und gut.
 
Ds ist es leider nicht, ich habe schon alle queries beendet, den mysql neu gestartet und auch den server neu gebootet, aber so bal der mysql 30 sek. läuft ist die Auslastung wieder weit über 100%.
 
Auf der Platte sind noch gut 40GB frei,
der Speicher ist es auch nicht:

1.98 GB total, 285.17 MB used.

Rechte? wer muss denn hier für was welche Rechte haben?
 
Ich frag mich grad wo das "Coping to tmp Table" bei dir herkommt.
Mit welchen Parametern hast du mysqlcheck denn aufgerufen?

Der Holzhammer wäre wohl sowas
Code: 
mysqlcheck --all-databases --analyze --all-in-1 --check --use-frm --auto-repair --extended --optimize
 
Habe ich jetzt acuh mal drüber laufen lassen, aber kein Unterschied, die queries die beim Copying hängen bleiben summieren sich bis der ganze Kasten nicht mehr reagiert.
 
Na wo steht das denn und vorallem bei welcher Aktion?
In der Ausgabe von mysqlcheck kann ich diese Ausgabe zumindest nicht erkennen. :confused:

Edit: Ah nun weiß ich was du meinst. Steht aber immer noch die Frage durch welche Aktion das ausgelöst wird.
Ansonsten vielleicht mal den Speicher geprüft? Vielleicht defekt. :)
 
Last edited by a moderator:
Naja, ist schon eine gewaltige Abfrage und es sind auch ne Menge Daten auszugeben, aber bisher lief das alles ohne Probleme.

Was mich auch wundert, dass der query_cache sich eigentlich nach der ersten Abfrage sich diese geschnappt hat und dann immer recht flott wieder ausgegeben hat.
Jetzt scheint er die query nach einiger zeit zu vergessen, obwohl der cache noch lange nicht voll ist.
 
Das script meckert dass mysql 90% Memory benutzt, aha!
Wo kann ich das den beschränken?

slow_queries hatte ich schon vor langer Zeit abgearbeitet, da kann man nichts mehr optimieren.
 
Hallo,

so alles auf einem neuen quadcore server mit 4 GB RAM, gleicher Effekt.
Ich sehe jetzt hier manche queries die werden zweimal hinereinander ausgeführt werden, obwohl das keiner verlangt, dann ist eine dabei die satte 29 sek. braucht, das ist aber eine Standard osCommerce Funktion.
Ich bin langsam ratlos, da ich nicht mehr weiß woran das liegen könnte.
Wenn sich hier ein Experte für MySQL finden würde, der mir auch direkt zu helfen kann,
ich würde gerne kommerzielle Hilfe annehmen.
Oder vielleicht kennt ja jemand jemanden, der sowas anbietet.

--
Danke
AS-N
 
Last edited by a moderator:
Jetzt ist doch noch eine query ausgekrochen, die unter php4 rannte, jetzt aber plötzlich gar nicht mehr wollte, und unter Last hat die dann das ganze System lahm gelegt.
 
You must log in or register to reply here.
Back
Top