Processus linux MySql à 90% du CPU

WRInaute discret
Bonjour à tous !

Je viens de migrer site hebergé sur free vers mon dédié, qui fonctionnait assez bien sur free. Mon dédié sous linux debian qui contenait déja un site web s'est alourdi considérablement depuis avec charge CPU qui s'est affolé et le serveur devenu assez lent.

Celeron 2.6
1 Go RAM
100 Mbit

Voila une capture de la commande top :

topjv3.jpg


Le problème semble venir clairement du processus MySqld, voila mon my.cnf :



#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/serve ... ables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#
# * Fine Tuning
#
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
#max_connections = 200
#table_cache = 64
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
#log_slow_queries = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
#server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
#expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 16M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
#
!includedir /etc/mysql/conf.d/



Le serveur héberge donc 2 sites Web, le premier n'entrainait casi aucune charge pour 4000 VU/jours, depuis que je viens de migrer le nouveau (4000 vu aussi) la charge CPU est montée directement à 70 / 90% ce qui est vraiment anormal d'autnd plus que la base de donnée fais à peine 10 Mo

J'ai bien un mysql_close() à la fin de toutes les pages

Des conseils pour améliorer la situation svp ?

Merci d'avance à tous :wink: :?
 
WRInaute impliqué
Regarde si MySQL t'indiques des slow_queries. A mon avis c'est plutôt de ce côté là qu'il faut regarder, certaines requetes doivent être longues à exécuter.
Gères-tu bien les index dans tes tables ?
 
WRInaute discret
FloBaoti -> tu veux dire dans les processus ?

EDIT : j'ai trouvé ca dans le rouge :

Slow_queries 138
Handler_read_rnd 1 724 k
Handler_read_rnd_next 437 M
Created_tmp_disk_tables 1 093
Opened_tables 113
Table_locks_waited 972

Quand la charge est élevé voici un screen des processus mysql :
processuh5.jpg


Quand la charge devient stable c'est plutot du sleep ... ca devient très rare évidement :s

Ohax -> non j'ai pas rebooté la machine, j'ai essayé divers config du my.cnf en faisant un restart de mysql et aussi d'apache2 ... mais la charge reste toujours aussi élevé :s
 
WRInaute passionné
J'ai le même soucis... (mais avec 600-700 connectés en même temps sur un Xeon Dual Core 2x 2.66 GHz et 4 Go RAM)
Mysql à 99.9% du CPU...

Sur le serveur dédié précédent, le problème était la RAM, le CPU était OK car il y avait plusieurs processus mysql.

Sous un seul processus, ben ça bouchonnne :(
 
WRInaute discret
J'ai fais quelques optimisations du coté des slow_queries en identifiant les requêtes trop lourdes (des count de recherches redondants), ca devrait donc aller mieux demain ... on verra à heure de pointe :)

C'est quand même bizarre que ca fonctionnait bien sur Free et que là un serveur dédié est sur les genoux
 
WRInaute discret
avec un xeon simple et 2 g de mem, je parviens à supporter une charge de 1200 connectés en même temps sur un forum SMF. Voici mes réglages

# * Fine Tuning
#
key_buffer = 148M
max_allowed_packet = 16M
thread_stack = 128K
tmp_table_size = 128M
table_cache = 1500
thread_cache_size = 90
max_heap_table_size = 128M
max_tmp_tables = 64
sort_buffer_size = 6M
myisam_sort_buffer_size = 64M
read_rnd_buffer_size = 2M
join_buffer_size = 5M
read_buffer_size = 2M
long_query_time = 5
thread_concurrency = 4
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1

skip-bdb
skip-innodb
skip-locking

max_user_connections = 150
 
WRInaute discret
il faudrait tester tes requetes sql les plus lourdes avec EXPLAIN pour voir combien de lignes sont lues
et dans le cas où il y a un très grand nombre de lignes, ajouter les index au(x) bon(s) endroit(s)
 
WRInaute passionné
ça fait longtemps que je ne travaille plus avec mysql en production mais sous les versions 3.XX

si les tables etaient trop volumineuses, j'avais facilement des tables temporaires de + de 500mo qui se créaient et ça ralentissait considerablement les requêtes

rog
 
Discussions similaires
Haut