Version complète: sur le forum Webmaster Hub : Lenteur et plantage Dédié OVH
Webmaster Hub > Création et exploitation de Sites Internet > Les fondations d'un site
TrocWeb
Bonjour à tous,

voici un exposé de mon problème

le dédié fonctionne correctement pendant plusieurs semaines, je laisse tourné (j'entends par la, je n'ai fait aucune modification)

depuis quelques jours le serveur rame voir plante, sur les conseils de Dan j'ai effectué une réparation des tables en mode console,
CODE-BOX
/etc/init.d/mysqld stop
cd /var/lib/mysql
for i in *
do
cd /var/lib/mysql/$i
myisamchk --force --recover *.MYI
done
/etc/init.d/mysqld start


rien n'a changé, j'ai pris contact avec Ovh qui ma indiqué que mon fichier log avais une taille critique pour le serveur (1.8go) de faire une rotation manuel et de le mettre en rotation quotidien, chose que j'ai fait

j'ai également tenté une réparation des tables et optimisation sous phpmyadmin

à ce jour le problème persiste, j'ai rebooté la machine plusieurs fois suite au plantage, le temps d'accès de ma page d'acceuil et de 0.50 a a 10.xxx ce qui est énorme pour une simple page, je vous laisse imaginer pour le reste

ou voir parfois

MSG_MYSQL_ERROR_OCCURRED

* MSG_ERROR_MYSQL_CONNECT
* MSG_SQL_ERROR: Too many connections,

sur les conseil de Dan,
CITATION(Dan @ dimanche 19 octobre 2008 à 11:31) *
Si tu as un message d'erreur de type TOO_MANY_CONNECTIONS, il faut modifier (ou ajouter) le paramètre max_connections dans le fichier my.cnf
Par défaut c'est 100, il faut donc l'augmenter puis redémarrer mysql.

Ce fichier my.cnf doit se trouver dans /etc, /etc/mysql ... ou ailleurs. Je ne connais pas l'emplacement des fichiers sous Fedora !


j'ai ajouté la ligne dans my.cnf comme ceci

max_connections 200




quel est votre avis, qu'est ce qui pourrai ralentir et faire planter à ce point le serveur

Cordialement
Kioob
Hello,

amha à moins que tu ais un trafic titanesque, augmenter le nombre de connexions MySQL simultanées est rarement une bonne idée. Il faudrait déjà commencer par regarder à quoi ressemblent ces fameuses 100 connexions. Si c'est un problème de verrou, tu auras beau augmenter la limite à 2000 (et ajouter la mémoire nécessaire) que ça n'y changera probablement rien.

Par contre maintenant que la machine a planté, une réparation des tables est probablement nécessaire.
Dan
As-tu activé le log-slow-queries et le long-query-time ?
Cela te permettrait au moins de voir dans quelles requêtes mysql passe le plus de temps.

Si ce n'est pas activé, tu peux ajouter ceci dans le fichier my.cnf :
CODE
log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 2

Il faudra ensuite t'assurer que le fichier /var/log/mysql/mysql-slow.log existe, éventuellement le créer et puis redémarrer mysql.
f_trt
Je suppose aussi qu'en premier tu as regardé que c'est a trafic égal, je veux dire par là que certe tu n'avais rien touché mais le trafic allait-il coissant jusqu'au problème ou était-il stable et donc laisse supposer un autre problème ?

Autre question les pages statiques (sans mysql) mettent-elle aussi 10 fois plus de temps ? (fsck peut-être ?)
TrocWeb
CITATION(Dan @ mardi 21 octobre 2008 à 09:49) *
As-tu activé le log-slow-queries et le long-query-time ?
Cela te permettrait au moins de voir dans quelles requêtes mysql passe le plus de temps.

Si ce n'est pas activé, tu peux ajouter ceci dans le fichier my.cnf :
CODE
log_slow_queries        = /var/log/mysql/mysql-slow.log
  long_query_time = 2

Il faudra ensuite t'assurer que le fichier /var/log/mysql/mysql-slow.log existe, éventuellement le créer et puis redémarrer mysql.


Question : je doit mettre la commande au gout de fedora comme ceci ?

CODE
log_slow_queries        = /var/lib/mysql/mysql-slow.log
long_query_time = 2


et créer le fichier mysql-slow.log en 777 dans /var/lib/mysql/

est ce bien cela Dan ?
Dan
A mon avis pas dans /var/lib, mais plutôt dans /var/log ...
Si le répertoire /var/log/mysql n'existe pas, soit tu le crées, soit tu changes cette ligne pour :
CODE
log_slow_queries        = /var/log/mysql-slow.log


