J'étudie pour devenir DBA en ce moment parce que j'ai une énorme base de données en direct très sensible que je gère. Voici les statistiques système actuelles de mon serveur de base de données dédié:
MySQL 5.5.23
top - 18:40:27 jusqu'à 14 jours, 4:43, 1 utilisateur, moyenne de charge: 19.72, 22.62, 24.04
Tâches: 183 au total, 3 en cours d'exécution, 180 en sommeil, 0 arrêté, 0 zombie
CPU (s): 69,9% us, 0,4% sy, 0,0% ni, 29,2% id, 0,0% wa, 0,1% hi, 0,4% si, 0,0% st
Mem: 24685224k total, 20172096k utilisé, 4513128k gratuit, 343420k tampons
Swap: 2007284k au total, 0k utilisé, 2007284k gratuit, 729004k mis en cache
UTILISATEUR PID PR NI VIRT RES SHR S% CPU% MEM TIME + COMMAND
5446 mysql 15 0 18.4g 17g 6176 R 765.8 76.2 114437: 38 mysqld
J'utilise actuellement 43 Go de cette tranche FusionIO de 50 Go. MySQL fait en moyenne environ 700 QPS et 75 à 90% d'utilisation du processeur. Voici mon fichier my.cnf:
[mysqld]
user=mysql
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
#innodb
#innodb_log_file_size = 256M
#innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout=50
innodb_file_per_table
innodb_buffer_pool_size=16G
innodb_buffer_pool_instances=4
#eliminating double buffering
innodb_flush_method = O_DIRECT
flush_time=86400
skip-name-resolve
query_cache_limit=4M
query_cache_size=256M
sort_buffer_size=8M
read_rnd_buffer_size=1M
max_connections=5000
interactive_timeout=60
wait_timeout=300
connect_timeout=30
thread_cache_size=32
key_buffer=124M
tmp_table_size=4096M
max_heap_table_size=256M
join_buffer=16M
max_connect_errors=2000
table_cache=2048
thread_concurrency=12
long_query_time=5
log-slow-queries=/var/log/mysql-slow.log
#table_definition_cache=384
max_allowed_packet=1024M
#server-id=20
#log-bin=mysql-bin
#expire_logs_days=10
event_scheduler=ON
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
pouvez-vous recommander des modifications de configuration que je devrais apporter à MySQL ou CentOS qui peuvent réduire considérablement l'utilisation de mon processeur? Ou d'ailleurs d'autres améliorations de ressources?
Vous devez déclencher deux choses
J'en ai discuté au fil des ans. Veuillez consulter certains de mes messages précédents sur la manière d'inciter InnoDB à engager plus d'activité CPU/Core.
May 26, 2011
: À propos des performances des bases de données monothread et multithreadSep 12, 2011
: Possible de faire en sorte que MySQL utilise plusieurs cœurs?Sep 20, 2011
: Multi-cœurs et performances MySQLApr 26, 2012
: Les performances du processeur sont-elles pertinentes pour un serveur de base de données?Essaie !!!
Votre dernier commentaire
Hé Rolando, j'ai ajouté read_io et write_io à 8 heures et j'ai lu vos autres publications, mais cela ne semble pas réduire l'utilisation du processeur. J'ai même laissé tomber les 4 instances de pool de tampons à 1 dans l'espoir qu'il aurait de meilleures performances, mais toujours pas. Avez-vous d'autres suggestions que je pourrais implémenter pour réduire l'utilisation du processeur?
Je suggérerais d'augmenter innodb_buffer_pool_instances à 8 pour correspondre au nombre de cœurs. La documentation MySQL suggère 1 G par instance de pool de mémoire tampon. Ensuite, vous monteriez à 16 (puisque vous avez innodb_buffer_pool_size à 16G). Essayez d'abord 8, puis 16.
Même avec cela, j'ai quelques nouvelles assez pénibles: Voici un Communiqué de presse de FusionIO d'il y a 2 ans . Le paragraphe 2 dit:
Le livre blanc de StatSoft a conclu que Fusion ioDrives augmentait considérablement les performances d'E/S dans la suite de produits et solutions d'analyse STATISTICA, augmentant considérablement l'utilisation et l'efficacité du processeur. Avec ioMemory, StatSoft a atteint des performances de données de 300 et 500 pour cent et des améliorations de réduction de latence par rapport au stockage sur disque hérité. Avec l'augmentation des performances d'E/S permises par les Fusion ioDrives, l'utilisation du processeur est passée à 90% dans les tests de grands ensembles de données, contre 32% d'utilisation du processeur observée avec la technologie basée sur disque.
Si vous utilisiez RAID 10 SAS ou même des SSD pour /var/lib/mysql
, InnoDB aurait sa journée avec les CPU. Cependant, d'après l'apparence de ce communiqué de presse, InnoDB est en concurrence avec FusionIO pour l'utilisation du CPU.
Découvrez les IOP pour le disque FusionIO et définissez innodb_io_capacity sur ce nombre. La valeur par défaut pour innodb_io_capacity est 200. Si les IOP sont supérieurs à 200, veuillez la définir. Si les IOP sont dans les années 1000, alors InnoDB a une chance d'être sur un pied d'égalité avec le FusionIO.
Essaie !!!
La première chose que je vérifierais est de savoir quelles requêtes sont exécutées à ces moments occupés - il peut s'agir d'un problème de conception de requête plutôt que d'un problème de configuration du matériel ou de la base de données. Par exemple, sans les bons index ou avec des requêtes écrites de sorte que le planificateur de requêtes ne puisse pas les utiliser, vous constaterez peut-être que beaucoup de temps est consacré à l'analyse des structures de table ou d'index en mémoire, ce qui mordillerait les ressources du processeur.
J'ai trouvé que si les tables deviennent trop grandes la charge du serveur peut augmenter considérablement et l'utilisation du CPU monter en flèche.