Hace aproximadamente 4 meses migramos de MS SQL Server a MySQL 5.5 . Desde entonces, hemos experimentado un problema una vez aproximadamente cada 25 días desde que CentOS se queda sin memoria y, como resultado, mata a MySQL. MySQL safe reinicia mysql, por lo que la base de datos está completamente inactiva durante un minuto o dos, pero podemos sufrir pérdidas de rendimiento y conectividad durante horas antes de que CentOS mate el hilo mysqld.
Por lo general, vemos problemas de 1 a.m. a 5 a.m. , pero nunca durante el día cuando el tráfico es más alto, lo que es realmente desconcertante sobre esta situación. A pesar de que normalmente se ven problemas de conectividad y rendimiento de 1 a.m. a 5 a.m., el servidor mysql generalmente se mata alrededor de las 4 a.m. o las 5 a.m., aproximadamente al mismo tiempo que se ejecuta mysqldump.
Pensamos que mysqldumppudo haber sido el culpable. Sin embargo, comienza a las 4 de la mañana todos los días, pero vemos problemas desde la 1 de la mañana en algunas noches. También se mysqldumpestá ejecutando con el --optconmutador, por lo que no debería almacenar muchos datos durante el proceso de volcado.
También consideramos la aplicación de respaldo que estamos usando que obtiene los archivos de volcado y los respalda en cinta. Cambiamos el tiempo que corre a las 6 AM y el problema no cambió.
Tenemos varios trabajos que se ejecutan periódicamente durante la noche, pero ninguno requiere muchos recursos y no lleva mucho tiempo ejecutarlos.
Aquí hay algunas estadísticas para lo que estamos trabajando y las entradas actuales en el my.cnfarchivo. Cualquier ayuda o sugerencia para cosas que podamos probar sería muy apreciada.
ESTADÍSTICAS DEL SERVIDOR :
- Intel (R) Xeon (R) CPU E5530 @ 2.40GHz
- núcleos de la CPU: 4
- Memoria: 12293480 (12 conciertos)
OS :
- CentOS 5.5
- Linux 2.6.18-274.12.1.el5 # 1 SMP martes 29 de noviembre 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
Respuestas:
Debe consultar el registro de errores de MySQL
Verifique que este valor sea el mismo que
ulimit -ael de los archivos abiertos:fuente
Su configuración tiene errores.
Aquí usa esta herramienta . ¿Te dice cuánta memoria RAM necesitas para tu configuración personalizada?
Su RAM actual como mencionó es
12GBpero necesita31.6GB500 conexiones MySQL activas.fuente