Lenteur et plantage Dédié OVH

[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,

/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,

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

Modifié 20 Octobre 2008 par TrocWeb

[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 :

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]

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 :

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 ?

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 ?

Modifié 21 Octobre 2008 par 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 :

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

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

Modifié 21 Octobre 2008 par Dan

[Dan]

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

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

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

Merci a toi Oh Grand Dan

Modifié 21 Octobre 2008 par TrocWeb

[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

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

Modifié 21 Octobre 2008 par TrocWeb

[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

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

Modifié 26 Octobre 2008 par TrocWeb

[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

Modifié 26 Octobre 2008 par TrocWeb

[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 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)

Dan, petite question, ne fait tu pas des interventions Ponctuelles à l'heure par exemple

Modifié 26 Octobre 2008 par TrocWeb

[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é

[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

[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

-------- 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

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 [url="http://dev.mysql.com/doc/refman/4.1/en/point-in-time-recovery.html"]http://dev.mysql.com/doc/refman/4.1/en/poi...e-recovery.html[/url]

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'

Modifié 27 Octobre 2008 par TrocWeb

[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

[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

D'avance merci

voici mon resulta

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 [url="http://dev.mysql.com/doc/refman/4.1/en/point-in-time-recovery.html"]http://dev.mysql.com/doc/refman/4.1/en/poi...e-recovery.html[/url]

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

Modifié 29 Octobre 2008 par TrocWeb

[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]

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 ).