optimisation bdd mysql

Version imprimable

07/03/2013, 00h00
omelhor

optimisation bdd mysql

Bonsoir,

Je cherche a optimiser ma bdd, et je suis tombé sur le script tuning-primer.sh qui m'a donné les résultats ci-dessous.
Est-ce que quelqu'un saurait utilisé ces résultats ou du moins en tirer l'essentiel ?

Merci beaucoup pour votre aider

Citation:

./tuning-primer.sh

-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 5.0.44-log x86_64

Uptime = 47 days 3 hrs 54 min 33 sec
Avg. qps = 188
Total Questions = 770046854
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/...variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 5 sec.
You have 5219 out of 770046875 that take longer than 5 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/5.0/...-recovery.html

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

MAX CONNECTIONS
Current max_connections = 1000
Current threads_connected = 1
Historic max_used_connections = 330
The number of used connections is 33% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 64 K
Current InnoDB data space = 4 M
Current InnoDB buffer pool free = 66 %
Current innodb_buffer_pool_size = 16 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 1.68 G
Configured Max Per-thread Buffers : 3.28 G
Configured Max Global Buffers : 610 M
Configured Max Memory Limit : 3.88 G
Physical Memory : 23.59 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 721 M
Current key_buffer_size = 512 M
Key cache miss rate is 1 : 124
Key buffer free ratio = 50 %
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 = 72 M
Current query_cache_used = 53 M
Current query_cache_limit = 2 M
Current Query cache Memory fill ratio = 74.07 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 512 K
Current read_rnd_buffer_size = 508 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 = 7010 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 = 3000 tables
You have a total of 1162 tables
You have 2975 open tables.
Current table_cache hit rate is 4%
, while 99% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 936 M
Current tmp_table_size = 936 M
Of 319042 temp tables, 44% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 29189 : 1
You have a high ratio of sequential access requests to SELECTs
You may benefit from raising read_buffer_size and/or improving your use of indexes.

TABLE LOCKING
Current Lock Wait ratio = 1 : 1278
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'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.

Salut,

Je ne connaissais pas ce script, sympa. Où l'as-tu trouvé?

Pour ta question, personnellement je commencerais ici:
Code:

1 2 3 4 5 TABLE SCANS Current read_buffer_size = 1 M Current TABLE scan ratio = 29189 : 1 You have a high ratio of sequential access requests TO SELECTs You may benefit FROM raising read_buffer_size AND/OR improving your USE of indexes.
Bien que tu aies un read_buffer_size assez gros, tu as beaucoup d'accès séquentiels. Ca veut dire que quand tu fais un SELECT, chaque ligne de ta table doit être lue une a une. Ca peut s'expliquer si tu ne fais que des "SELECT * FROM ma_table; " par contre, si tu as des clauses WHERE dans la plupart de tes requêtes, ce n'est pas normal, tu manques d'index.

Tu aurais peut-être plus d'infos avec l'option log-queries-not-using-indexes.

Salut Paul

Le script je l'ai trouvé par hazard sur google dans un forum ( je ne sais plus lequel ) il y a quelques mois

Pour l'optimisation de ma base voici quelques infos complémentaires :

50 % de mes requêtes proviennent de cette requête :
Code:

1 2 SELECT SQL_NO_CACHE title,author,timestamp,url,contents,image FROM nom_table WHERE timestamp < CURRENT_TIMESTAMP() ORDER BY `timestamp` DESC LIMIT 0,100;
A savoir que la table en question a environ 100 000 enregistrement ( ca fait beaucoup je pense )

