MySQL, her 25 günde bir işletim sistemi tarafından öldürülür


9

4 Hakkında ay önce göç MS SQL Server için MySQL 5.5 . O zamandan beri CentOS'un hafızasının bittiği ve sonuç olarak MySQL'i öldürdüğü günden bu yana yaklaşık 25 gündür bir sorun yaşıyoruz. MySQL güvenli mysql'i yeniden başlatır, böylece veritabanı sadece bir veya iki dakika boyunca tamamen kapanır, ancak CentOS mysqld iş parçacığını öldürmeden önce saatlerce performans ve bağlantı kayıplarına maruz kalabiliriz.

Genellikle sabah 1'den akşam 5'e kadar olan sorunları görürüz , ancak asla trafiğin en yüksek olduğu günlerde bu durumla ilgili gerçekten şaşırtıcı olan şeydir. Normalde bağlanabilirlik ve performans sorunlarını sabah 1'den akşam 5'e kadar görmesine rağmen, mysql sunucusu genellikle sabah 4 civarında veya akşam 5 civarında öldürülür, aynı zamanda mysqldump çalışır.

mysqldumpSuçlu olabileceğini düşündük . Ancak günlük 4 am başlar, ancak bazı geceleri 01:00 gibi sorunları görüyoruz. Ayrıca anahtarla mysqldumpçalışıyor --opt, bu nedenle döküm işlemi sırasında çok fazla veri arabelleğe almamalıdır.

Ayrıca, kullandığımız döküm dosyalarını alan ve teybe yedekleyen yedekleme uygulamasını da dikkate aldık. Biz 6 am çalıştığı zaman değişti ve sorun değişmedi.

Gece boyunca periyodik olarak çalışan birkaç işimiz var, ancak hiçbiri çok yoğun kaynak gerektirmiyor ve çalıştırılması çok uzun sürmüyor.

Aşağıda, üzerinde çalıştığımız işlemlere ve my.cnfdosyadaki geçerli girişlere ilişkin bazı istatistikler bulunmaktadır . Deneyebileceğimiz şeyler için herhangi bir yardım veya öneri çok takdir edilecektir.

SUNUCU İSTATİSTİKLERİ :

  • Intel (R) Xeon (R) CPU E5530 @ 2,40 GHz
  • cpu çekirdekleri: 4
  • Bellek: 12293480 (12 konser)

İşletim Sistemi :

  • CentOS 5.5
  • Linux 2.6.18-274.12.1.el5 # 1 SMP Sal 29 Kasım 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

Dev.mysql.com/doc/refman/5.5/tr/error-log.html hata günlüğünü yapılandırın ve sorun oluştuğunda bir şeyin kaydedilip kaydedilmediğini kontrol edin

Bu siteyi omh.cc/mycnf kullandım ve sorunun büyük olasılıkla yapılandırmanın kendisiyle ilgili olduğunu belirledim. Myisam ile ilgili bağlantı havuzlarının çoğunu ayarlayacağım ve bunun bellek tüketimine yardımcı olup olmadığını göreceğim.

2
CentOS 5.5 güncel değil. 5.8 (işletim sistemi güvenliğini önemsiyorsanız)
Nils

1
Çözüm ilginç olurdu. Kendi sorunuza cevap olarak gönderebilir misiniz?
Nils

çözüldüğü yerde reddit iş parçacığında yinelenen yayın . ayrıca MySQL'in forumlarında
Mark McKinstry

Yanıtlar:


2
  1. MySQL hata günlüğünü kontrol etmelisiniz

  2. Bu değerin ulimit -aaçık dosyalarla aynı olup olmadığını kontrol edin :

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

0

Yapılandırmanız hatalı.

İşte bu aracı kullanın . Özel yapılandırmanız için ne kadar bellek RAM'e ihtiyacınız olduğunu söyler?

Bahsettiğiniz gibi RAM'iniz 500 aktif MySQL bağlantısına 12GBihtiyacınız var 31.6GB.

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
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.