Mysql tunning
De BlaxWiki
Révision datée du 28 mars 2012 à 17:24 par Admin (discussion | contributions) (Page créée avec « <pre> key buffer sous utilisé => on le diminue de moitié (passage à 128M) Query cache prunes per day: 1628162 => on double le query_cache_size (passage à 256M) Tables... »)
key buffer sous utilisé => on le diminue de moitié (passage à 128M)
Query cache prunes per day: 1628162 => on double le query_cache_size (passage à 256M)
Tables fragmentées : need optimize tables;
max conns atteint => phenomène a priori, rare : les graphes indiquent une moyenne à 23 avec des pics aux alentours de 100
passage de slow_query time à 1 => permettra d'avoir plus d'infos sur les requetes "lentes"
Temporary tables created on disk: 45% => augmentation tmp_table_size et max_heap_table_size (passage à 128M)
open tables 2048/2048 => passage de table_cache et open_files à 4096 (actuellement 2048) et ajout d'un ulimit -n 4096 dans le init.d de mysqld
buffer_pool_size : trop bas mais pas assez de RAM disponible (6GB+ de data InnoDB donc préco de passage à 8GB pour anticiper et être tranquille)
=====================
Utilisation du Query cache reste faible => augmentation de la taille max d'une query en cache (4M -> 6M)
Upgrade RAM => augmentation innodb buffer pool size à 8G
======================
J+7 (en fait J+15)
Diminution timeout pour éviter les connexion en sleep : passage de wait et interactive_timeout à 45s (max conn atteint en prod)
Augmentation de innodb_buffer_pool_size à 10 GB (déjà plein et evite double cache par l'OS)
Augmentation de join-buffer_size à 4M
top score des slow queries : SELECT * FROM `atome`.`JobOfferSearchView` WHERE (MODIFICATIONDATE >= {ts '2011-06-12 01:40:01.281'} OR MODIFICATIONDATE IS NULL)\G (87% du temps de
toutes les slow queries)