MySQLは25日ごとにOSに殺されます


9

約4か月前に、MS SQL ServerからMySQL 5.5に移行しました。それ以来、CentOSがメモリを使い果たし、その結果MySQLが強制終了する約25日間に一度、問題が発生しています。MySQLはmysqlを安全に再起動するため、データベースは1〜2分だけ完全にダウンしますが、CentOSがmysqldスレッドを強制終了するまでに、パフォーマンスと接続の損失に数時間かかる可能性があります。

通常、午前1時から午前5時まで問題が発生しますが、日中はトラフィックが最も多いため、この状況では本当に困惑します。通常、午前1時から午前5時まで接続とパフォーマンスの問題が発生しますが、mysqldumpの実行とほぼ同時に、mysqlサーバーは午前4時または5時頃に強制終了されます。

mysqldump犯人かもしれないと思った。ただし、それは毎日午前4時に始まりますが、一部の夜には早くも午前1時に問題が発生します。またmysqldump--optスイッチで実行されているので、ダンププロセス中に大量のデータをバッファリングしないでください。

また、ダンプファイルを取得してテープにバックアップする、使用しているバックアップアプリについても検討しました。実行時間を午前6時に変更しましたが、問題は変わりませんでした。

夜間に定期的に実行されるジョブがいくつかありますが、リソースを大量に消費するジョブはなく、実行にそれほど時間がかかりません。

以下は、私たちが作業しているものとmy.cnfファイルの現在のエントリに関するいくつかの統計です。私たちが試すことができるものについての助けや提案があれば、とてもありがたいです。

サーバー統計

  • Intel(R)Xeon(R)CPU E5530 @ 2.40GHz
  • CPUコア:4
  • メモリ:12293480(12ギグ)

OS

  • CentOS 5.5
  • Linux 2.6.18-274.12.1.el5#1 SMP Tue Nov 29 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/en/error-log.htmlを設定し、問題が発生したときに何かが登録されているかどうかを確認します

私はこのサイトomh.cc/mycnfを使用して、問題は構成自体にある可能性が最も高いと判断しました。myisam関連の接続プールの多くを調整して、それがメモリ消費に役立つかどうかを確認します。

2
CentOS 5.5は最新ではありません。5.8は(OSセキュリティに関心がある場合)
Nils

1
解決策は興味深いでしょう。自分の質問への回答として投稿できますか?
ニルス

解決されたredditスレッドの投稿を複製します。それも掲載されましたMySQLのフォーラム
Mark McKinstry

回答:


2
  1. MySQLエラーログを確認する必要があります

  2. この値が同じであることを確認してください ulimit -aの開いているファイルます。

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

0

設定にバグがあります。

ここでこのツールを使用します。カスタム構成に必要なメモリRAMの量がわかりますか?

あなたが述べた現在のRAMは12GBですが31.6GB、500のアクティブな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
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.