L'important est que le fichier soit créé, et ait comme utilisateur "mysql" ... pas besoin de mode 777.
TrocWeb
j'ai donc installé cette ligne dans my.cnf

CODE
log_slow_queries        = /var/log/mysql-slow.log
  long_query_time = 2


j'ai créé un fichier mysql-slow.log dans /var/log/ AVEC WIN SCP

et j'ai fait

/etc/init.d/mysqld stop
/etc/init.d/mysqld start

n'étant pas sur que je pouvais effectuer /etc/init.d/mysqld restart

ai-je bien compris la procédure ?

par contre le fichier et root et non mysql ..la j'ai un doute, si tel est le cas je ne vois pas comment faire ce fichier en user mysql
Dan
CITATION(TrocWeb @ mardi 21 octobre 2008 à 15:53) *
par contre le fichier et root et non mysql ..la j'ai un doute, si tel est le cas je ne vois pas comment faire ce fichier en user mysql

CODE
chown mysql nom_du_fichier

tout simplement !

Dan

PS: merci de n'utiliser la balise codebox que pour les codes supérieurs à une dizaine de lignes !
TrocWeb
a ben oui, suis je bête, en plus je l'ai fait sur le serveur de jeu de ma Team pour leur donner les droits sick.gif

EDIT c'est bon les droits sont ok, je regarderais dans plusieurs heures ce que cela donnera

Merci a toi Oh Grand Dan
TrocWeb
suite...

j'ai fait un fichier mysql-slow.log dans /var/log/

puis donné le fichier à l'utilisateur mysql


chown mysql mysql-slow.log


j'ai indiqué cette ligne tel que ci-dessous dans My.cnf

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
max_connections 200
log_slow_queries = /var/log/mysql-slow.log
long_query_time = 2

puis j'ai arrêté mysql puis remis en route

/etc/init.d/mysqld stop
/etc/init.d/mysqld start


après plusieurs Heures, le fichier reste vide shutup.gif

j'ai vérifié les lignes, tout est ok, comme tu la indiqué

Dan, petite question, ne fait tu pas des interventions Ponctuelles à l'heure par exemple smartass.gif
TrocWeb
bonjour Dan et le Hub, j'ai réussi à faire marcher ce fichier mysql-slow.log

voila un exemple de la longue liste qui s'enregistre... cela vous parle t-il car moi sick.gif

D'avance merci


# User_AT_Host: encheres[encheres] @ localhost []
# Query_time: 2 Lock_time: 0 Rows_sent: 0 Rows_examined: 248069
SELECT box_id, box_value FROM custom_fields_data WHERE
owner_id=100713 AND page_handle='auction';
# User_AT_Host: encheres[encheres] @ localhost []
# Query_time: 2 Lock_time: 0 Rows_sent: 0 Rows_examined: 248069
SELECT box_id, box_value FROM custom_fields_data WHERE
owner_id=100025 AND page_handle='auction';
Dan
Ces requêtes ne durent que 2 secondes, tu dois à mon avis en avoir de bien plus longues.

