mysql 5.5. hohe Last

[kutt]

Hallo, seit einiger Zeit liegt die Last meines SQL Servers immer bei 70..80%.

Die genaue Version ist: 5.5.46-0+deb7u1

Im Top schaut das Ganze so aus:


In der Performance merkt man das Ganze nicht so sehr - immerhin ist es ein Core i7 mit 16GB Ram.

Ich habe schon alles mögliche versucht, um den Grund für die 70..80% Last des SQL Servers herauszufinden. Das nächste wäre mir mal einen logger einzurichten, um zu sehen, ob die mysql Last wirklich von den Queries abhängt (Tag-Nacht Zyklus). Ich habe eher das Gefühl, als würde den mysql irgendwas slammen ...

bei

Code: Alles auswählen

 mysqladmin -uroot -p processlist

kommt auch nichts wirklich verwertbares. Ist alles auf "Sleep" und bei der Replikation steht:

Master has sent all binlog to slave; waiting for binlog to be updated

m.M. nach schaut das alles i.O. aus...

[rendegast]

mytop

mysqltuner
oder
https://github.com/major/MySQLTuner-perl 1.6.1
http://mysqltuner.com/
?

Von irgendeiner Testreihe noch debug/profiling-Einstellungen aktiviert?




Sind die 50MB für bind/named normal?
EDIT Sehe hier gerade, frisch installiert ohne Einstellungen oder Tätigkeit nimmt der sich schon 18MB.

[kutt]

mytop

mysqltuner
oder
https://github.com/major/MySQLTuner-perl 1.6.1
http://mysqltuner.com/
?

Von irgendeiner Testreihe noch debug/profiling-Einstellungen aktiviert?
.

(ohne Reihenfolge)

- profiling steht auf 0

OK - der SQL Server läuft jetzt nicht so lange, aber das sagt der mysqltuner

38892

Ein anderes tuning script sagt:

38893

und zum Schluß mytop:

38894

ja - ich hab ein paar Joins ohne Indexe, aber der mySQL hängt immer 70 und 90%
Wenn ich den Apache2 stoppe (der die Hauptlast macht), sinkt die CPU Last vom mysql-Prozess auf stetig 70% ab.

irgendwas ist da faul...

[rendegast]

In top mal die Thread+Baumanzeige einschalten? (H)(V)
Mal ein strace an den mysql-Prozeß hängen,
womit er wohl beschäftigt ist?

Vielleicht Plattenfehler? <-> dmesg/smart

[kutt]

Mal ein strace an den mysql-Prozeß hängen,
womit er wohl beschäftigt ist?

Vielleicht Plattenfehler? <-> dmesg/smart

hmmm - das Raid schaut gut aus:

38895

Auf der Platte ist noch genug Platz .. in den Logs steht nix brauchbares

aber strace ist interessant .. da gehts ab ... 9MB strace in 10 sek... bei abgeschalteten apache2 - WTF

Hmm - für NoPaste etwas viel. Ich lads mal hoch. Bitteschön:

Strace Log (TXT Datei - Achtung: 9.783.859 Bytes)

Das einzige, was ich zu "FUTEX_WAKE_PRIVATE" etc finden kann ist: Reboot des Servers kann helfen...
https://www.redmine.org/boards/2/topics/31731?r=31733

[rendegast]

Du könntest mal den Kernel 3.16 wheezy-backports versuchen,
oder andersherum wieder auf 3.2 wheezy wechseln.


Nebenbei,
Deine 9MB.txt schrumpft mit gzip auf 300-600kb, so dann wohl auch per http-Compress.

[kutt]

ja - ich hab in dem Zuge gleich den 3.2.0 aktiviert.

Jetzt schauts aber besser aus:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4618 mysql 20 0 849m 202m 8068 S 1.3 1.3 0:58.44 mysqld

Serverneustart hat also was gebracht - mal beobachten ob's hält

[Gunah]

Datenbank optimierungen an sich ist nicht ganz so einfach.

MySQLTuner ist aufjedenfall nen Nettes Tool.
Welches auch bei Falscher Konfiguration warnt.

Es gibt viele Tricks. was aber auch damit zusammenhängt, wieiviel RAM die Kiste hat.

Hier mal generelle Tricks die man anwenden kann:
- Wenn genügend RAM vorhanden ist, das tmp Verzeichnis von MySQL auf ein TMPFS zeigen lassen. ( https://wiki.archlinux.de/title/Ramdisk )
- in FSTAB die Partitionen mit der Option "noatime" angeben. ( https://wiki.archlinux.de/title/Noatime )

diese beiden kleinen Anpassungen bringen schon relativ viel bei der Performance, da die HDD/SSD nicht mehr so viel schreiben muss.