Około 4 miesiące temu przeprowadziliśmy migrację z MS SQL Server do MySQL 5.5 . Od tego czasu napotykamy problem raz na mniej więcej 25 dni, odkąd w CentOS zabrakło pamięci iw rezultacie zabija MySQL. MySQL Safe ponownie uruchamia mysql, więc baza danych jest całkowicie wyłączona na minutę lub dwie, ale możemy stracić wydajność i utratę łączności przez wiele godzin, zanim CentOS zabije wątek mysqld.
Zwykle widzimy problemy od 1:00 do 5:00 , ale nigdy w ciągu dnia, gdy ruch jest największy, co jest naprawdę zaskakujące w tej sytuacji. Pomimo normalnych problemów z łącznością i wydajnością od 1 do 5 rano, serwer mysql zazwyczaj ginie około 4 rano lub 5 rano, mniej więcej w tym samym czasie, w którym działa mysqldump.
Myśleliśmy, że mysqldumpmoże być sprawcą. Jednak zaczyna się o 4 rano codziennie, ale widzimy problemy już o 1 rano w niektóre noce. Działa również mysqldumpz --optprzełącznikiem, więc nie powinno buforować dużej ilości danych podczas procesu zrzutu.
Rozważaliśmy również używaną przez nas aplikację do tworzenia kopii zapasowych, która pobiera pliki zrzutu i tworzy kopię zapasową na taśmie. Zmieniliśmy czas działania na 6 rano i problem pozostał bez zmian.
Mamy kilka zadań, które są uruchamiane okresowo przez całą noc, ale żadne z nich nie wymaga dużych nakładów i nie zajmuje dużo czasu.
Oto kilka statystyk dotyczących tego, nad czym pracujemy i bieżących wpisów w my.cnfpliku. Będziemy wdzięczni za wszelką pomoc lub sugestie dotyczące rzeczy, które możemy wypróbować.
STATYSTYKI SERWERA :
- Procesor Intel (R) Xeon (E) E5530 @ 2,40 GHz
- Rdzenie procesora: 4
- Pamięć: 12293480 (12 koncertów)
OS :
- CentOS 5.5
- Linux 2.6.18-274.12.1.el5 # 1 SMP Wt 29 listopada 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
Odpowiedzi:
Powinieneś sprawdzić dziennik błędów MySQL
Sprawdź, czy ta wartość jest taka sama jak w przypadku
ulimit -aotwartych plików:źródło
Twoja konfiguracja jest wadliwa.
Tutaj użyj tego narzędzia . Mówi ci, ile pamięci RAM potrzebujesz na niestandardową konfigurację?
Twoja obecna pamięć RAM, jak wspomniałeś, jest
12GBpotrzebna31.6GBdo 500 aktywnych połączeń MySQL.źródło