mysql | query cache

4 réponses

Auteur	Message
flush \| Modérateur Inscrit le : 09/05/2005	# Le 24/07/2008 à 22:39 Bon j'ai pas de chance depuis hier ... mon serveur mysql principal à eu la chance de se faire asperger de liquide de clim chez OVH et à donc été HS pendant 6 ou 7 heures. Depuis ma config déconne complètement (hier 23heures), un consultant mysql était venu le réglé, et il a du faire des réglages a chaud sans la reporter dans le my.cnf Bref en gros il arrête pas de charger a fond, et je pense que cela vient du query cache, voilà mes infos : mysql> show status like '%qc%'; +-------------------------+----------+ \| Variable_name \| Value \| +-------------------------+----------+ \| Qcache_free_blocks \| 6155 \| \| Qcache_free_memory \| 20595760 \| \| Qcache_hits \| 3780622 \| \| Qcache_inserts \| 14759826 \| \| Qcache_lowmem_prunes \| 97602 \| \| Qcache_not_cached \| 4855919 \| \| Qcache_queries_in_cache \| 11248 \| \| Qcache_total_blocks \| 28719 \| +-------------------------+----------+ 8 rows in set (0.04 sec) mysql> show variables like '%cache%'; +------------------------------+----------------------+ \| Variable_name \| Value \| +------------------------------+----------------------+ \| binlog_cache_size \| 32768 \| \| have_query_cache \| YES \| \| key_cache_age_threshold \| 300 \| \| key_cache_block_size \| 1024 \| \| key_cache_division_limit \| 100 \| \| max_binlog_cache_size \| 18446744073709551615 \| \| ndb_cache_check_time \| 0 \| \| query_cache_limit \| 2097152 \| \| query_cache_min_res_unit \| 4096 \| \| query_cache_size \| 33554432 \| \| query_cache_type \| ON \| \| query_cache_wlock_invalidate \| ON \| \| table_cache \| 2560 \| \| thread_cache_size \| 256 \| +------------------------------+----------------------+ 14 rows in set (0.00 sec) Au début j'avais : query_cache_limit à 64M query_cache_size à 128M Mais bon dans tous les cas, il semble peu utilisé. Avez vous une idée ? Merci Regardez la tête de la charge : http://www.casimages.com/img.php?i=080724104524418... (Message édité le 24-07-2008 à 22h44 par flush) @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/07/2008 à 23:02 D'un autre coté après un redémarrage de MySQL il faut le temps que tout se recharge dans les différents cache, ainsi que le cache disque vu qu'il y a eu reboot. Mais c'est vrai que là ça fait long et les stats ne sont pas forcément géniales. (en passant, un show global status like 'com_select'; donne environ la valeur de Qcache_inserts + Qcache_not_cached ??) Là tu as un cache de 32Mo et tu ne mets pas en cache les requêtes de plus de 2Mo : c'est toi qui a mis ça ? le 128M/64M d'au départ, c'est pas ce que le consultant avait mis ? D'ailleurs ne peux tu pas le recontacter ? Des fois qu'il s'en souviendrait un peu... daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 24/07/2008 à 23:09 mysql> show global status like 'com_select'; +---------------+----------+ \| Variable_name \| Value \| +---------------+----------+ \| Com_select \| 20400064 \| +---------------+----------+ 1 row in set (0.03 sec) J'ai bien l'email du consultant mais je suis sur qu'il a tout oublier ! La valeur 128/64 c'était dans le fichier ... Oui il faut du temps pour que tout remonte ... mais bon ça me semble un peu long, je vais tenter de remettre les mêmes valeurs à chaud. @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 24/07/2008 à 23:21 Oki c'est bien ça. Donc grosso modo tu as 20-25% des SELECT qui ne peuvent pas être mis en cache, soit parce que le résultat est trop gros (quoi que 2Mo c'est déjà pas mal je trouve) soit parce que la requête contient des éléments l'en empêchant (now, curdate, etc). Mais je ne suis pas persuadé que le problème vienne de là. T'es en full innodb, c'est bien ça ? Donc pas de soucis d'index corrompu à priori. Qu'il ait tout oublié je veux bien, mais s'il a aussi oublié d'enregistrer ses modifs dans la conf il a le droit de recommencer gratuitement non ? daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 25/07/2008 à 09:04 Non j'ai que 10% des tables en innodb. Ouais, ça va surtout être dur de le chopper le gars ! Il est toujours entre 2 avions et 3 trains ... entre milan et madrid, paris, berlin, les pays nordiques ... Bref je vais voir avec le support mysql déjà ^^ Sinon il reviendra ! mais je sais que ca va pas etre du rapide @+ Jean-Philippe

