Pour MySQL : myisam_use_mmap = 1 souhaitable ?

ortolojf · 3 Juin 2015

Bonjour

Toutes les tables MySQL de mes deux bdds, sont en MyISAM.

J'ai fait le tuning de mon serveur MySQL depuis avant-hier, avec les scripts mysqltuner.pl et tuning-primer.sh

Je pense avoir fait le maximum ce soir, malgré mes 8 tables ( légèrement ) sous-optimisées sur 72 tables environ ).

Pour optimiser au maximum mes tables, j'ai tout bonnement sauvegardé les deux bdd postfixadmin et puis celle des courses, ( + 500MB quand même pour cette dernière ) , puis j'ai dropé toutes les tables, vérifié que les fichiers ne s'y trouvaient plus dans le répertoire des bdds, puis restauré les deux bdds.

Mon problème est le suivant :

J'ai le query cache configuré correct d'après les deux scripts.

Cependant je pense que je pourrais améliorer encore les performances,en mettant la variable suivante à 1 :

myisam_use_mmap = 1

Ma version de MySQL est : 5.5 je crois ).

Ma question est : Cette variable pose-t-elle des problème de stabilité du serveurMySQL, ou de désoptimisation des tables ?

Merci beaucoup de vos réponses.

Respectueusement.

frenchhorn · 4 Juin 2015

salut

en cherchant juste la requete "myisam_use_mmap" sur google, on voit bien que ca peut te causer beaucoup plus de problèmes qu'autre chose...

perso je ne tenterais pas le diable avec cette option...

ortolojf · 4 Juin 2015

Bonjour frenchhorn

Et par rapport au query_cache ?

J'ai vaguement vu sur le net, un blog indiquant des statistiques défavorables au fait de mettre le query_cache à actif, pour des tables MyISAM ?

Pour l'instant mon query_cache est désactivé ( depuis hier soir ), et je sais quels paramètres mettre pour l'activer ( certifiés par les deux scripts ).

J'ajoute ( après vérification ), que le total de tous mes fichiers de bdd de courses, fait environ 200 MB et non pas 500MB.

Merci beaucoup de ta réponse.

Respectueusement.

frenchhorn · 4 Juin 2015

quels problèmes de performances rencontre tu? La plupart du temps il y a deux améliorations possibles:

- créer les bons index sur tes tables, par exemple si tu fais souvent un SELECT sur le champs "prenom" alors il vaut mieux avoir mis un index. Mais attention, ne pas mettre des index partout car cela alourdit les tables. Il peut aussi y avoir des index à champs multiples

- La plupart du temps les requêtes SQL peuvent être optimisées, par exemple éviter le SELECT * . Améliorer les requêtes avec des jointures entre tables, etc...

ortolojf · 4 Juin 2015

Bonsoir frenchorn

Merci voir mon autre message pour la mise au point souhaitable de query_cache_size, query_cache_limit et query_cache_min_res_unit.

J'y indique tous les paramètres et résultats des deux scripts.

Cette après-midi j'ai ramené query_cache_min_res_unit de 4K à 2K.

Mais j'ai lu ce soir sur le net que celà pouvait fragmenter le cache... ;(

Si les performances sont moins bonnes demain matin, je testerai l'augmentation de query_cache_size de 32M à 48M, et remise à 4K de cache_min_res_unit.

Quant à mes requêtes MySQL, elles sont peaufinées au quart de poil, avec des index sur une ou plusieurs colonnes.

J'ai même un cache MySQL "maison", qui mémorise quotidiennement lors du premier accès dans des fichiers temporaires ascii, les requêtes lourdes ( résultats passés des chevaux ).

Merci beaucoup de ton aide.

Respectueusement;

Julia41 · 18 Juin 2015

Bonjour ortolojf, je pense qu'il y a pire que l'optimisation, il y a la suroptimisation. La désactivation du query_cache est une mauvaise idée, je pense que j'ai vu des améliorations sur moins d'1% des cas, mais tu peux tester.
Pour ton myisam_use_mmap, n'y touche pas, par défaut, c'est très bien.

Vu que tu as l'air parti pour t'amuser avec l'optimisation de ton serveur SQL, tu dois avant créer un protocole pour voir s'il y a du mieux, ou non.
Par exemple, après un restart de MySQL (qui vide donc les caches), il faut laisser tourner MySQL une à deux minutes. Et aussi, si tu benchmarks une page précise, la charger 2/3 fois histoire que le query_cache tape dedans.

Si tu as suivi toutes les recommandations de tuning-primer et mysqltuner (je préfère tuning-primer), normalement tu n'as pas grand chose à faire par la suite.

En suggestion, je te conseillerais toutefois de passer tes tables de MyISAM à InnoDB pour des tests (un ALTER sur 500Mo prends pas mal de temps toutefois, j'ignore tes libertés pour tester), en configurant proprement l'innodb buffer pool, et en activant le "one file per table" (j'ai un trou d'orthographe exacte pour ces variables).

"Ma version de MySQL est : 5.5 je crois )." => Tu pourrais essayer de passer sur MySQL 5.6, qui offre un bon gain de performance.

Ces dernières années, les grosses améliorations de MySQL ont été porté sur le moteur InnoDB, je pense que pour tes 500Mo de DATA, ça pourrait valoir le coup.

ortolojf · 18 Juin 2015

Bonjour Julia

Voici le résultat de mon tuning-primer.sh ce matin.

Pour le tuning, j'ai emprunté sur le net à des exemples de même configuration que la mienne ( RAM 8Go, autant de read que de write ).

Mais... Hier et avant-hier, j'ai éliminé tous les SELECT ... JOIN, ( remplacés par des SELECT successifs ), et affiné mes requêtes trop imprécises.

Pour une page ancienne qui se charge pour la première fois, je n'ai plus que 2,45 secondes ( au lieu de 4 secondes et des poussières ). Une page déjà chargée met environ 0,4 seconde côté serveur ( dixit Speeed Insigth ).

Ceci grâce à mon cache '"software", quant au cache "query_cache" de MySQL, il fonctionne je l'ai remis à 4K

Merci pour ton aide.

Respectueusement.

Code:

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

MySQL Version 5.5.43-0+deb7u1-log x86_64

Uptime = 2 days 22 hrs 50 min 22 sec
Avg. qps = 28
Total Questions = 7248855
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.5/en/server-system-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 = 2.000000 sec.
You have 21 out of 7248876 that take longer than 2.000000 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.5/en/point-in-time-recovery.html

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

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

INNODB STATUS
Current InnoDB index space = 16 K
Current InnoDB data space = 48 K
Current InnoDB buffer pool free = 95 %
Current innodb_buffer_pool_size = 100 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 : 894 M
Configured Max Per-thread Buffers : 1.20 G
Configured Max Global Buffers : 636 M
Configured Max Memory Limit : 1.82 G
Physical Memory : 8.00 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 137 M
Current key_buffer_size = 500 M
Key cache miss rate is 1 : 592
Key buffer free ratio = 66 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 20 M
Current query_cache_used = 12 M
Current query_cache_limit = 20 M
Current Query cache Memory fill ratio = 61.20 %
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 = 2 M
Current read_rnd_buffer_size = 8 M
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 = 2110 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_open_cache = 1000 tables
Current table_definition_cache = 400 tables
You have a total of 96 tables
You have 143 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 50 M
Current tmp_table_size = 50 M
Of 11566 temp tables, 7% were created on disk
Created disk tmp tables ratio seems fine

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

TABLE LOCKING
Current Lock Wait ratio = 1 : 10391
Your table locking seems to be fine