La structure de celle-ci est la suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 CREATE TABLE IF NOT EXISTS `newsindex` ( `ID` int(4) NOT NULL auto_increment, `title` varchar(150) NOT NULL default '', `url` varchar(255) NOT NULL, `timestamp` datetime default NULL, `contents` text NOT NULL, `author` varchar(100) NOT NULL default '', `image` varchar(255) default '', PRIMARY KEY (`ID`), UNIQUE KEY `title` (`title`), UNIQUE KEY `url` (`url`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=923445 ;
J'ignore si mes index sont correct !!!

Je vais mettre en place le log-queries-not-using-indexes pour voir ce que cela donne

Merci beaucoup

08/03/2013, 13h40
apaul

Ok, tu fais des requêtes en interrogeant le champ "timestamp" mais il n'a pas l'air indexé. Pour en être sûr:

Code:

SHOW INDEX FROM nom_table

Du coup, tu peux en faire un comme ça:

Code:

create index idx_timestamp on nom_table(`timestamp`) ;

Si tu veux relancer tes stats plus tard, elles vont être polluées par les anciennes valeurs à moins que tu puisses monitorer leur évolution (FLUSH LOGS ne remet pas tous les compteurs à zéro). Du coup, le mieux est de redémarrer ta base, la laisser tourner sur la même période, puis voir si tu as du changement.

Ou alors, plus rapide, tu ne monitores que cette variable. Tu fais des:

Code:

show status like 'Handler_read_rnd_next' ;

Assez régulièrement avant et après la modif, tu vas voir comment ca évolue (ca devrait augmenter beaucoup moins vite après, ce qui serait une bonne chose)

PS: "timestamp" étant un mot réservé, ce n'est pas très pratique d'appeler une colonne comme ça. Ca oblige à utiliser les backquotes.

Edit: Lance ta requête avant et après la création des index pour voir la différence aussi...
08/03/2013, 17h29
omelhor

Salut,

Il est vraie que le nom choisit "timestamp" n'a pas été très judicieux, j'ai prévue de le modifier, mais il faut au préalable que je recentralise tous mes sites web.
J'ai crée un index sur timestamp comme tu me la préconiser
le résultat est impressionnant de 0.0603 je suis passé à 0.0009 sec. !!!

Du coup je pense généraliser les index sur ma colonne timestamp sur les tables qui utilisent la même requête SQL, du gros boulot en perspective !!!

Petite question par rapport a cet index, est-ce que la prend de la conso sur la mémoire ?

Merci beaucoup
11/03/2013, 08h31
apaul

Salut,

Pour tout ce qui est conso de la mémoire vive, MySQL prévoit de l'espace pour ça (les key_buffer_...) dont la taille est définie dans le my.cnf.
Le "problème" des index en principe n'est pas vraiment la conso mémoire, mais plutôt le ralentissement des inserts. En effet, à chaque insert, pour que l'index soit utilisable, il doit bien entendu tout mettre en ordre. C'est cette opération qui peut prendre du temps. Dans la plupart des cas, c'est assez négligeable (sauf si on met des indexes partout et en double...). Par contre, pour les bases qui font des écritures intensives, ca peut jouer.

Quand il y a un gros bloc d'insert à faire, certains proposent de détruire l'index avant, faire les inserts et recréer l'index ensuite.
11/03/2013, 14h35
CinePhil
Une autre approche...
Citation:
Envoyé par omelhor

50 % de mes requêtes proviennent de cette requête :

Code:

1 2 SELECT SQL_NO_CACHE title,author,timestamp,url,contents,image FROM nom_table WHERE timestamp < CURRENT_TIMESTAMP() ORDER BY `timestamp` DESC LIMIT 0,100;
Ce qui me choque un peu dans cette requête, c'est le WHERE dont je ne perçois pas l'utilité ! 8O

Comment est alimenté la colonne mal nommée 'timestamp' ?
Si elle prend le timestamp actuel au moment de l'insertion et n'est jamais à NULL, il est fort probable que l'index sur la colonne 'timestamp' aura autant de valeurs différentes qu'il y a de lignes dans la table.

La partie ORDER BY `timestamp` DESC LIMIT 0,100 oblige MySQL à d'abord ordonner toutes les lignes puis ne retenir que les 100 premières du classement.

Il serait plus pertinent de faire une estimation large du timestamp de la centième ligne et de restreindre dans le where les timestamp supérieurs à cette estimation.
Par exemple, s'il y a en moyenne 10 images insérées par semaine, en comptant large, il suffirait de prendre les images des 15 dernières semaines et d'en limiter le jeu de résultats aux 100 premières :
Code:

1 2 3 4 5 SELECT SQL_NO_CACHE title, author, `timestamp`, url, contents, image FROM nom_table WHERE timestamp > DATE_SUB(CURRENT_TIMESTAMP INTERVAL 15 WEEK) ORDER BY `timestamp` DESC LIMIT 0,100;
Ainsi, l'utilisation de l'index devient pertinente et le tri se fait seulement sur les lignes des 15 dernières semaines et non plus sur la totalité des lignes.

Citation:
Envoyé par CinePhil
Une autre approche...

Ce qui me choque un peu dans cette requête, c'est le WHERE dont je ne perçois pas l'utilité ! 8O

Comment est alimenté la colonne mal nommée 'timestamp' ?
Si elle prend le timestamp actuel au moment de l'insertion et n'est jamais à NULL, il est fort probable que l'index sur la colonne 'timestamp' aura autant de valeurs différentes qu'il y a de lignes dans la table.

La partie ORDER BY `timestamp` DESC LIMIT 0,100 oblige MySQL à d'abord ordonner toutes les lignes puis ne retenir que les 100 premières du classement.

Il serait plus pertinent de faire une estimation large du timestamp de la centième ligne et de restreindre dans le where les timestamp supérieurs à cette estimation.
Par exemple, s'il y a en moyenne 10 images insérées par semaine, en comptant large, il suffirait de prendre les images des 15 dernières semaines et d'en limiter le jeu de résultats aux 100 premières :
Code:

1 2 3 4 5 SELECT SQL_NO_CACHE title, author, `timestamp`, url, contents, image FROM nom_table WHERE timestamp > DATE_SUB(CURRENT_TIMESTAMP INTERVAL 15 WEEK) ORDER BY `timestamp` DESC LIMIT 0,100;
Ainsi, l'utilisation de l'index devient pertinente et le tri se fait seulement sur les lignes des 15 dernières semaines et non plus sur la totalité des lignes.
Salut,

En fait je récupère des news via des flux RSS, et c'est la date présente dans ces news qui inséré dans la colonne "timestamp". Ce WHERE je l'ai mis car des fois la date est supérieur a l'heure actuelle.
Je récupère environ 1000 news par jour.

En faisant un test sur ces 2 requêtes, j'obtient pour les 2 un temps de 0.0010 sec
Code:

1 2 3 4 5 6 7 8 9 10 11 12 SELECT SQL_NO_CACHE title, author, `timestamp` , url, contents, image FROM newsindex WHERE `timestamp` > DATE_SUB( CURRENT_TIMESTAMP , INTERVAL 15 WEEK ) ORDER BY `timestamp` DESC LIMIT 0 , 100 SELECT SQL_NO_CACHE title,author,timestamp,url,contents,image FROM newsindex WHERE timestamp < CURRENT_TIMESTAMP() ORDER BY `timestamp` DESC LIMIT 0,100;
Quel genre de test pourais-je faire afin de savoir laquelle est la plus optimisée ?

merci beaucoup

13/03/2013, 23h02
CinePhil

Citation:

Je récupère environ 1000 news par jour.

Code:

LIMIT 0,100;

Tu ne veux que les 100 dernières, c'est à dire moins d'une journée donc inutile de classer toute la table. Ceci devrait largement suffire :

Code:

WHERE timestamp > DATE_SUB(CURRENT_TIMESTAMP INTERVAL 24 HOUR)
14/03/2013, 11h21
Fred_34

Citation:

Envoyé par CinePhil

Tu ne veux que les 100 dernières, c'est à dire moins d'une journée donc inutile de classer toute la table.

Est-ce que tu dis ça en fonction de la version ( 5.0.44 ) de Omelhor ?

Sur une version récente, si je fais un explain sur ORDER BY un_index LIMIT 1000, MySQL ne va lire que 1000 lignes.
14/03/2013, 11h35
CinePhil

J'avoue que je disais ça par intuition.