Seit Update von errata302 oom-killer mysqldump

UCS - Univention Corporate Server
#1

Hallo allerseits,
4.0-3 errata313, mysql-server-5.5 5.5.44-0.15.201508042121, zarafa4ucs 7.1.3000-8.93.201504241611

Ich führe täglich ein mysqldump aus, um die Datenbank von Zarafa zu sichern.

mysqldump --skip-opt --log-error=/var/log/mysqldump.error --single-transaction --user=zarafaDbUser --password=MeinPasswort zarafa > /data/mysql/Backup/zarafa.sql

Seit Donnerstag, an dem ich das letzte Update des UCS von 4.0-3 errata302 durchgeführt habe, wird der mysqldump vom oom-killer abgebrochen.

Sep 10 21:12:01 ucs kernel: [1673444.027926] python2.7 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Sep 10 21:12:01 ucs kernel: [1673444.027926] python2.7 cpuset=/ mems_allowed=0 Sep 10 21:12:01 ucs kernel: [1673444.060017] CPU: 1 PID: 22064 Comm: python2.7 Tainted: G OE 3.16.0-ucs135-amd64 #1 Debian 3.16.7-c Sep 10 21:12:01 ucs kernel: [1673444.061818] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 Sep 10 21:12:01 ucs kernel: [1673444.061820] 0000000000000000 0000000000000000 ffffffff81548353 ffff88040a8fa050 Sep 10 21:12:01 ucs kernel: [1673444.061823] ffffffff81546037 0000000000000007 ffffffff810ca5a0 0000000000000000 Sep 10 21:12:01 ucs kernel: [1673444.061825] ffffffff810de34f ffff8800a232fa28 ffffffff8154cd4e 0000000000000200 Sep 10 21:12:01 ucs kernel: [1673444.061827] Call Trace: Sep 10 21:12:01 ucs kernel: [1673444.104029] [<ffffffff81548353>] ? dump_stack+0x41/0x51 ... 0 21:12:01 ucs kernel: [1673444.151003] [23188] 0 23188 5763980 3637970 11261 2115152 0 mysqldump Sep 10 21:12:01 ucs kernel: [1673444.151006] [23465] 115 23465 57397 10270 113 12004 0 /usr/sbin/amavi Sep 10 21:12:01 ucs kernel: [1673444.151008] [23634] 33 23634 66976 2896 117 1161 0 apache2 Sep 10 21:12:01 ucs kernel: [1673444.151013] [23650] 100 23650 24914 620 50 0 -1000 smtpd Sep 10 21:12:01 ucs kernel: [1673444.151015] [23651] 100 23651 10503 159 25 0 -1000 proxymap Sep 10 21:12:01 ucs kernel: [1673444.151018] [23652] 100 23652 12482 448 29 0 -1000 trivial-rewrite Sep 10 21:12:01 ucs kernel: [1673444.151021] [23653] 100 23653 12515 464 29 0 -1000 cleanup Sep 10 21:12:01 ucs kernel: [1673444.151023] [23654] 100 23654 22928 300 47 0 -1000 smtp Sep 10 21:12:01 ucs kernel: [1673444.151025] Out of memory: Kill process 23188 (mysqldump) score 829 or sacrifice child Sep 10 21:12:01 ucs kernel: [1673444.151028] Killed process 23188 (mysqldump) total-vm:23055920kB, anon-rss:14551760kB, file-rss:120kB
Ich denke, da hat sich ein Bug eingeschlichen.

Wäre schön, wenn sich jemand von UCS dazu melden würden.

Gruß,
Peter

#2

Hallo Peter,

Ich kann den Fall bei mir nicht reproduzieren, ich vermute aufgrund der Logdatei aber dass hier einfach die DB zu groß geworden ist für die aktuelle Konfiguration/Maschine geworden.

Bitte prüfen Sie (und posten sie gegebenenfalls) die DBDump Größe, wieviel RAM in der Maschine steckt und was in die my.cnf configuriert ist.

Es gibt zusätzlich die Möglichkeit die Optionen von mysqldump zu ändern (Siehe mysqldump doku unten). z.B: “To disable extended inserts and memory buffering, use --opt --skip-extended-insert --skip-quick”

Mit freundlichem Gruß,
Daniel Orrego

#3

Hm, es scheint wieder zu laufen. Heute und gestern Nacht ist das Dump erfolgreich erzeugt worden.
Der UCS ist virtualisiert, hat 16GB RAM und 8 CPU Kerne, MySQL Datenbankgröße 30GB, Dumpgröße 25GB. Die my.cnf sieht wie folgt aus:

# egrep -v "^s*$|^#" /etc/mysql/my.cnf [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking bind-address = 127.0.0.1 key_buffer = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover = BACKUP query_cache_limit = 1M query_cache_size = 16M expire_logs_days = 10 max_binlog_size = 100M [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/
Ich werde das weiter beobachten und mich erneut melden, wenn der OOM Killer wieder zuschlägt.

#4

Hi Peter,

Ich empfehle dir die --quick Option zu berücksichtigen (um große Tabelle nicht komplett im RAM zu laden). Das kannst du noch versuchen wenn du wieder in Schwierigkeiten läufst.

Gruß,
Daniel

Mastodon