mariadb103: Optimierung Backup Erstellung

[Peter Bäumer]

Glück Auf! Holger,
hatte ein keines Zeitliches Problem mit dem Mysql-Backup.
Aufgrund das eine von meinen Datenbank eine Größe von 12GB erreicht hatte (im Dateisystem, SQL-Dump ca 7,5GB), dauerte das erstellen des sql.xz Backup-Files ca. 2 Stunden.
Auf der such nach Optimierung bin ich über die Option --threads= gestolpert und habe 6 der 12 vorhanden CPU's den xz-Programm fürs erstellen u. restore gegönnt.

Ich war überrascht das es dann nur noch eine knappe habe Stunde gedauert hatte :)

Ausprobiert habe ich es nur auf Eisfair 64.

Es wäre schön wenn man im Setup Menü angeben könnte wie viele Threat's xz benutzen darf.
Oder als Auto-Einstellung immer die Hälfte der verfügbaren CPUs?
-threads=$(awk ' /core id/ {CPU_MAX_ID=$4+1}; END { printf "%0.0f\n",CPU_MAX_ID/2+0.1}' /proc/cpuinfo) # bei Ungeraden Anzahl der CPU's wird aufgerundet... mit -0.1 abgerundet...

--------------------------------------------------------

/usr/bin/mysql-common-backup.sh
nach Zeile 29 add:
arch_ext_opt=" --threads=6"

Zeile 105 und 119:
war:
${arch_ext} -c > ${db_target_name}

optimiert:
${arch_ext} ${arch_ext_opt} -c > ${db_target_name}



/usr/bin/mysql-common-restore.sh
Zeile 83:
war:
comp_cmd="unxz"

optimiert:
comp_cmd="unxz --threads=6"


----
-T, --threads=NUM use at most NUM threads; the default is 1; set to 0
to use as many threads as there are processor cores


MfG
Peter B.

[Holger Bruenjes]

Hallo Peter

Post by Peter Bäumer
hatte ein keines Zeitliches Problem mit dem Mysql-Backup.
Aufgrund das eine von meinen Datenbank eine Größe von 12GB erreicht hatte (im Dateisystem, SQL-Dump ca 7,5GB), dauerte das erstellen des sql.xz Backup-Files ca. 2 Stunden.
Auf der such nach Optimierung bin ich über die Option --threads= gestolpert und habe 6 der 12 vorhanden CPU's den xz-Programm fürs erstellen u. restore gegönnt.
Ich war überrascht das es dann nur noch eine knappe habe Stunde gedauert hatte :)
Ausprobiert habe ich es nur auf Eisfair 64.
Es wäre schön wenn man im Setup Menü angeben könnte wie viele Threat's xz benutzen darf.
Oder als Auto-Einstellung immer die Hälfte der verfügbaren CPUs?
-threads=$(awk ' /core id/ {CPU_MAX_ID=$4+1}; END { printf "%0.0f\n",CPU_MAX_ID/2+0.1}' /proc/cpuinfo) # bei Ungeraden Anzahl der CPU's wird aufgerundet... mit -0.1 abgerundet...
--------------------------------------------------------

gute Idee, nur 103 ist EOL, kommt dann mit in 110

Holger

[Peter Bäumer]

Post by Holger Bruenjes
Hallo Peter

Post by Peter Bäumer
hatte ein keines Zeitliches Problem mit dem Mysql-Backup.
Aufgrund das eine von meinen Datenbank eine Größe von 12GB erreicht hatte (im Dateisystem, SQL-Dump ca 7,5GB), dauerte das erstellen des sql.xz Backup-Files ca. 2 Stunden.
Auf der such nach Optimierung bin ich über die Option --threads= gestolpert und habe 6 der 12 vorhanden CPU's den xz-Programm fürs erstellen u. restore gegönnt.
Ich war überrascht das es dann nur noch eine knappe habe Stunde gedauert hatte :)
Ausprobiert habe ich es nur auf Eisfair 64.
Es wäre schön wenn man im Setup Menü angeben könnte wie viele Threat's xz benutzen darf.
Oder als Auto-Einstellung immer die Hälfte der verfügbaren CPUs?
-threads=$(awk ' /core id/ {CPU_MAX_ID=$4+1}; END { printf "%0.0f\n",CPU_MAX_ID/2+0.1}' /proc/cpuinfo) # bei Ungeraden Anzahl der CPU's wird aufgerundet... mit -0.1 abgerundet...
--------------------------------------------------------

gute Idee, nur 103 ist EOL, kommt dann mit in 110

ups da habe ich nicht aufgepasst im alten Backup habe ich noch Sicherungen von der Version 103,
installiert und getestet habe ich mit der Version 110.

Danke für die Rückmeldung.

Post by Holger Bruenjes
Holger

MfG
Peter B.