Pour MySQL : myisam_use_mmap = 1 souhaitable ?

Discussion dans 'Développement d'un site Web ou d'une appli mobile' créé par ortolojf, 3 Juin 2015.

  1. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34
    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.
     
  2. frenchhorn
    frenchhorn WRInaute passionné
    Inscrit:
    8 Février 2007
    Messages:
    1 136
    J'aime reçus:
    3
    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...
     
  3. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34
    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.
     
  4. frenchhorn
    frenchhorn WRInaute passionné
    Inscrit:
    8 Février 2007
    Messages:
    1 136
    J'aime reçus:
    3
    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...
     
  5. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34
    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;
     
  6. Julia41
    Julia41 WRInaute passionné
    Inscrit:
    31 Août 2007
    Messages:
    1 774
    J'aime reçus:
    0
    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.
     
  7. ortolojf
    ortolojf WRInaute accro
    Inscrit:
    14 Août 2002
    Messages:
    3 596
    J'aime reçus:
    34
    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
    
    
     
Chargement...
Similar Threads - MySQL myisam_use_mmap souhaitable Forum Date
Mysql : Impact convertion champ numérique SMALLINT vers BIGINT Développement d'un site Web ou d'une appli mobile 23 Août 2021
Quel SGBDR autre que MySQL/MariaDB ? Administration d'un site Web 12 Janvier 2021
encodage texte sur requete mysql Demandes d'avis et de conseils sur vos sites 21 Octobre 2020
Requête MySql imbriquée Développement d'un site Web ou d'une appli mobile 8 Octobre 2020
Supprimer les doublons d'une table mysql Développement d'un site Web ou d'une appli mobile 16 Juin 2020
Mysql migration utf8->utf8mb4 Développement d'un site Web ou d'une appli mobile 17 Août 2019
recherche lettres dans mysql Développement d'un site Web ou d'une appli mobile 11 Juillet 2019
cache mysql maison Développement d'un site Web ou d'une appli mobile 18 Février 2019
Stocker dans des variables php les fonctions MySql Développement d'un site Web ou d'une appli mobile 2 Février 2019
message : [LEGACY][libmysqlclient] Please consider moving to stable and mysqlnd in Administration d'un site Web 8 Novembre 2018
Connexion à un serveur mysql distant Développement d'un site Web ou d'une appli mobile 21 Octobre 2018
Mysql, modifier des chaines avec différents caractères Administration d'un site Web 13 Septembre 2018
Fusionner deux champs sur la même table et même base de donnée Mysql Administration d'un site Web 12 Septembre 2018
Requête Mysql avec des string Développement d'un site Web ou d'une appli mobile 6 Février 2018
Surveiller les connexions à la base de données MySQL Développement d'un site Web ou d'une appli mobile 1 Février 2018
PHP : script pour mettre catalogue xml clickbank dans mysql Développement d'un site Web ou d'une appli mobile 6 Décembre 2017
Mise à jour MySql 5.1 vers 5.5 Administration d'un site Web 1 Juillet 2017
Problème avec un changement de version Mysql de 5.5 à 5.7 Développement d'un site Web ou d'une appli mobile 9 Juin 2017
Requete mysql Développement d'un site Web ou d'une appli mobile 30 Mai 2017
Problème requête mysql Développement d'un site Web ou d'une appli mobile 1 Mars 2017