Auteur

Message

flush |
Modérateur

Inscrit le : 09/05/2005

# Le 24/07/2008 à 22:39

Bon j'ai pas de chance depuis hier ... mon serveur mysql principal à eu la chance de se faire asperger de liquide de clim chez OVH et à donc été HS pendant 6 ou 7 heures.

Depuis ma config déconne complètement (hier 23heures), un consultant mysql était venu le réglé, et il a du faire des réglages a chaud sans la reporter dans le my.cnf

Bref en gros il arrête pas de charger a fond, et je pense que cela vient du query cache, voilà mes infos :

mysql> show status like '%qc%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 6155 |
| Qcache_free_memory | 20595760 |
| Qcache_hits | 3780622 |
| Qcache_inserts | 14759826 |
| Qcache_lowmem_prunes | 97602 |
| Qcache_not_cached | 4855919 |
| Qcache_queries_in_cache | 11248 |
| Qcache_total_blocks | 28719 |
+-------------------------+----------+
8 rows in set (0.04 sec)

mysql> show variables like '%cache%';
+------------------------------+----------------------+
| Variable_name | Value |
+------------------------------+----------------------+
| binlog_cache_size | 32768 |
| have_query_cache | YES |
| key_cache_age_threshold | 300 |
| key_cache_block_size | 1024 |
| key_cache_division_limit | 100 |
| max_binlog_cache_size | 18446744073709551615 |
| ndb_cache_check_time | 0 |
| query_cache_limit | 2097152 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 33554432 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | ON |
| table_cache | 2560 |
| thread_cache_size | 256 |
+------------------------------+----------------------+
14 rows in set (0.00 sec)

Au début j'avais :
query_cache_limit à 64M
query_cache_size à 128M

Mais bon dans tous les cas, il semble peu utilisé.

Avez vous une idée ?

Merci

Regardez la tête de la charge : http://www.casimages.com/img.php?i=080724104524418...

(Message édité le 24-07-2008 à 22h44 par flush)

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/07/2008 à 23:02

D'un autre coté après un redémarrage de MySQL il faut le temps que tout se recharge dans les différents cache, ainsi que le cache disque vu qu'il y a eu reboot.

Mais c'est vrai que là ça fait long et les stats ne sont pas forcément géniales.
(en passant, un show global status like 'com_select'; donne environ la valeur de Qcache_inserts + Qcache_not_cached ??)

Là tu as un cache de 32Mo et tu ne mets pas en cache les requêtes de plus de 2Mo : c'est toi qui a mis ça ? le 128M/64M d'au départ, c'est pas ce que le consultant avait mis ?

D'ailleurs ne peux tu pas le recontacter ? Des fois qu'il s'en souviendrait un peu...

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 24/07/2008 à 23:09

mysql> show global status like 'com_select';
+---------------+----------+
| Variable_name | Value |
+---------------+----------+
| Com_select | 20400064 |
+---------------+----------+
1 row in set (0.03 sec)

J'ai bien l'email du consultant mais je suis sur qu'il a tout oublier !

La valeur 128/64 c'était dans le fichier ...

Oui il faut du temps pour que tout remonte ... mais bon ça me semble un peu long, je vais tenter de remettre les mêmes valeurs à chaud.

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 24/07/2008 à 23:21

Oki c'est bien ça. Donc grosso modo tu as 20-25% des SELECT qui ne peuvent pas être mis en cache, soit parce que le résultat est trop gros (quoi que 2Mo c'est déjà pas mal je trouve) soit parce que la requête contient des éléments l'en empêchant (now, curdate, etc).

Mais je ne suis pas persuadé que le problème vienne de là.
T'es en full innodb, c'est bien ça ? Donc pas de soucis d'index corrompu à priori.

Qu'il ait tout oublié je veux bien, mais s'il a aussi oublié d'enregistrer ses modifs dans la conf il a le droit de recommencer gratuitement non ?

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 25/07/2008 à 09:04

Non j'ai que 10% des tables en innodb.

Ouais, ça va surtout être dur de le chopper le gars ! Il est toujours entre 2 avions et 3 trains ... entre milan et madrid, paris, berlin, les pays nordiques ...

Bref je vais voir avec le support mysql déjà ^^
Sinon il reviendra ! mais je sais que ca va pas etre du rapide

@+ Jean-Philippe

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.