MySQL est tué par OS tous les 25 jours environ


9

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

Configurez le journal des erreurs dev.mysql.com/doc/refman/5.5/en/error-log.html et vérifiez si quelque chose est enregistré lorsque le problème se produit

J'ai utilisé ce site omh.cc/mycnf et j'ai déterminé que le problème est probablement lié à la configuration elle-même. Je vais ajuster beaucoup de pools de connexions liés à myisam et voir si cela aide à la consommation de mémoire.

2
CentOS 5.5 n'est pas à jour. 5.8 est (si vous vous souciez de la sécurité du système d'exploitation)
Nils

1
La solution serait intéressante. Pouvez-vous l'afficher comme réponse à votre propre question?
Nils

article en double dans le fil reddit où il a été résolu. il a également été publié sur les forums de MySQL
Mark McKinstry

Réponses:


2
  1. Vous devriez vérifier le journal des erreurs MySQL

  2. Vérifiez que cette valeur est identique à celle ulimit -ades fichiers ouverts:

    int my.cnf 
    [mysqld_safe]
    open-files-limit = 8192
    

0

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 besoin 31.6GBde 500 connexions MySQL actives.

Session variables
max_allowed_packet 16.0 MB
sort_buffer_size 8.0 MB
net_buffer_length 16.0 KB
thread_stack 192.0 KB
read_rnd_buffer_size 16.0 MB
read_buffer_size 2.0 MBSession variables
max_allowed_packet 16.0 MB
sort_buffer_size 8.0 MB
net_buffer_length 16.0 KB
thread_stack 192.0 KB
read_rnd_buffer_size 16.0 MB
read_buffer_size 2.0 MB
join_buffer_size 8.0 MB
Total (per session)50.2 MB
Global variables
innodb_log_buffer_size 1.0 MB
query_cache_size 64.0 MB
innodb_buffer_pool_size 7.0 GB
innodb_additional_mem_pool_size 16.0 MB
key_buffer_size 32.0 MB
Total 7.1 GB
Total memory needed (for 500 connections): 31.6 GB
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.