Il y a environ 4 mois, nous avons migré de MS SQL Server vers MySQL 5.5 . Depuis lors, nous avons rencontré un problème une fois dans les 25 jours environ depuis que CentOS manque de mémoire et, par conséquent, il tue MySQL. MySQL safe redémarre mysql afin que la base de données ne soit complètement arrêtée qu'une minute ou deux, mais nous pouvons subir des pertes de performances et de connectivité pendant des heures avant que CentOS ne tue le thread mysqld.
Nous voyons généralement des problèmes de 1 h à 5 h , mais jamais pendant la journée lorsque le trafic est le plus élevé, ce qui est vraiment déroutant dans cette situation. Malgré des problèmes de connectivité et de performances de 1 h à 5 h, le serveur mysql est généralement tué vers 4 h ou 5 h, à peu près au même moment où mysqldump s'exécute.
Nous pensions mysqldumpque c'était peut-être le coupable. Cependant, cela commence à 4 h tous les jours, mais nous voyons des problèmes dès 1 h du matin certaines nuits. Fonctionne également mysqldumpavec le --optcommutateur, il ne devrait donc pas mettre en mémoire tampon beaucoup de données pendant le processus de vidage.
Nous avons également pris en compte l'application de sauvegarde que nous utilisons qui récupère les fichiers de vidage et les sauvegarde sur bande. Nous avons changé l'heure à 6 heures du matin et le problème est resté inchangé.
Nous avons plusieurs travaux qui s'exécutent périodiquement tout au long de la nuit, mais aucun n'est très gourmand en ressources et ne prend pas très longtemps à s'exécuter.
Voici quelques statistiques sur ce avec quoi nous travaillons et les entrées actuelles dans le my.cnffichier. Toute aide ou suggestion de choses que nous pourrions essayer serait très appréciée.
STATS DU SERVEUR :
- Processeur Intel (R) Xeon (R) E5530 à 2,40 GHz
- cœurs de processeur: 4
- Mémoire: 12293480 (12 concerts)
OS :
- CentOS 5.5
- Linux 2.6.18-274.12.1.el5 # 1 SMP mar 29 nov 13:37:46 EST 2011 x86_64 x86_64 x86_64 GNU / Linux
MY.CNF:
[client]
port = 3306
socket = /var/lib/mysql/mysql.sock
[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-name-resolve
ssl-ca=<file location>
ssl-cert=<file location>
ssl-key=<file location>
back_log = 50
max_connections = 500
table_open_cache = 2048
table_definition_cache = 9000
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 130
thread_concurrency = 16
query_cache_size = 64M
query_cache_limit = 1M
ft_min_word_len = 4
default-storage-engine=INNODB
thread_stack = 192K
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
log-bin=/log/mysql/mysql-bin
expire_logs_days=7
binlog_format=mixed
key_buffer_size = 32M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size = 7G
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 70
innodb_lock_wait_timeout = 120
[mysql]
no-auto-rehash
[mysqld_safe]
open-files-limit = 8192
Réponses:
Vous devriez vérifier le journal des erreurs MySQL
Vérifiez que cette valeur est identique à celle
ulimit -ades fichiers ouverts:la source
Votre configuration est boguée.
Ici, utilisez cet outil . Il vous indique la quantité de mémoire RAM dont vous avez besoin pour votre configuration personnalisée?
Votre RAM actuelle, comme vous l'avez mentionné, est
12GBnécessaire, mais vous avez besoin31.6GBde 500 connexions MySQL actives.la source