Onderwerp: Slechte MySQL Performance

Ik heb hier een MySQLd process dat maar blijft draaien, normaal werkte MySQL met allemaal losse processen. Is dit hieronder normaal voor een top-result?

Code:

93 processes: 91 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:  59.0% user   0.7% system   0.0% nice   0.0% iowait  40.2% idle
Mem:   998556k av,  978384k used,   20172k free,       0k shrd,  125516k buff
                    729912k actv,       0k in_d,   20060k in_c
Swap: 1020024k av,   22940k used,  997084k free                  606544k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
14501 mysql     15   0 27584  22M  2348 S    57.6  2.2  35:29 mysqld-max

Code:

[root@server02 root]# ps -aux | grep mysql
root      1587  0.0  0.0  4380  308 ?        S    Jan10   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/server02.hostingserver.nl.pid
mysql    14501  3.2  2.2 265588 22324 ?      S    Jan18  35:26 /usr/sbin/mysqld-max --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/server02.hostingserver.nl.pid --skip-locking --socket=/var/lib/mysql/mysql.sock
root      5615  0.0  0.0  3756  560 pts/3    S    14:49   0:00 grep mysql
[root@server02 root]#

Code:

[root@server02 root]# service mysql
Usage: /etc/init.d/mysql start|stop|restart
[root@server02 root]# service mysqld
mysqld: unrecognized service
[root@server02 root]#

De performance van php/mysql scripts is meestal goed, maar 1 op de 15x heb je weer een parse-time van 10sec.

Dit is overigens gebeurt na de upgrade van MySQL-3 naar MySQL-4

kan aan zoveel dingen liggen, het lijkt me handig als je achterhaald welk script dit veroorzaakt en dan kijkt of die wel goed geoptimalizeerd is

Klopt het dat MySQL-4 alles in 1 process doet?

MySQL Config:

Code:

[root@server02 root]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
skip-locking
skip-innodb
query_cache_limit=1M
query_cache_size=80M
query_cache_type=1
max_connections=500
interactive_timeout=100
wait_timeout=100
connect_timeout=10
thread_cache_size=128
key_buffer=150M
join_buffer=1M
max_allowed_packet=16M
table_cache=512
record_buffer=1M
sort_buffer_size=1M
read_buffer_size=1M
max_connect_errors=10
thread_concurrency=2
myisam_sort_buffer_size=64M
log-bin
server-id=1

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/lib/mysql/mysql.pid <-- Not necessary
open_files_limit=8192

[mysqldump]
quick
max_allowed_packet=16M

[mysql]
no-auto-rehash
#safe-updates

[isamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M

[myisamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M

[mysqlhotcopy]
interactive-timeout
[root@server02 root]#

Pid verandert wel steeds, maar tijd + naam blijft zelfde...
14501 mysql 15 0 29456 24M 2248 S 96.0 2.4 44:48 mysqld-max

Code:

[root@server02 root]# ps -aux | grep 14501
mysql    14501  3.8  2.4 266076 24732 ?      S    Jan18  44:48 /usr/sbin/mysqld-max --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/server02.hostingserver.nl.pid --skip-locking --socket=/var/lib/mysql/mysql.sock
root     11827  0.0  0.0  3708  388 pts/3    R    16:21   0:00 grep 14501
[root@server02 root]#

Misschien een query die erg zwaar is.
Kun je bekijken door een parameter mee te geven.

http://www.mysql.com/doc/en/Slow_query_log.html

[edit]
lees nu je post nog eens, gaat hier helemaal niet over..

thread_concurrency=2

misschien dat je hier eens naar moet kijken ? ( zou je misschien kunnen vinden in de manual van mysql ? )

Als dit letterlijk jouw configuratie is, lijkt het me niet dat mysql deze configuratie slikt. Er staat namelijk:

Code:

pid-file=/var/lib/mysql/mysql.pid <-- Not necessary

Die "<-- Not necessary" moet eruit, waar je dit ook van hebt gekopieerd (ik denk bij ev1servers/rackshack), dit soort dingen kun je beter 3 keer nakijken voordat je het klakkeloos overneemt

Ik heb het inderdaad van het EV1Servers voor. Ik heb het 1x overgekeken. Er stond meer commentaar bij.

Volgens mij is dit echt niet de reden geweest van de grote lange cpu-load vretende MySQL-process.

Het lijkt trouwens uitgemaakt te hebben... load is 0.0 en server is up :P

Ik post morgen meer

Ik heb niet gezegd dat het daaraan ligt, maar als dat er zo in stond, dan negeerde mysql je configuratie (knap, bij mij weigert mysql op die manier op te starten namelijk ). Deze configuratie is gewoon top, en nu wordt die configuratie waarschijnlijk gewoon ingelezen.

Als je trouwens 2 processoren hebt mag je de thread-concurrency ook eens naar 4 gooien, misschien dat dat nog een goed effect heeft voor je

Blijft nog steeds 1 process, maar performance lijkt iets beter geworden te zijn.