Discussion :

[omelhor]

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

./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'.

[apaul]

Salut,

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

Pour ta question, personnellement je commencerais ici:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[omelhor]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

Sélectionner tout - Visualiser dans une fenêtre à part

SHOW INDEX FROM nom_table

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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

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