Re: Sperrt Mysqldump die DB?

Axel Schwenke writes:

Hallo Axel!

Welche Kommandozeilenoptionen für mysqldump benutzt du? Sind da auch
MyISAM-Tabellen oder ist das alles InnoDB?


$shellOutput = shell_exec('mysqldump -u root -pxxx --default-character-set=utf8
--databases '.$row->Database.' > /Data/backup/mysqldump/'.$row->Database.'.sql');

Das meiste sind MyISAM, 11934 Stück.

monster:/Database/mysql# find * . | grep .frm | wc -l
11934

Innodbs sind:

monster:/Database/mysql# find * . | grep ibd | wc -l
1970

-rw-rw---- 1 mysql mysql 2,1G 4. Nov 10:06 ibdata1
-rw-rw---- 1 mysql mysql 5,0M 4. Nov 10:06 ib_logfile0
-rw-rw---- 1 mysql mysql 5,0M 4. Nov 10:06 ib_logfile1

Hast du schon über --lock-tables, --lock-all-tables und
--single-transaction nachgelesen? Nein? Dann hol das nach. Hier:

http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html#option_mysqldump_lock-
all-tables

OK das ziehe ich mir heute rein, komisch ist nur dass es vorher ging und ich
nichts geändert habe.

Nov 4 03:42:15 monster mysqld[3344]: InnoDB: Warning: a long semaphore wait:
Nov 4 03:42:20 monster mysqld[3344]: --Thread 1200695632 has waited at btr0cur.c line 366 for 242.00 seconds the semaphore:
Nov 4 03:42:20 monster mysqld[3344]: S-lock on RW-latch at 0x359f838 created in file dict0dict.c line 3706
Nov 4 03:42:20 monster mysqld[3344]: number of readers 1, waiters flag 0
Nov 4 03:42:20 monster mysqld[3344]: Last time read locked in file btr0cur.c line 366
Nov 4 03:42:20 monster mysqld[3344]: Last time write locked in file btr0cur.c line 359
Nov 4 03:42:20 monster mysqld[3344]: wait has ended

Das ist das Latch für das Data Dictionary. Falls da irgendwo ein FLUSH
TABLES beteiligt ist, kann das die Situation erklären.

Naja der Webserver läuft durch und natürlich martern die Typo3's die DB wärend
des Backups her.

Nov 4 05:28:08 monster mysqld[3344]: Total memory allocated 36548226; in
additional pool allocated 1048576
Nov 4 05:28:08 monster mysqld[3344]: Buffer pool size 512
Nov 4 05:28:08 monster mysqld[3344]: Free buffers 0
Nov 4 05:28:08 monster mysqld[3344]: Database pages 510

Dein MySQL (zumindest InnoDB) läuft schaumgebremst. Wie es aussieht,
hast du innodb_buffer_pool_size nicht gesetzt und es läuft mit dem
Default von 8MB. Das ist für reale Load natürlich total ungeeignet.

Wärend des Tages läuft die DB gut, auch der Cache ist voll und wird verwendet.
Sehe ich im Mysqladmin bei der Querycache Hit Rate, die liegt durchgehend bei
100%. Die Buffersize hatte ich mal gesetzt hat aber nichts gebracht.?

#innodb_buffer__pool_size = 128M
#innodb_log_buffer_size = 8M
#innodb_log_file_size = 64M



monster:~# free
total used free shared buffers cached
Mem: 8168364 7810232 358132 0 157272 2448260
-/+ buffers/cache: 5204700 2963664
Swap: 2097144 92 2097052

Hmm. 5G RAM und 2G Swap in Benutzung. Wie teilt sich das auf MySQL
und den Apachen auf? Sind da noch andere Prozesse, die fett Speicher
brauchen?

Nur die DB und 256 Apache laufen, wenn ich mit SSH reinkomme brauche ich nur
den Apachen zu stoppen und das Swap geht innerhalb 2 - 3 Minuten auf normal
zurück weil die DB von 5 Giga auf 1,5 Giga fällt. Im Mysqladmin sieht man dass
250 Connections aktiv sind und desshalb braucht er den ganzen Ram.

thread_stack = 512K

Zu groß. Laß das auf dem Default (IIRC 192K).

sort_buffer_size = 6M
read_buffer_size = 4M

Zu groß. Laß das auf den Defaults.
Alle 3 vorgenannten werden pro offener Verbindung belegt!

Das geht sich mit den 256 Apache genau aus. Kann ich probeweise auch wieder
verringern, wichtig ist dass der Tagesbetrieb schnell läuft!

max_connections = 400

Brauchst du das?

Werden sowieso nur 256 & Dump und Admin verwendet, soll ich das auf 260
reduzieren?

query_cache_size = 960M

Ist vermutlich verschwendet.
Dein Log zeigt auch jede Menge Queries mit NO_CACHE.

Wird nach einigen Minuten Betrieb zur Gänze verwendet. Ist auch deutlich
schneller sobald er den Cache gefüllt hat. Vorher war der Seitenaufbau immer
total zäh, jetzt flutscht es sobald die Seite einmal aufgebaut wurde.

http://www.netproject.at/serverstats/

Ziemlich eindeutig.

Sieht so aus, als würde dein mysqldump mit --lock-tables laufen (das
ist der default). Dadurch werden alle Zugriffe auf MySQL angehalten.
Die Apache-Worker werden so nicht fertig und Apache startet für jeden
weiteren Zugriff einen weiteren Worker. Innerhalb ca. 30 Minuten (von
23:00 bis 23:30) hat Apache seine 256 erlaubten Worker gestartet und
jeder hat eine Verbindung zu MySQL aufgemacht und wartet (darauf, daß
mysqldump fertig wird).

Allerdings reichen 8G RAM nicht für 256 Apache-Worker und 256 MySQL-
Threads. Das System fängt an zu swappen. Mysqldump wird langsam.
Das sieht man sehr schön am I/O-Rate Diagramm: die 16MB/s ist
mysqldump, ca. 23:30 ist der RAM voll und der Durchsatz sackt ein.

Also die derzeitige auslastung:

ps -ax | grep apache | wc -l
198

netstat -ant | grep :80 | wc -l
756

Wobei ich starte den Apache mit:
StartServers 195
ServerLimit 250

Eigendlich sollte er ja 10 Giga DB innerhalb 10 Minuten gedumpt haben!
Manchmal, in letzter Zeit öfter bleibt aber der Dump stehen und dann laufen
die Apache auf. So kommt es mir vor.


Maßnahmen:

1. Apache und MySQL besser konfigurieren. Ich würde mal sagen,
MaxClients 100 in Apache und max_connections=200 in MySQL.
Außerdem den query_cache in MySQL verkleinern auf sagen wir
mal 256MB. Dafür innodb_buffer_pool_size=512M.
Das sollte verhindern daß dein RAM überläuft.

Maxclients 100 ist zuwenig! Sobald ich den Cache verringere gehen die Seiten
langsamer. Sind alles Typo3 installationen.

Zu einem späteren Zeitpunkt solltest du auch die InnoDB-Logs
besser konfigurieren:
innodb_log_file_size=128M
innodb_log_buffer_size=8M

Hatte ich schon (siehe oben), habe ich dann auf 5 MB begrenzt.


2. Tabellentypen checken. Vermutlich ist das Gros deiner Tabellen
(zumindest alle Tabellen von Typo3) schon InnoDB.
Wenn da (außerhalb der `mysql` Datenbank!) noch MyISAM-Tabellen
sind, überlegen ob die auf InnoDB umgestellt werden können.

Naja das mit einem Grossen Innofile hat mir nie besonders gefallen. Leider
haben die Typo3jungs einige auf Innodb umgestellt. Innodbfilepertable habe ich
erst später enteckt? bzw. kam erst später in mysql(4)??

3. mysqldump mit der Option --single-transaction aufrufen.

Muss ich mir durchlesen, können dann die Apache weiterlaufen? Derzeit schmeisse
ich den Job raus bzw. Kollege macht Reset.

DANKE!

.

Relevant Pages