As-tu bien des index sur owner_id (j'imagine que oui) et page_handle (moins sûr) ?
TrocWeb
Merci pour ton aide précieuse Dan


la requête la plus long et un Query_time: 8, elle concerne également la table custom_fields_data

concernant "As-tu bien des index sur owner_id (j'imagine que oui) et page_handle (moins sûr) ?"

tu me demande si il y a des requêtes de ce genre dans la liste ?
TrocWeb
re bonjour le Hub


concernant la lenteur et le processus mysql (parfois 117 %) parfois 23

le problème indiqué ci dessous par Phpmyadmin peut-il en être la cause ?

si oui comment réparer cela, existe t-il un risque pour le site ?

Il y a des problèmes avec les index de la table `auction_media`
Warning Plus d'un index de type INDEX existe pour la colonne `auction_id`
Il y a des problèmes avec les index de la table `auctions`
Warning Plus d'un index de type INDEX existe pour la colonne `active`
Il y a des problèmes avec les index de la table `bids`
Warning Plus d'un index de type INDEX existe pour la colonne `auction_id`
Il y a des problèmes avec les index de la table `bulktmp`
Warning La colonne `id` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index
Il y a des problèmes avec les index de la table `categories`
Warning Plus d'un index de type INDEX existe pour la colonne `parent_id`
Il y a des problèmes avec les index de la table `favourite_stores`
Warning Plus d'un index de type INDEX existe pour la colonne `store_id`
Il y a des problèmes avec les index de la table `invoices`
Warning Plus d'un index de type INDEX existe pour la colonne `user_id`
Il y a des problèmes avec les index de la table `messaging`
Warning Plus d'un index de type INDEX existe pour la colonne `topic_id`
Warning Plus d'un index de type INDEX existe pour la colonne `auction_id`
Il y a des problèmes avec les index de la table `proxybid`
Warning Plus d'un index de type INDEX existe pour la colonne `auction_id`
Il y a des problèmes avec les index de la table `users`

A noter ces soucis ont toujours été la, j'avais lu précédemment (suite a plusieurs recherche) que cela n'était pas important, je me dit donc que le problème de lenteur de viens pas de la ?

d'avance merci pour votre aide
Dan
C'est clairement de là que viennent tes problèmes.
Tu as vraisemblablement eu un arrêt "brutal" du serveur, ce qui arrive lorsque tu le rebootes par le manager (coupure d'alimentation)

Il faut réparer la base de données avec myisamchk (idéalement) ou mysqlcheck.

Le deuxième te permet de le faire sans arrêter mysql, pas le premier.

Dan
TrocWeb
j'ai deja effectué cette procédure (plusieurs fois même) selon ta méthode

/etc/init.d/mysqld stop
cd /var/lib/mysql
for i in *
do
cd /var/lib/mysql/$i
myisamchk --force --recover *.MYI
done
/etc/init.d/mysqld start



et rie n'y fait, j'ai toujours ces erreur d'index

merci pour tous... j'apprends doucement mais surement avec l'aide du hub a_thumbsup_20.gif
Dan
Tu devrais commencer par supprimer les index qui sont en double...
Puis lancer myisamchk.

Tu as eu des erreurs lors du mysamchk ?
TrocWeb
j'ai eu une erreur une fois, mais pas les fois suivante, je pense que la commande la réparé,

par contre pour supprimer les index en double sick.gif si tu peut m'aiguiller... je vais tous de même faire des recherches avec note amis Google

petite précision de ma part, ce script à l'état brut a déjà des index en doubles, ne sont il pas volontaire ? cela est t-il une erreur de leur part ?

TrocWeb (Fred)

CITATION(TrocWeb @ mardi 21 octobre 2008 à 23:11) *
Dan, petite question, ne fait tu pas des interventions Ponctuelles à l'heure par exemple smartass.gif
TrocWeb
Dan j'ai pris contact avec le concepteur du script, il me dit de ne surtout pas supprimer les doubles, que cela a été fait pour optimiser le code

j'exploite par contre un soucis de taille mon fichier my.cnf ne contient aucune valeur de réglage mis a part quelques ligne et d'après mes longueeeeeesss recherche ce fichier doit avoir des paramètres, ce qui du coup me dit, que mon serveur n'est absolument pas optimisé shutup.gif
Dan
Tu peux avoir des index créés sur des clés multiples, et ces clés peuvent aussi se retrouver comme index simple.
Dans ce cas il faut les laisser tels quels.

Et pour my.cnf, il faudrait savoir quelle version de mysql tu tournes.
Les paramètres du cache se paramètrent dans ce fichier, par exemple.
TrocWeb
ma version est : MySQL version 4.1.20-log

et mon fichier my.cnf est dépourvu de toutes optimisation, voici ce qu'il contient, donc aucun cache activé ce qui je suppose n'est pas pour améliorer les performances du serveur


My.cnf
CODE-BOX
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

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

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysqld]
set-variable=long_query_time=1
log-slow-queries=/var/log/mysql/log-slow-queries.log

[mysqld]
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2


paramètres Mysql actuel
CODE-BOX
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[!!] Your MySQL version 4.1.20-log is EOL software! Upgrade soon!
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive +BDB -Federated +InnoDB +ISAM -NDBCluster
[--] Data in MyISAM tables: 293M (Tables: 327)
[--] Data in InnoDB tables: 5M (Tables: 117)
[!!] BDB is enabled but isn't being used
[!!] ISAM is enabled but isn't being used
[!!] Total fragmented tables: 12

-------- Performance Metrics -------------------------------------------------
[--] Up for: 19h 9m 22s (1M q [20.778 qps], 29K conn, TX: 3B, RX: 185M)
[--] Reads / Writes: 94% / 6%
[--] Total buffers: 34.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 302.7M (30% of installed RAM)
[OK] Slow queries: 0% (5K/1M)
[OK] Highest usage of available connections: 69% (69/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/91.3M
[OK] Key buffer hit rate: 99.9% (178M cached / 187K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 253K sorts)
[OK] Temporary tables created on disk: 10% (253 on disk / 2K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 8K opened)
[OK] Open file limit used: 10% (103/1K)
[OK] Table locks acquired immediately: 99% (1M immediate / 1M locks)
[OK] InnoDB data size / buffer pool: 5.9M/8.0M


en voici d'autres

CODE-BOX
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 2 sec.
You have 5626 out of 1443309 that take longer than 2 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/4.1/en/poi...e-recovery.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 3
Historic max_used_connections = 69
The number of used connections is 69% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 203 M
Configured Max Per-thread Buffers : 268 M
Configured Max Global Buffers : 17 M
Configured Max Memory Limit : 286 M
Physical Memory : 1000.35 M
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 91 M
Current key_buffer_size = 7 M
Key cache miss rate is 1 : 945
Key buffer fill ratio = 91.00 %
You could increase key_buffer_size
It is safe to raise this up to 1/4 of total system memory;
assuming this is a dedicated database server.

QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 48 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 444 tables
You have 64 open tables.
Current table_cache hit rate is 0%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 2109 temp tables, 12% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 2053 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 373
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
TrocWeb
bonjour je vous fait par de mes recherches et de mes optimisations de mon My.cnf

espérant avoir votre avis sur les réglages (bon ou mauvais) et si j'en ai oublié en passant

Merci à vous

TrocWeb


CODE-BOX
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

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

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysqld]
set-variable=long_query_time=1
log-slow-queries=/var/log/mysql/log-slow-queries.log

[mysqld]
log_slow_queries = /var/log/mysql/mysql-slow.log

key_buffer_size = 512M

query_cache_size = 16M

query_cache_limit = 50M


thread_cache_size = 4

sort_buffer_size = 510M

max_connections = 128

table_cache = 100000

max_heap_table_size = 128M

tmp_table_size = 100M

read_buffer_size = 7M
TrocWeb
Bonjour

j'aimerais savoir si il y a une norme bien précise pour un P4 3GHZ avec 1024 de mémoire pour le My.Cnf ou si chaque serveur a son propre réglage

n'existe t-il pas un fichier type? car après de longue recherche et réglage divers sick.gif

D'avance merci

voici mon resulta mad2.gif

CODE-BOX
SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 1 sec.
You have 0 out of 111 that take longer than 1 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/4.1/en/poi...e-recovery.html

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 1
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 1
Historic max_used_connections = 2
The number of used connections is 1% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

MEMORY USAGE
Max Memory Ever Allocated : 146 M
Configured Max Per-thread Buffers : 899 M
Configured Max Global Buffers : 138 M
Configured Max Memory Limit : 1 G
Physical Memory : 1000.35 M

Max memory limit exceeds 90% of physical memory

KEY BUFFER
Current MyISAM index space = 91 M
Current key_buffer_size = 64 M
Key cache miss rate is 1 : 5
Key buffer fill ratio = 3.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 64 M
Current query_cache_used = 164 K
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = .25 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

OPEN FILES LIMIT
Current open_files_limit = 1234 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 512 tables
You have a total of 386 tables
You have 29 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 0 temp tables, 0% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 3073 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 234
Your table locking seems to be fine
Dan
Dans toute distribution de mysql tu dois avoir des fichiers exemples : my-small.cnf, my-medium.cnf, my-large.cnf et my-huge.cnf
Ils sont dans le sous-répertoire support-files de ta distribution.

Tu devrais trouver leur emplacement avec "locate my-large.cnf"

Tu peux d'ailleurs te baser sur my-large en adaptant le 'thread-concurrency' qu'il faut mettre au nombre de coeurs CPUx2 (donc quatre pour un dual-core, 2 pour un simple coeur)
Kioob
CITATION
j'aimerais savoir si il y a une norme bien précise pour un P4 3GHZ avec 1024 de mémoire pour le My.Cnf ou si chaque serveur a son propre réglage


Chaque serveur a son propre "réglage", surtout que cela dépend en grande partie de tes données. A la limite je conseillerais MySQLTuner, qui tente de régler ça de manière automatisée (c'est évidement moins bien qu'une vraie configuration, mais toujours mieux que ce qu'on trouve à l'installation).
Sinon même conseil que Dan : il y a quelques infos intéressantes dans les fichiers de conf fournis en exemple par MySQL (sous Debian c'est stocké dans /usr/share/doc/mysql-server-5.0/examples ).
TrocWeb
Bonjour

merci pour votre aide,

sous fedora, les fichiers exemple sont bien la /usr/share/doc/mysql-server-5.0/examples

j'ai opté pour my-large


CODE-BOX
# The MySQL server
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 2


le problème avec MySQLTuner, c'est qu'il lui faut un serveur qui tourne depuis 48H et le mien (suite au mauvais réglage) tombe généralement avant mad2.gif
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.