MySQL wird etwa alle 25 Tage vom Betriebssystem getötet

Vor ungefähr 4 Monaten haben wir von MS SQL Server auf MySQL 5.5 migriert . Seitdem ist seit ungefähr 25 Tagen ein Problem aufgetreten, bei dem CentOS nicht mehr über genügend Arbeitsspeicher verfügt und MySQL dadurch zerstört wird. MySQL safe startet mysql neu, sodass die Datenbank nur ein oder zwei Minuten lang vollständig ausgefallen ist. Wir können jedoch stundenlang Leistungs- und Konnektivitätsverluste erleiden, bevor CentOS den mysqld-Thread beendet.

Wir sehen normalerweise Probleme von 1 Uhr morgens bis 5 Uhr morgens , aber niemals tagsüber, wenn der Verkehr am höchsten ist, was an dieser Situation wirklich verwirrend ist. Obwohl normalerweise von 1 bis 5 Uhr Konnektivitäts- und Leistungsprobleme auftreten, wird der MySQL-Server normalerweise um 4 Uhr morgens oder 5 Uhr morgens getötet, ungefähr zur gleichen Zeit, zu der MySQLldump ausgeführt wird.

Wir dachten, mysqldumpes könnte der Schuldige gewesen sein. Es beginnt jedoch täglich um 4 Uhr morgens, aber an manchen Abenden treten bereits um 1 Uhr morgens Probleme auf. Wird auch mysqldumpmit dem --optSwitch ausgeführt, sodass während des Dump-Vorgangs nicht viele Daten gepuffert werden sollten.

Wir haben auch die von uns verwendete Backup-App in Betracht gezogen, mit der die Dump-Dateien abgerufen und auf Band gesichert werden. Wir haben die Uhrzeit auf 6 Uhr geändert und das Problem blieb unverändert.

Wir haben mehrere Jobs, die die ganze Nacht über regelmäßig ausgeführt werden, aber keiner ist sehr ressourcenintensiv und dauert nicht lange.

Hier sind einige Statistiken für das, womit wir arbeiten, und die aktuellen Einträge in der my.cnfDatei. Jede Hilfe oder Anregung für Dinge, die wir versuchen können, wäre sehr dankbar.

SERVER STATS :

Intel (R) Xeon (R) CPU E5530 bei 2,40 GHz
CPU-Kerne: 4
Speicher: 12293480 (12 Gigs)

Betriebssystem :

CentOS 5.5
Linux 2.6.18-274.12.1.el5 # 1 SMP Di 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

mysql memory centos

— Bahamat
quelle

Konfigurieren Sie das Fehlerprotokoll dev.mysql.com/doc/refman/5.5/en/error-log.html und überprüfen Sie, ob etwas registriert ist, wenn das Problem

Ich habe diese Site omh.cc/mycnf verwendet und festgestellt, dass das Problem höchstwahrscheinlich bei der Konfiguration selbst liegt. Ich werde viele der Myisam-bezogenen Verbindungspools anpassen und prüfen, ob dies beim Speicherverbrauch hilft.

CentOS 5.5 ist nicht aktuell. 5.8 ist (wenn Sie sich um die Sicherheit des Betriebssystems kümmern)

— Nils

Die Lösung wäre interessant. Können Sie es als Antwort auf Ihre eigene Frage posten?

— Nils

doppelter Beitrag im reddit-Thread, in dem er gelöst wurde. Es wurde auch in den Foren

— Mark McKinstry

Sie sollten das MySQL-Fehlerprotokoll überprüfen
Überprüfen Sie, ob dieser Wert mit den ulimit -ageöffneten Dateien übereinstimmt :
```
int my.cnf 
[mysqld_safe]
open-files-limit = 8192
```

— Bill Xie
quelle

Ihre Konfiguration ist fehlerhaft.

Verwenden Sie hier dieses Tool . Hier erfahren Sie, wie viel Arbeitsspeicher Sie für Ihre benutzerdefinierte Konfiguration benötigen.

Wie Sie bereits erwähnt haben 12GB, benötigen Sie derzeit 31.6GB500 aktive MySQL-Verbindungen.

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

— Ahmad Awais
quelle