MySQL ginie przez system operacyjny co około 25 dni


9

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

Skonfiguruj dziennik błędów dev.mysql.com/doc/refman/5.5/en/error-log.html i sprawdź, czy coś się zarejestrowało, gdy

Skorzystałem z tej strony omh.cc/mycnf i ustaliłem, że najprawdopodobniej problem dotyczy samej konfiguracji. Zamierzam dostosować wiele pul połączeń związanych z myisam i sprawdzić, czy to pomaga w zużyciu pamięci.

2
CentOS 5.5 nie jest aktualny. 5.8 to (jeśli zależy Ci na bezpieczeństwie systemu operacyjnego)
Nils,

1
Rozwiązanie byłoby interesujące. Czy możesz to opublikować jako odpowiedź na swoje pytanie?
Nils,

zduplikowany post w wątku reddit, w którym został rozwiązany. został również opublikowany na forach MySQL
Mark McKinstry

Odpowiedzi:


2
  1. Powinieneś sprawdzić dziennik błędów MySQL

  2. Sprawdź, czy ta wartość jest taka sama jak w przypadku ulimit -aotwartych plików:

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

0

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 12GBpotrzebna 31.6GBdo 500 aktywnych połączeń 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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.