MySQL 每 25 天左右就會被作業系統殺死一次

MySQL 每 25 天左右就會被作業系統殺死一次

大約 4 個月前,我們從微軟SQL伺服器MySQL 5.5。從那時起,我們大約每 25 天就會遇到一次 CentOS 記憶體不足並導致 MySQL 終止的問題。 MySQL 安全地重新啟動 mysql,因此資料庫只會完全關閉一兩分鐘,但在 CentOS 殺死 mysqld 執行緒之前,我們可能會遭受效能和連線損失幾個小時。

我們通常會在凌晨 1 點到 5 點之間看到問題,但絕對不會在白天流量最高的時候進行,這才是這種情況真正令人困惑的地方。儘管通常會在凌晨 1 點到凌晨 5 點出現連線和效能問題,但 mysql 伺服器通常會在凌晨 4 點或 5 點左右被終止,大約在 mysqldump 運行的時間。

我們認為mysqldump可能是罪魁禍首。然而,它每天凌晨 4 點開始,但在某些晚上我們早在凌晨 1 點就發現了問題。也mysqldump與交換器一起運行--opt,因此在轉儲過程中不應緩衝大量資料。

我們還考慮了我們正在使用的備份應用程序,它獲取轉儲文件並將其備份到磁帶。我們將運行時間更改為早上 6 點,問題沒有改變。

我們有幾個作業會在整個晚上定期運行,但沒有一個作業是資源密集型的,並且運行起來根本不需要很長時間。

以下是我們正在處理的內容以及my.cnf文件中當前條目的一些統計資料。對於我們可以嘗試的任何幫助或建議,我們將不勝感激。

伺服器統計

  • 英特爾(R) 至強(R) CPU E5530 @ 2.40GHz
  • CPU核心數:4
  • 記憶體:12293480(12GB)

作業系統

  • CentOS 5.5
  • Linux 2.6.18-274.12.1.el5 #1 SMP 11 月 29 日星期二 13:37:46 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

我的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

答案1

  1. 你應該檢查 MySQL 錯誤日誌

  2. ulimit -a檢查該值是否與開啟的檔案相同:

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

答案2

你的配置有問題。

這裡用這個工具。它會告訴您自訂配置需要多少記憶體 RAM?

正如你所提到的,你目前的 RAM 是,12GB但你需要31.6GB500 個活躍的 MySQL 連線。

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

相關內容