1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Herzlich Willkommen auf der Internet-Plattform zum Edelmänner-Server!
    Du bist aktuell Gast auf unserer Website und hast nur eingeschränkten Zugriff auf manche Foren.
    Um vollständigen Zugriff auf unser Forum zu erhalten, musst du dich zuerst mit deinem Minecraft-Namen in unserem Forum registrieren und dich zu einem Spieler bewerben. Mit dieser Bewerbung einhergehend ist auch die Einstufung als Spieler auf unserem Minecraft-Server.

    Server-Adresse: s.edelmaenner.net
    Version: 1.14.4

    Schau doch mal vorbei!
    Information ausblenden

Vergleich von Backups und TPS Drops

Dieses Thema im Forum "Beschwerden & Anregungen" wurde erstellt von __kreck, 17. Nov. 2019.

  1. __kreck

    Spieler

    Registriert seit:
    30. Apr. 2017
    Beiträge:
    57
    Zustimmungen:
    12
    Hallo,

    Ich habe mir mal die Backupvarianten angeschaut um die TPS Drops während der Sicherung (auch künftig) zu verringern.

    Getstet habe ich mit einer Welt die 6.7Gb hat (2b2t, habe leider keinen größeren Worlddownload gefunden).

    Auf dem Server liefen eine diverse Dinge um ein wenig Lag zu verursachen und die TPS zu drücken. TPS waren zwischen 17.5 – 18.5, hat ein wenig variiert. Ausgestattet war der Server recht spärlich: 2 CPU á 2095 MHz und 4Gb RAM.

    CPU lief während den Tests auf Vollast. TPS wurden im 5 Sekundentakt erfasst.

    upload_2019-11-17_15-47-51.png
    upload_2019-11-17_15-47-58.png
    upload_2019-11-17_15-48-7.png

    Folgendes wurde getestet:

    1. tar ohne ionice
    2. tar mit ionice -c3
    3. tar in docker Container mit Bandbreitenlimit von 20Mb
    4. tar ohne Kompression
    5. tar über ssh (50Mbit Leitung)
    6. tar über ssh (1Gbit+ Leitung)
    7. rsync
    8. rsync mit Bandbreitenlimit ~10Mb
    9. borg
    10. borg mit 500 geänderten Files (timestamp)
    11. rsync mit 500 geänderten Files (timestamp)
    12. rsync mit 500 geänderten Files (timestamp) und --no-whole-file Switch
    Ich habe vor der Sicherung kein Snapshot des Volumes erstellt, deshalb kam es beim Sichern auch zu unschönen Meldungen: tar: world: file changed as we read it ;)

    Bei den Sicherungen per tar habe ich mir das rüberkopieren per SCP gespart, hätte die Sache sicherlich nicht besser gemacht.

    Über die Qualität der Shellscripte können wir später streiten. Der Zweck wurde erfüllt :).


    1. tar ohne ionice

    tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
    230.40s user 25.41s system 90% cpu 4:43.52 total


    upload_2019-11-17_15-51-7.png
    upload_2019-11-17_15-51-11.png

    2. tar mit ionice -c3

    Das ist die Methode die momentan wohl laut @Zweistein2 verwendet wird.

    upload_2019-11-17_15-52-1.png

    ionice -c3 macht gefühlt keinen großen Unterschied :/

    ionice -c3 tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world
    230.98s user 27.76s system 89% cpu 4:48.95 total


    upload_2019-11-17_15-52-41.png
    upload_2019-11-17_15-52-46.png

    3. tar in docker Container mit Bandbreitenlimit von 20Mb

    Danach dachte ich, vielleicht kann man die Bandbreite mit einem Contrainer besser drosseln. Hat soweit auch funktioniert, I/O sind jedenfalls sehr gering, dafür dauert das Backup entsprechend länger. TPS droppen auch nicht mehr so extrem wie zuvor.

    docker run -it --rm --name minecraft_backup -w /tmp/minecraft -v /tmp/minecraft:/tmp/minecraft --device-read-bps=/dev/system/root:20mb --device-write-bps=/dev/system/root:20mb alpine time tar czvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/world


    upload_2019-11-17_15-53-24.png
    upload_2019-11-17_15-53-28.png

    4. tar ohne Kompression

    Nun nochmal das Ganze ohne Kompression, sollte die Last der CPU deutlich reduzieren.

    Läuft ratz fatz. Dafür ist die Filesize natürlich größer. TPS drop ist auch hier vorhanden, jedoch deutlich geringer.

    tar cvf /tmp/minecraft/backup/foo.tar.gz /tmp/minecraft/backup/world
    0.80s user 16.72s system 45% cpu 38.669 total

    upload_2019-11-17_15-54-40.png
    upload_2019-11-17_15-54-47.png


    Aber warum überhaupt erst Lokal speichern und dann per SCP übertragen? Warum nicht gleich per SSH auf den Zielserver übertragen und dort komprimieren?


    5. tar über ssh (50Mbit Leitung)

    Reduziert immerhin die Write I/O. TPS drop ähnlich wie bei der Docker Variante. Habe den Versuch dann aber abgebrochen nach ein paar Minuten.

    tar cvf - /tmp/minecraft/world | ssh -p 56022 root@192.168.2.2 "gzip -6 > /tmp/foo.tar.gz"

    upload_2019-11-17_15-56-19.png
    upload_2019-11-17_15-56-24.png


    6. tar über ssh (1Gbit+ Leitung)

    Diesmal wurde das Backup auf einen anderen Server kopiert. Dieser hatte auch eine ordentliche Anbindung.

    TPS drop ist ähnlich wie bei dem Test mit einer 50Mbit Bandbreite.

    tar cvf - /tmp/minecraft/world | ssh kreck@x.x.x.x "gzip -9 > ~/foo.tar.gz"

    upload_2019-11-17_15-57-19.png
    upload_2019-11-17_15-57-24.png

    Um ein paar Files zu ändern habe ich random den Zeitstempel von Files geändert

    find /tmp/minecraft/world/region -name '*.mca' -type f -exec bash -c '(($RANDOM%5)) && touch {}' \;

    7. rsync

    rsync -av /tmp/minecraft/world/ -e 'ssh -p xxx' kreck@x.x.x.x:~/world/
    31.39s user 11.34s system 12% cpu 5:34.91 total


    leider habe ich hier keine I/O Stats.

    upload_2019-11-17_15-58-45.png

    8. rsync mit Bandbreitenlimit ~10Mb

    Ähnlich wie ohne Limitierung. TPS Drop ebenfalls vorhanden, aber nicht mehr so stark. Dauer des Backups ist trotzdem deutlich reduziert.

    rsync -av --bwlimit=10000 /tmp/minecraft/world/ -e 'ssh -p xxx' kreck@x.x.x.:~/world/ 32.53s user 9.99s system 14% cpu 4:51.02 total

    upload_2019-11-17_15-59-20.png
    upload_2019-11-17_15-59-24.png

    9. borg

    Darauf hat mich @minifisch in Discord gebracht. Repository liegt ebenfalls auf einem anderen Server.

    I/O ist hoch, Impact der TPS auch. Aber – es geht verdammt schnell.

    borg create --stats --compression none ssh://kreck@x.x.x.x:xxxx/home/kreck/borg::minecraft_$(date +%Y.%m.%d_%H.%M) /tmp/minecraft/world
    51.61s user 6.01s system 63% cpu 1:31.28 total


    upload_2019-11-17_16-0-29.png
    upload_2019-11-17_16-0-34.png

    Nun musste ich ungefähr gleiche Verhältnisse herstellen um rsync und borg vergleichen zu können. Also habe ich bei den ersten 500 Dateien den Zeitstempel geändert und dann die Sicherung gestartet.

    COUNT=1; for i in $(ls /tmp/minecraft/world/region); do [ $COUNT -le 500 ] && touch /tmp/minecraft/world/region/$i; [ $COUNT -eq 500 ] && break; ((COUNT=$COUNT+1)); done

    buuh Output von ls soll man nicht parsen ...

    10. borg mit 500 geänderten Files (timestamp)

    TPS drop auch vorhanden (wie zuvor), jedoch wenigster stark. Backup ist auch schnell durchgelaufen.

    borg create --stats --compression none ssh://kreck@x.x.x.x:xxxx/home/kreck/borg::minecraft_$(date +%Y.%m.%d_%H.%M) /tmp/minecraft/world

    upload_2019-11-17_16-4-22.png
    upload_2019-11-17_16-4-28.png


    10. rsync mit 500 geänderten Files (timestamp)

    I/O Impact ist geringer, jeodoch dauert die Sicherung ein wenig länger. TSP drop ist <1 TPS weniger im Vergleich zu borg.

    rsync -av -e 'ssh -p xxx' /tmp/minecraft/world/ kreck@x.x.x.x:/home/kreck/world/

    upload_2019-11-17_16-10-45.png
    upload_2019-11-17_16-10-49.png

    Nun fiel mir noch ein das rsync den --no-whole-file Switch hat für Übertragungen übers Netz.

    11. rsync mit 500 geänderten Files (timestamp) und --no-whole-file Switch

    Wieder eine kleine Verbesserung.

    rsync -av --no-whole-file -e 'ssh -p xxx' /tmp/minecraft/world/ kreck@x.x.x.x:/home/kreck/world/

    upload_2019-11-17_16-12-20.png
    upload_2019-11-17_16-12-23.png




    Vergleich TPS borg/rsync --no-whole-file
    upload_2019-11-17_16-12-59.png

    Komplette Übersicht
    upload_2019-11-17_16-13-21.png


    Zusammenfassung

    tar in jeglicher Form scheidet aus. Ich denke die Wahl sollte auf rsync + rsnapshot oder borg fallen. Vielleicht gibt es bei borg ebenfalls noch Optimierungen. Ich habe das Tool zum ersten mal Benutzt und bin mit den Einstellungen noch nicht vertraut.

    Was man jedoch sagen kann: beide sind schneller, sichern inkrementell und vergingern die Last deutlich.


    Man muss natürlich prüfen wie sich die Performance auf einem Server mit mehr Kernen, RAM und einer größeren Welt verhält, aber für einen groben Überblick sollte das erstmal reichen.

    Falls noch jemand weitere Vorschläge hat nehme ich diese gerne an.


    Danke an @Iglo für das bereitstellen eines Server der mir als Backuprepository gedient hat.
    Danke @minifisch für den Vorschlag von borg, das werde ich mir mal genauer ansehen.

    Gruß
    __kreck
     
    #1 __kreck, 17. Nov. 2019
    Zuletzt bearbeitet: 17. Nov. 2019
    • Gefällt mir Gefällt mir x 7
  2. Iglo

    Spieler

    Registriert seit:
    7. Nov. 2016
    Beiträge:
    57
    Zustimmungen:
    1
    Den Server bereitzustellen war die geringste Leistung an diesem Beitrag! Danke aufjedenfall von mir für deine Mühen!
    Denke das kann gut als Grundlage für zukünftige Gespräche verwendet werden, anstelle des Stochern im blauen Dunst .)

    Hoffe das es @Zweistein2 genug Fakten an die Hand gibt um eine Entscheidung bzgl der Backupstrategie zu finden.
    Die aktuell laufenden Backups während des Zockens sind nur wenig feierlich.
     
  3. Zweistein2

    Zweistein2 Forengestein
    Administrator

    Registriert seit:
    26. Aug. 2014
    Beiträge:
    872
    Zustimmungen:
    407
    Was für einen Einfluss haben inkrementelle Backups auf MC? Sprich Chunk-Corruption, Wiederherstellung, etc.?

    Hab da leider keinerlei Erfahrungswerte dazu und im Internet findet man viel dazu wenn der Tag lang ist... :S
     
  4. __kreck

    Spieler

    Registriert seit:
    30. Apr. 2017
    Beiträge:
    57
    Zustimmungen:
    12
    Ich denke das es keine Rolle spielt ob man die Chunks Full oder Inkrementell sichert. Die Region Files halten ja immer die Informationen für einen kompletten Chunk und stehen logisch in keinem Bezug zu einer anderen Datei bzw. Chunk.

    Laut Internet™ kann Ich die ja einfach rauslöschen und der Server generiert diese neu. Scheint aber nicht so recht zu funktionieren, mit Paper jedenfalls nicht. Vanilla und Spigot hab ich nicht getestet. Vielleicht einfach mal ne Woche testen und einen Restore durchführen.

    upload_2019-11-17_22-1-26.png

    Wichtiger ist es während der Sicherung einen konsistenten Stand zu haben. Sprich einen Snapshot zu erstellen und davon dann die Sicherung zu machen. Es sollte ein Dateisystem verwendet werden welches diese Funktionalität hat. XFS, BtrFS oder LVM mit z.B. xfs oder ext4.

    Da es sich hier nur um "simple" Dateien dreht ist das Handling es Backups doch vergleichsweise einfach.

    Unter Konsistent verstehe ich auch, dass die Datenbanken den gleichen Informationsstand haben wie das Dateisystem. Wenn die Sicherung der Dateien läuft und ich währenddessen Blöcke setze und diese Informationen z.B. in der Logblock-DB landen hast du beim Restore falschen Stände zwischen DB und Filesystem (World).

    Kurz um: Ich sehe keine Probleme in einer inkrementellen Sicherung der Files, für den Restore gilt das gleiche. Das ist jedoch meine persönliche Einschätzung - ich bin kein Spezialist für Minecraft Server und lasse mich gerne eines besseren belehren.

    Wenn ein Chunk jedoch im Quelldateisystem schon defekt ist, dann spielt es auch keine Rolle mehr ob ich Full oder Inkrementell sicher.

    Gruß
    __kreck
     
  5. Iglo

    Spieler

    Registriert seit:
    7. Nov. 2016
    Beiträge:
    57
    Zustimmungen:
    1
    Ping. Gibt es hier einen neuen Stand?
     
  6. Zweistein2

    Zweistein2 Forengestein
    Administrator

    Registriert seit:
    26. Aug. 2014
    Beiträge:
    872
    Zustimmungen:
    407
    Noch nicht