info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Linux-Problem
2 views
Skip to first unread message
Stefan Puschek
Nov 1, 2022, 12:00:31 PM11/1/22
to
Linux-Problem
Hallo Mitlesende,
ich habe da ein Problem - und weiss nicht wo ich ansetzen soll :)
Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter Form
auf einem nfs-Mount ablegen: (ein backup-Skript)
benutzt wird dafür partclone,
komprimieren soll pigz (gzip hatte ich auch schon probiert),
der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
das funktioniert, aaaber: warum kann er nicht komprimieren (pigz oder
gzip) und GLEICHZEITIG den Output auf den Server schreiben?
Wenn ich mit htop zusehe, gibt es 2 abwechselnde Zustände: entweder er
komprimiert (=hohe CPU-Nutzung) oder er schreibt den Output auf den
Server (Network-IO sieht man auch im htop).
Warum kann er nicht GLEICHZEITIG komprimieren und den Output speichern?
Habe ich falsche Vorstellungen oder mache ich es nur nicht richtig?
Ich habe erst einen e1-USB-Stick probiert, und danach GRML
(Debian-basiert) - und bei Beiden das gleiche Phänomen...
Wo liegt mein Fehler?
Groetjes
Stefan
Hallo Mitlesende,
ich habe da ein Problem - und weiss nicht wo ich ansetzen soll :)
Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter Form
auf einem nfs-Mount ablegen: (ein backup-Skript)
benutzt wird dafür partclone,
komprimieren soll pigz (gzip hatte ich auch schon probiert),
der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
das funktioniert, aaaber: warum kann er nicht komprimieren (pigz oder
gzip) und GLEICHZEITIG den Output auf den Server schreiben?
Wenn ich mit htop zusehe, gibt es 2 abwechselnde Zustände: entweder er
komprimiert (=hohe CPU-Nutzung) oder er schreibt den Output auf den
Server (Network-IO sieht man auch im htop).
Warum kann er nicht GLEICHZEITIG komprimieren und den Output speichern?
Habe ich falsche Vorstellungen oder mache ich es nur nicht richtig?
Ich habe erst einen e1-USB-Stick probiert, und danach GRML
(Debian-basiert) - und bei Beiden das gleiche Phänomen...
Wo liegt mein Fehler?
Groetjes
Stefan
Marcus Röckrath
Nov 1, 2022, 1:10:02 PM11/1/22
to
Hallo Stefan,
Stefan Puschek wrote:
> Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter Form
> auf einem nfs-Mount ablegen: (ein backup-Skript)
>
> benutzt wird dafür partclone,
> komprimieren soll pigz (gzip hatte ich auch schon probiert),
> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
>
> partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
>
> das funktioniert, aaaber: warum kann er nicht komprimieren (pigz oder
> gzip) und GLEICHZEITIG den Output auf den Server schreiben?
IMHO weil das Packen Blockweise geschieht.
> Wo liegt mein Fehler?
Ich wüsste nicht, dass du einen Fehler machst.
Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät brauchbar
an, oder?
PS: Die zu sichernde Partition ist aber nicht aktiv eingehängt.
--
Gruß Marcus
Stefan Puschek wrote:
> Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter Form
> auf einem nfs-Mount ablegen: (ein backup-Skript)
>
> benutzt wird dafür partclone,
> komprimieren soll pigz (gzip hatte ich auch schon probiert),
> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
>
> partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
>
> das funktioniert, aaaber: warum kann er nicht komprimieren (pigz oder
> gzip) und GLEICHZEITIG den Output auf den Server schreiben?
> Wo liegt mein Fehler?
Ich wüsste nicht, dass du einen Fehler machst.
Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät brauchbar
an, oder?
PS: Die zu sichernde Partition ist aber nicht aktiv eingehängt.
--
Gruß Marcus
Stefan Puschek
Nov 1, 2022, 1:50:26 PM11/1/22
to
Hallo Marcus,
da mal nachlesen - wonach suche ich?
> > Wo liegt mein Fehler?
>
> Ich wüsste nicht, dass du einen Fehler machst.
schon mal gut
> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
> brauchbar an, oder?
klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
komprimiert und geschrieben würde
> PS: Die zu sichernde Partition ist aber nicht aktiv eingehängt.
logisch :)
Groetjes
Stefan
>
> > Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter
> > Form auf einem nfs-Mount ablegen: (ein backup-Skript)
> >
> > benutzt wird dafür partclone,
> > komprimieren soll pigz (gzip hatte ich auch schon probiert),
> > der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
> >
> > partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
> >
> > das funktioniert, aaaber: warum kann er nicht komprimieren (pigz
> > oder gzip) und GLEICHZEITIG den Output auf den Server schreiben?
>
> IMHO weil das Packen Blockweise geschieht.
und deswegen kann er entweder komprimieren ODER schreiben? Wo kann ich
> > Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter
> > Form auf einem nfs-Mount ablegen: (ein backup-Skript)
> >
> > benutzt wird dafür partclone,
> > komprimieren soll pigz (gzip hatte ich auch schon probiert),
> > der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
> >
> > partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
> >
> > das funktioniert, aaaber: warum kann er nicht komprimieren (pigz
> > oder gzip) und GLEICHZEITIG den Output auf den Server schreiben?
>
> IMHO weil das Packen Blockweise geschieht.
da mal nachlesen - wonach suche ich?
> > Wo liegt mein Fehler?
>
> Ich wüsste nicht, dass du einen Fehler machst.
> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
> brauchbar an, oder?
komprimiert und geschrieben würde
> PS: Die zu sichernde Partition ist aber nicht aktiv eingehängt.
Groetjes
Stefan
Marcus Röckrath
Nov 1, 2022, 2:40:03 PM11/1/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> und deswegen kann er entweder komprimieren ODER schreiben? Wo kann ich
> da mal nachlesen - wonach suche ich?
>
> da mal nachlesen - wonach suche ich?
>
>> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
>> brauchbar an, oder?
>
> klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> komprimiert und geschrieben würde
Wenn die Komprimierung blockweise geschieht, kann es nicht "durchgehend"
>> brauchbar an, oder?
>
> klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> komprimiert und geschrieben würde
synchron über die Netzwerkschnittstelle gehen, wie die Daten von partclone
an gzip/*zip übergeben werden.
Ein Block muss von gzip analysiert werden und geht dann auch wieder als
Block raus und nicht Byte rein und sofort wieder raus - Durchzug sozusagen.
Welche Raten hast du?
In einem Schnelltest mit gzip als Kompriemierer komme ich hier (auf
Samba-Freigabe) auf ca. 10 MB/s.
--
Gruß Marcus
Kay Martinen
Nov 1, 2022, 3:00:13 PM11/1/22
to
Am 01.11.22 um 18:50 schrieb Stefan Puschek:
>>> Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter
>>> Form auf einem nfs-Mount ablegen: (ein backup-Skript)
>>>
>>> benutzt wird dafür partclone,
Ist mir nicht vertraut. Kopiert das auch leere Blöcke mit oder kann man
die ausklammern - was dann ja aber kein klon mehr wäre.
>>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
>>> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann sie
komprimieren mit gzip oder dem anderen?
>>> partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
>>>
>>> das funktioniert, aaaber: warum kann er nicht komprimieren (pigz
>>> oder gzip) und GLEICHZEITIG den Output auf den Server schreiben?
>>
>> IMHO weil das Packen Blockweise geschieht.
>
> und deswegen kann er entweder komprimieren ODER schreiben? Wo kann ich
> da mal nachlesen - wonach suche ich?
Vielleicht in Richtung Blockgröße. Platten liefern entweder 512 Byte
oder 4k Sektoren, wie macht partclone das, welche blockgröße benutzt
dein komprimierer wenn er einen datenstrom komprimieren soll?
Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster mit
der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst werden -
innerhalb eines Blocks. Wenn da jetzt ein 4k block mit daten und dann
ein 4k block mit leerstellen kommen und dein komprimierer arbeitet NICHT
mit 4k blockgröße...!
>> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
>> brauchbar an, oder?
>
> klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> komprimiert und geschrieben würde
Das könnte am Leistungsvermögen deiner Hardware liegen. Hast du das
gleiche mal auf einem Schnelleren PC mit mehr RAM probiert?
Alternative wenn du genug Platz auf der Quelle hast. Erst das image
lokal schreiben, ggf. mit Komprimierung und dann das komprimierte file
auf den remote rechner schieben.
Noch schneller könnte es durch Ertüchtigung deines Netzwerkes in
Richtung GbE gehen. Braucht vielleicht nur der Server eine 1000BaseT
Karte statt der 100BaseT? Wenn der Switch Smart genug ist könnte auch
eine zweite 100BaseT helfen. Es gibt ja bonding-tools für den EIS.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
>>> Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter
>>> Form auf einem nfs-Mount ablegen: (ein backup-Skript)
>>>
>>> benutzt wird dafür partclone,
die ausklammern - was dann ja aber kein klon mehr wäre.
>>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
>>> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
komprimieren mit gzip oder dem anderen?
>>> partclone.ext4 -s /dev/sda2 -o - -c | pigz -c > $DESTDIR/p2.root.gz
>>>
>>> das funktioniert, aaaber: warum kann er nicht komprimieren (pigz
>>> oder gzip) und GLEICHZEITIG den Output auf den Server schreiben?
>>
>> IMHO weil das Packen Blockweise geschieht.
>
> und deswegen kann er entweder komprimieren ODER schreiben? Wo kann ich
> da mal nachlesen - wonach suche ich?
oder 4k Sektoren, wie macht partclone das, welche blockgröße benutzt
dein komprimierer wenn er einen datenstrom komprimieren soll?
Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster mit
der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst werden -
innerhalb eines Blocks. Wenn da jetzt ein 4k block mit daten und dann
ein 4k block mit leerstellen kommen und dein komprimierer arbeitet NICHT
mit 4k blockgröße...!
>> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
>> brauchbar an, oder?
>
> klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> komprimiert und geschrieben würde
gleiche mal auf einem Schnelleren PC mit mehr RAM probiert?
Alternative wenn du genug Platz auf der Quelle hast. Erst das image
lokal schreiben, ggf. mit Komprimierung und dann das komprimierte file
auf den remote rechner schieben.
Noch schneller könnte es durch Ertüchtigung deines Netzwerkes in
Richtung GbE gehen. Braucht vielleicht nur der Server eine 1000BaseT
Karte statt der 100BaseT? Wenn der Switch Smart genug ist könnte auch
eine zweite 100BaseT helfen. Es gibt ja bonding-tools für den EIS.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Stefan Puschek
Nov 2, 2022, 5:45:54 AM11/2/22
to
Hallo Marcus,
> Ein Block muss von gzip analysiert werden und geht dann auch wieder
> als Block raus und nicht Byte rein und sofort wieder raus - Durchzug
> sozusagen.
logisch
> Welche Raten hast du?
partclone lesen und nach /dev/null schieben 10GB in 60 Sekunden
partclone lesen, pipen nach pigz und von da nach /dev/null ca. 180
Sekunden
partclone lesen, pipen nach pigz und von da per 100Mbit/s auf den
Server 500 Sekunden
> In einem Schnelltest mit gzip als Kompriemierer komme ich hier (auf
> Samba-Freigabe) auf ca. 10 MB/s.
reine Datenübertragung auf den Server 11,7MByte/s laut htop
Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
'komprimieren' und 'auf den Server schreiben' wechselt...
Groetjes
Stefan
>
> > und deswegen kann er entweder komprimieren ODER schreiben? Wo kann
> > ich da mal nachlesen - wonach suche ich?
> >
> >> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
> >> brauchbar an, oder?
> >
> > klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> > komprimiert und geschrieben würde
>
> Wenn die Komprimierung blockweise geschieht, kann es nicht
> "durchgehend" synchron über die Netzwerkschnittstelle gehen, wie die
> Daten von partclone an gzip/*zip übergeben werden.
pigz bearbeitet PARALLEL auf 4 cores 128KB-Blöcke laut man-page
> > und deswegen kann er entweder komprimieren ODER schreiben? Wo kann
> > ich da mal nachlesen - wonach suche ich?
> >
> >> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
> >> brauchbar an, oder?
> >
> > klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> > komprimiert und geschrieben würde
>
> Wenn die Komprimierung blockweise geschieht, kann es nicht
> "durchgehend" synchron über die Netzwerkschnittstelle gehen, wie die
> Daten von partclone an gzip/*zip übergeben werden.
> Ein Block muss von gzip analysiert werden und geht dann auch wieder
> als Block raus und nicht Byte rein und sofort wieder raus - Durchzug
> sozusagen.
> Welche Raten hast du?
partclone lesen und nach /dev/null schieben 10GB in 60 Sekunden
partclone lesen, pipen nach pigz und von da nach /dev/null ca. 180
Sekunden
partclone lesen, pipen nach pigz und von da per 100Mbit/s auf den
Server 500 Sekunden
> In einem Schnelltest mit gzip als Kompriemierer komme ich hier (auf
> Samba-Freigabe) auf ca. 10 MB/s.
Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
'komprimieren' und 'auf den Server schreiben' wechselt...
Groetjes
Stefan
Stefan Puschek
Nov 2, 2022, 5:59:01 AM11/2/22
to
Hallo Kay,
> >>> Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter
> >>> Form auf einem nfs-Mount ablegen: (ein backup-Skript)
> >>>
> >>> benutzt wird dafür partclone,
>
> Ist mir nicht vertraut. Kopiert das auch leere Blöcke mit oder kann
> man die ausklammern - was dann ja aber kein klon mehr wäre.
partclone kopiert nur die belegten Blöcke - für ein Backup reicht das
> >>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
> >>> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
>
> Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann
> sie komprimieren mit gzip oder dem anderen?
SATA-SSD :)
partclone liest von der Partition 10GB in 60Sekunden und schiebt den
Output nach /dev/null
> >>> partclone.ext4 -s /dev/sda2 -o - -c | pigz -c >
> >>> $DESTDIR/p2.root.gz
> >>>
> >>> das funktioniert, aaaber: warum kann er nicht komprimieren (pigz
> >>> oder gzip) und GLEICHZEITIG den Output auf den Server schreiben?
> >>
> >> IMHO weil das Packen Blockweise geschieht.
> >
> > und deswegen kann er entweder komprimieren ODER schreiben? Wo kann
> > ich da mal nachlesen - wonach suche ich?
>
> Vielleicht in Richtung Blockgröße. Platten liefern entweder 512 Byte
> oder 4k Sektoren, wie macht partclone das, welche blockgröße benutzt
> dein komprimierer wenn er einen datenstrom komprimieren soll?
pigz nutzt 128KB Blocksize laut man-page
> Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster mit
> der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst werden -
> innerhalb eines Blocks. Wenn da jetzt ein 4k block mit daten und dann
> ein 4k block mit leerstellen kommen und dein komprimierer arbeitet
> NICHT mit 4k blockgröße...!
aber das erklärt nicht, warum er alle 10-20 Sekunden zwischen
komprimieren und speichern wechselt - in 10 Sekunden schreibt er 110
MEGABYTE - also die Blöcke sind VIEL kleiner...
> >> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
> >> brauchbar an, oder?
> >
> > klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> > komprimiert und geschrieben würde
>
> Das könnte am Leistungsvermögen deiner Hardware liegen. Hast du das
> gleiche mal auf einem Schnelleren PC mit mehr RAM probiert?
i5-4210U im Notebook
aber ich habs auch mal auf meinem Desktop versucht:
Ryzen5 5600X, 32GB RAM, per GbE an den Server angebunden und ähnliches
Ergebnis: entweder er komprimiert oder er speichert - aber NIEMALS
gleichzeitig :(
> Alternative wenn du genug Platz auf der Quelle hast. Erst das image
> lokal schreiben, ggf. mit Komprimierung und dann das komprimierte
> file auf den remote rechner schieben.
für das Backup starte ich die Maschinen von einem USB-Stick, also kein
schneller lokaler Platz verfügbar...
> Noch schneller könnte es durch Ertüchtigung deines Netzwerkes in
> Richtung GbE gehen. Braucht vielleicht nur der Server eine 1000BaseT
> Karte statt der 100BaseT? Wenn der Switch Smart genug ist könnte auch
> eine zweite 100BaseT helfen. Es gibt ja bonding-tools für den EIS.
es geht um die Verbindung zwischen der 'Werkstatt' (mein Schlafzimmer)
und dem Arbeitszimmer: kein LAN möglich wegen zu viele Türen
dazwischen; deswegen nutze ich seit fast 12 Jahren ein Päärchen Ubiquity
NanoStation M5 (Punkt-zu-Punkt Funkbrücke)
Aber es bleibt die Frage: warum kann er nicht gleichzeitig komprimieren
UND den Output wegschreiben...
Groetjes
Stefan
> >>> Ich möchte den Inhalt einer Partition (z.B. ext4) in komprimierter
> >>> Form auf einem nfs-Mount ablegen: (ein backup-Skript)
> >>>
> >>> benutzt wird dafür partclone,
>
> Ist mir nicht vertraut. Kopiert das auch leere Blöcke mit oder kann
> man die ausklammern - was dann ja aber kein klon mehr wäre.
> >>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
> >>> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
>
> Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann
> sie komprimieren mit gzip oder dem anderen?
partclone liest von der Partition 10GB in 60Sekunden und schiebt den
Output nach /dev/null
> >>> partclone.ext4 -s /dev/sda2 -o - -c | pigz -c >
> >>> $DESTDIR/p2.root.gz
> >>>
> >>> das funktioniert, aaaber: warum kann er nicht komprimieren (pigz
> >>> oder gzip) und GLEICHZEITIG den Output auf den Server schreiben?
> >>
> >> IMHO weil das Packen Blockweise geschieht.
> >
> > und deswegen kann er entweder komprimieren ODER schreiben? Wo kann
> > ich da mal nachlesen - wonach suche ich?
>
> Vielleicht in Richtung Blockgröße. Platten liefern entweder 512 Byte
> oder 4k Sektoren, wie macht partclone das, welche blockgröße benutzt
> dein komprimierer wenn er einen datenstrom komprimieren soll?
> Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster mit
> der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst werden -
> innerhalb eines Blocks. Wenn da jetzt ein 4k block mit daten und dann
> ein 4k block mit leerstellen kommen und dein komprimierer arbeitet
> NICHT mit 4k blockgröße...!
komprimieren und speichern wechselt - in 10 Sekunden schreibt er 110
MEGABYTE - also die Blöcke sind VIEL kleiner...
> >> Wo liegt denn das Problem? Die Daten komen doch auf dem Zielgerät
> >> brauchbar an, oder?
> >
> > klar - aber das Backup könnte schneller gehen, wenn GLEICHZEITIG
> > komprimiert und geschrieben würde
>
> Das könnte am Leistungsvermögen deiner Hardware liegen. Hast du das
> gleiche mal auf einem Schnelleren PC mit mehr RAM probiert?
aber ich habs auch mal auf meinem Desktop versucht:
Ryzen5 5600X, 32GB RAM, per GbE an den Server angebunden und ähnliches
Ergebnis: entweder er komprimiert oder er speichert - aber NIEMALS
gleichzeitig :(
> Alternative wenn du genug Platz auf der Quelle hast. Erst das image
> lokal schreiben, ggf. mit Komprimierung und dann das komprimierte
> file auf den remote rechner schieben.
schneller lokaler Platz verfügbar...
> Noch schneller könnte es durch Ertüchtigung deines Netzwerkes in
> Richtung GbE gehen. Braucht vielleicht nur der Server eine 1000BaseT
> Karte statt der 100BaseT? Wenn der Switch Smart genug ist könnte auch
> eine zweite 100BaseT helfen. Es gibt ja bonding-tools für den EIS.
und dem Arbeitszimmer: kein LAN möglich wegen zu viele Türen
dazwischen; deswegen nutze ich seit fast 12 Jahren ein Päärchen Ubiquity
NanoStation M5 (Punkt-zu-Punkt Funkbrücke)
Aber es bleibt die Frage: warum kann er nicht gleichzeitig komprimieren
UND den Output wegschreiben...
Groetjes
Stefan
Thomas
Nov 2, 2022, 7:37:14 AM11/2/22
to
Ich habe über Dein Problem noch nie nachgedacht...
In meiner Vorstellung ist eine Pipe ein Rohr: Ein Prozess schiebt Daten
in das Rohr und ein zweiter nimmt die Daten heraus.
Wenn alles passt (der Erzeuger-Prozess schiebt die Daten mit 10Mb/s, die
Pipe kann 10Mb/s empfangen, die Pipe kann 10Mb/s schreiben, der
Datensenke-Prozess kann 10Mb/s empfangen), könnte ich mir vorstellen,
das sowohl der Erzeuger-Prozess als auch der Datensenke-Prozess
"gleichzeitig" die CPU nutzen.
Wie verwaltet das Betriebssystem eine Pipe? Können beide Prozesse
"gleichzeitig" schreiben und lesen? Darf immer nur ein Prozess auf die
Pipe zugreifen? Die Pipe muss ja verwalten, wohin der Erzeuger schreiben
darf und welchen Daten der Datensenke-Prozess gelesen hat. Ich kann mir
gut vorstellen, dass das Betriebssystem über eine Sperre festlegt,
welcher Prozess auf die Pipe zugreifen und deren Zustand verändern darf.
Wenn ich mir die Pipe wie einen Eimer vorstelle, kann der
Erzeuger-Prozess nur so viele Daten schrieben, bis der Eimer voll ist.
Auf der anderen Seite kann der Datensenke-Prozess nur so viele Daten
lesen, wie im Eimer sind. Kann man nicht in den
Betriebssystem-Parametern festlegen, wie groß der "Eimer" (technisch
würde ich das Buffer size nennen) einer/aller Pipes sein soll? Ich würde
schätzen, je größer der Eimer Deiner Pipe ist, desto mehr Parallelität
wirst Du in htop sehen.
Gruß
Thomas
Marcus Röckrath
Nov 2, 2022, 9:30:02 AM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> partclone kopiert nur die belegten Blöcke - für ein Backup reicht das
>
>> >>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
>> >>> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
>>
>> Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann
>> sie komprimieren mit gzip oder dem anderen?
>
> SATA-SSD :)
> partclone liest von der Partition 10GB in 60Sekunden und schiebt den
> Output nach /dev/null
Und wie lange dauert es, wenn du es vor /dev/null noch durch den
>
>> >>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
>> >>> der Server mit $DESTDIR ist leider nur per 100Mbit/s angebunden.
>>
>> Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann
>> sie komprimieren mit gzip oder dem anderen?
>
> SATA-SSD :)
> partclone liest von der Partition 10GB in 60Sekunden und schiebt den
> Output nach /dev/null
Komprimierer schiebst?
> pigz nutzt 128KB Blocksize laut man-page
>
>> Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster mit
>> der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst werden -
>> innerhalb eines Blocks. Wenn da jetzt ein 4k block mit daten und dann
>> ein 4k block mit leerstellen kommen und dein komprimierer arbeitet
>> NICHT mit 4k blockgröße...!
>
> aber das erklärt nicht, warum er alle 10-20 Sekunden zwischen
> komprimieren und speichern wechselt - in 10 Sekunden schreibt er 110
> MEGABYTE - also die Blöcke sind VIEL kleiner...
garnichts tut, wenn er nicht ganz oben in der Liste ist.
Wenn das Ausgangssystem schnell genug ist, die Komprimierung in sowas wie
Echtzeit durchzuführen - siehe oben den Test mit zip nach /dev/null - käme
nun noch die Netzwerkschnittstelle ins Spiel.
> aber ich habs auch mal auf meinem Desktop versucht:
> Ryzen5 5600X, 32GB RAM, per GbE an den Server angebunden und ähnliches
> Ergebnis: entweder er komprimiert oder er speichert - aber NIEMALS
> gleichzeitig :(
Nur weil er nicht oben in htop erscheint?
> Aber es bleibt die Frage: warum kann er nicht gleichzeitig komprimieren
> UND den Output wegschreiben...
und die Netzwerkschnittstelle ausgeben. Ist der Block weggeschrieben, was
keine Last in pigz verursachen wird, wird er vermutlich ziemlich flott
übertragen, was auch keine große Last verursachen wird und bei der relativ
kleinen Blockgröße auch ziemlich schnell gehen soll.
Um genau zu prüfen, wer zu welchem Zeitpunkt was und wieviel tut, sind Tools
wie top etc. eher kaum geeignet, weil sie nicht kontinuierlich "messen",
sondern alle x-Sekunden einen Augenblickswert ausgeben.
Ob dein Backup in vertretbarer Geschwindigkeit läuft, könnte viel eher ein
kompletter lauf zeigen:
Ausgangsdatenmenge
Gesamtlaufzeit
Datengröße auf Zielsystem
PS: Ein Partitionsimage zu schreiben isr eine Menge Holz jeden Tag; ich
arbeite lieber auf Dateiebene (z. B. rsync), was nur beim erstenmal viel,
danach nur geänderte Daten überträgt.
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 9:30:02 AM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
>> Welche Raten hast du?
>
> partclone lesen und nach /dev/null schieben 10GB in 60 Sekunden
>
> partclone lesen, pipen nach pigz und von da nach /dev/null ca. 180
> Sekunden
>
> partclone lesen, pipen nach pigz und von da per 100Mbit/s auf den
> Server 500 Sekunden
Wenn die Datei auf dem Zielsystem nun ca. 5 GB hätte, wäre das doch das
>
> partclone lesen und nach /dev/null schieben 10GB in 60 Sekunden
>
> partclone lesen, pipen nach pigz und von da nach /dev/null ca. 180
> Sekunden
>
> partclone lesen, pipen nach pigz und von da per 100Mbit/s auf den
> Server 500 Sekunden
Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
> Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
> 'komprimieren' und 'auf den Server schreiben' wechselt...
Du darfst das auch gerne mal vom Monitor abfilmen und irgendwo bereitlegen.
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 9:40:02 AM11/2/22
to
Hallo Thomas,
Thomas wrote:
> Ich habe über Dein Problem noch nie nachgedacht...
Solange eine Sache erwartbar lange dauert, mache ich mir auch keinen Kopf
darüber, wie der Kernel das regelt.
Erstens gibt es durchaus auch noch andere Sachen, die dazu parallel laufen,
so dass Tasks auch nur gewisse CPU-Zeit zugeteilt bekommen. Feinheiten kann
man über nice regeln, also dem Backupprozess damit mehr CPU-Zeit zuteilen.
Mehrere CPU-Kerne vermindern natürlich das Schalten zwischen den Tasks.
> In meiner Vorstellung ist eine Pipe ein Rohr: Ein Prozess schiebt Daten
> in das Rohr und ein zweiter nimmt die Daten heraus.
Ja.
> Wenn alles passt (der Erzeuger-Prozess schiebt die Daten mit 10Mb/s, die
> Pipe kann 10Mb/s empfangen, die Pipe kann 10Mb/s schreiben, der
> Datensenke-Prozess kann 10Mb/s empfangen), könnte ich mir vorstellen,
> das sowohl der Erzeuger-Prozess als auch der Datensenke-Prozess
> "gleichzeitig" die CPU nutzen.
>
> Wie verwaltet das Betriebssystem eine Pipe? Können beide Prozesse
> "gleichzeitig" schreiben und lesen? Darf immer nur ein Prozess auf die
> Pipe zugreifen?
Habe da nicht wirklich eine Vorstellung man wird das aber nachlesen können.
Ob also partclone den Speicherbereich der Pipe für sich sperrt und
vollschreibt, dann freigibt und der Zipper nun Daten entnehmen darf, wobei
er dann auch einen Lock durchführt.
Oder pusht partclone Daten in den Speicher einfach rein, solange der Bereich
noch nicht (Zeiger) auf das letzte Byte des Speicherbereichs zeigt;
gleichzeitig am Ausgang sich der Zipper bedient und der Kernel für jedes
gelesene Byte den Zeiger wieder zurückholt, ...
Ohne regelnde Instanz gehts nicht, denn es führt zur Datenverlust, wenn
einfach gefüllt wird und der Speicher überläuft. Wäre im Netzverkehr nicht
sowas wie das UDP-Protokoll, dass nicht wirklich abgesichert ist - anders
als TCP?
> Wenn ich mir die Pipe wie einen Eimer vorstelle, kann der
> Erzeuger-Prozess nur so viele Daten schrieben, bis der Eimer voll ist.
Oder man läßt ihn überlaufen -> Datenverlust.
Kann ja durchaus sinnvoll sein, wenn man Messdaten in Echtzeit verarbeiten
muss. Dann wären die aktuellen Daten wichtiger als das verspätete
Verarbeiten längst veralteter Daten.
> Auf der anderen Seite kann der Datensenke-Prozess nur so viele Daten
> lesen, wie im Eimer sind. Kann man nicht in den
> Betriebssystem-Parametern festlegen, wie groß der "Eimer" (technisch
> würde ich das Buffer size nennen) einer/aller Pipes sein soll? Ich würde
> schätzen, je größer der Eimer Deiner Pipe ist, desto mehr Parallelität
> wirst Du in htop sehen.
Grundsätzlich stimme ich dir zu, aber htop ist nicht wirklich dazu geeignet,
Echtzeitwerte eines Systems zu liefern.
--
Gruß Marcus
Thomas wrote:
> Ich habe über Dein Problem noch nie nachgedacht...
darüber, wie der Kernel das regelt.
Erstens gibt es durchaus auch noch andere Sachen, die dazu parallel laufen,
so dass Tasks auch nur gewisse CPU-Zeit zugeteilt bekommen. Feinheiten kann
man über nice regeln, also dem Backupprozess damit mehr CPU-Zeit zuteilen.
Mehrere CPU-Kerne vermindern natürlich das Schalten zwischen den Tasks.
> In meiner Vorstellung ist eine Pipe ein Rohr: Ein Prozess schiebt Daten
> in das Rohr und ein zweiter nimmt die Daten heraus.
> Wenn alles passt (der Erzeuger-Prozess schiebt die Daten mit 10Mb/s, die
> Pipe kann 10Mb/s empfangen, die Pipe kann 10Mb/s schreiben, der
> Datensenke-Prozess kann 10Mb/s empfangen), könnte ich mir vorstellen,
> das sowohl der Erzeuger-Prozess als auch der Datensenke-Prozess
> "gleichzeitig" die CPU nutzen.
>
> Wie verwaltet das Betriebssystem eine Pipe? Können beide Prozesse
> "gleichzeitig" schreiben und lesen? Darf immer nur ein Prozess auf die
> Pipe zugreifen?
Ob also partclone den Speicherbereich der Pipe für sich sperrt und
vollschreibt, dann freigibt und der Zipper nun Daten entnehmen darf, wobei
er dann auch einen Lock durchführt.
Oder pusht partclone Daten in den Speicher einfach rein, solange der Bereich
noch nicht (Zeiger) auf das letzte Byte des Speicherbereichs zeigt;
gleichzeitig am Ausgang sich der Zipper bedient und der Kernel für jedes
gelesene Byte den Zeiger wieder zurückholt, ...
Ohne regelnde Instanz gehts nicht, denn es führt zur Datenverlust, wenn
einfach gefüllt wird und der Speicher überläuft. Wäre im Netzverkehr nicht
sowas wie das UDP-Protokoll, dass nicht wirklich abgesichert ist - anders
als TCP?
> Wenn ich mir die Pipe wie einen Eimer vorstelle, kann der
> Erzeuger-Prozess nur so viele Daten schrieben, bis der Eimer voll ist.
Kann ja durchaus sinnvoll sein, wenn man Messdaten in Echtzeit verarbeiten
muss. Dann wären die aktuellen Daten wichtiger als das verspätete
Verarbeiten längst veralteter Daten.
> Auf der anderen Seite kann der Datensenke-Prozess nur so viele Daten
> lesen, wie im Eimer sind. Kann man nicht in den
> Betriebssystem-Parametern festlegen, wie groß der "Eimer" (technisch
> würde ich das Buffer size nennen) einer/aller Pipes sein soll? Ich würde
> schätzen, je größer der Eimer Deiner Pipe ist, desto mehr Parallelität
> wirst Du in htop sehen.
Echtzeitwerte eines Systems zu liefern.
--
Gruß Marcus
Stefan Puschek
Nov 2, 2022, 9:55:38 AM11/2/22
to
Hallo Marcus,
ich habe aber auch 22GB-Backups von einer anderen Maschine
aber die Grösse ist doch egal: es geht darum, dass er nicht
gleichzeitig komprimiert UND den Output wegschreibt sondern immer
ENTWEDER ODER
und ich will halt wissen, warum das so ist :)
> > Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
> > 'komprimieren' und 'auf den Server schreiben' wechselt...
>
> Woher entnimmst du, dass 10-20 Sekunden zwischen den Tasks gewechselt
> wird?
man sieht es im htop oder top, man hört es wenn beim komprimieren der
Lüfter läuft und beim schreiben (sieht man im iftop) wieder ausgeht
> Du darfst das auch gerne mal vom Monitor abfilmen und irgendwo
> bereitlegen.
mangels Kamera wird das nix...
Groetjes
Stefan
>
> >> Welche Raten hast du?
> >
> > partclone lesen und nach /dev/null schieben 10GB in 60 Sekunden
> >
> > partclone lesen, pipen nach pigz und von da nach /dev/null ca. 180
> > Sekunden
> >
> > partclone lesen, pipen nach pigz und von da per 100Mbit/s auf den
> > Server 500 Sekunden
>
> Wenn die Datei auf dem Zielsystem nun ca. 5 GB hätte, wäre das doch
> das Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
bei dieser Maschine 3,8GB
> >> Welche Raten hast du?
> >
> > partclone lesen und nach /dev/null schieben 10GB in 60 Sekunden
> >
> > partclone lesen, pipen nach pigz und von da nach /dev/null ca. 180
> > Sekunden
> >
> > partclone lesen, pipen nach pigz und von da per 100Mbit/s auf den
> > Server 500 Sekunden
>
> Wenn die Datei auf dem Zielsystem nun ca. 5 GB hätte, wäre das doch
> das Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
ich habe aber auch 22GB-Backups von einer anderen Maschine
aber die Grösse ist doch egal: es geht darum, dass er nicht
gleichzeitig komprimiert UND den Output wegschreibt sondern immer
ENTWEDER ODER
und ich will halt wissen, warum das so ist :)
> > Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
> > 'komprimieren' und 'auf den Server schreiben' wechselt...
>
> Woher entnimmst du, dass 10-20 Sekunden zwischen den Tasks gewechselt
> wird?
Lüfter läuft und beim schreiben (sieht man im iftop) wieder ausgeht
> Du darfst das auch gerne mal vom Monitor abfilmen und irgendwo
> bereitlegen.
Groetjes
Stefan
Stefan Puschek
Nov 2, 2022, 10:13:47 AM11/2/22
to
Hallo Marcus,
> > partclone kopiert nur die belegten Blöcke - für ein Backup reicht
> > das
> >
> >> >>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
> >> >>> der Server mit $DESTDIR ist leider nur per 100Mbit/s
> >> >>> angebunden.
> >>
> >> Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann
> >> sie komprimieren mit gzip oder dem anderen?
> >
> > SATA-SSD :)
> > partclone liest von der Partition 10GB in 60Sekunden und schiebt den
> > Output nach /dev/null
>
> Und wie lange dauert es, wenn du es vor /dev/null noch durch den
> Komprimierer schiebst?
180 Sekunden
> > pigz nutzt 128KB Blocksize laut man-page
> >
> >> Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster
> >> mit der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst
> >> werden - innerhalb eines Blocks. Wenn da jetzt ein 4k block mit
> >> daten und dann ein 4k block mit leerstellen kommen und dein
> >> komprimierer arbeitet NICHT mit 4k blockgröße...!
> >
> > aber das erklärt nicht, warum er alle 10-20 Sekunden zwischen
> > komprimieren und speichern wechselt - in 10 Sekunden schreibt er 110
> > MEGABYTE - also die Blöcke sind VIEL kleiner...
>
> htop ist garantiert nicht dazu geeignet, anzuzeigen, ob ein Prozess
> garnichts tut, wenn er nicht ganz oben in der Liste ist.
>
> Wenn das Ausgangssystem schnell genug ist, die Komprimierung in sowas
> wie Echtzeit durchzuführen - siehe oben den Test mit zip nach
> /dev/null - käme nun noch die Netzwerkschnittstelle ins Spiel.
Moment: von Echtzeit kann ja keine Rede sein: Komprimieren ohne
schreiben des Outputs hat immerhin einen Sprung von +120 Sekunden
verursacht; wenn pigz läuft, sehe ich 4 Threads mit fast 100%
CPU-Auslastung - wenn er den Output auf den Server schreibt,
verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter geht
aus
> > aber ich habs auch mal auf meinem Desktop versucht:
> > Ryzen5 5600X, 32GB RAM, per GbE an den Server angebunden und
> > ähnliches Ergebnis: entweder er komprimiert oder er speichert -
> > aber NIEMALS gleichzeitig :(
>
> Woher weißt du, dass der andere Prozess garnichts tut?
>
> Nur weil er nicht oben in htop erscheint?
>
> > Aber es bleibt die Frage: warum kann er nicht gleichzeitig
> > komprimieren UND den Output wegschreiben...
>
> Ein Block muss erst komplett "komprimiert" sein, dann kann pigz den
> ausgeben und die Netzwerkschnittstelle ausgeben. Ist der Block
> weggeschrieben, was keine Last in pigz verursachen wird, wird er
> vermutlich ziemlich flott übertragen, was auch keine große Last
> verursachen wird und bei der relativ kleinen Blockgröße auch ziemlich
> schnell gehen soll.
>
> Um genau zu prüfen, wer zu welchem Zeitpunkt was und wieviel tut,
> sind Tools wie top etc. eher kaum geeignet, weil sie nicht
> kontinuierlich "messen", sondern alle x-Sekunden einen
> Augenblickswert ausgeben.
das Update-Interval steht auf 1 Sekunde
> Ob dein Backup in vertretbarer Geschwindigkeit läuft, könnte viel
> eher ein kompletter lauf zeigen:
>
> Ausgangsdatenmenge
unkomprimiert 10GB
komprimiert 3,8GB
> Gesamtlaufzeit
500 Sekunden
> Datengröße auf Zielsystem
genau die 3,8GB
und 3,8GB mit 11,7MByte/s schreiben dauert nur 324 Sekunden
> PS: Ein Partitionsimage zu schreiben isr eine Menge Holz jeden Tag;
> ich arbeite lieber auf Dateiebene (z. B. rsync), was nur beim
> erstenmal viel, danach nur geänderte Daten überträgt.
ich mache das nicht jeden Tag; das ist nur eine Art von
Sicher-ist-sicher-Backup, wenn mal eine SSD stirbt - oder ich Mist
gebaut habe.
Diese Backups haben mir schon mehrfach "den Arsch gerettet" :)
deshalb mache ich das bei ALLEN Maschinen (nicht die Server!!)
Groetjes
Stefan
> > partclone kopiert nur die belegten Blöcke - für ein Backup reicht
> > das
> >
> >> >>> komprimieren soll pigz (gzip hatte ich auch schon probiert),
> >> >>> der Server mit $DESTDIR ist leider nur per 100Mbit/s
> >> >>> angebunden.
> >>
> >> Wie schnell kann deine HW denn von disk lesen? Und wie schnell kann
> >> sie komprimieren mit gzip oder dem anderen?
> >
> > SATA-SSD :)
> > partclone liest von der Partition 10GB in 60Sekunden und schiebt den
> > Output nach /dev/null
>
> Und wie lange dauert es, wenn du es vor /dev/null noch durch den
> Komprimierer schiebst?
> > pigz nutzt 128KB Blocksize laut man-page
> >
> >> Komprimiert wird ja meist durch ersetzen der häufigsten Bitmuster
> >> mit der kürzesten Sequenz. Diese matrix kann m.W. auch angepasst
> >> werden - innerhalb eines Blocks. Wenn da jetzt ein 4k block mit
> >> daten und dann ein 4k block mit leerstellen kommen und dein
> >> komprimierer arbeitet NICHT mit 4k blockgröße...!
> >
> > aber das erklärt nicht, warum er alle 10-20 Sekunden zwischen
> > komprimieren und speichern wechselt - in 10 Sekunden schreibt er 110
> > MEGABYTE - also die Blöcke sind VIEL kleiner...
>
> htop ist garantiert nicht dazu geeignet, anzuzeigen, ob ein Prozess
> garnichts tut, wenn er nicht ganz oben in der Liste ist.
>
> Wenn das Ausgangssystem schnell genug ist, die Komprimierung in sowas
> wie Echtzeit durchzuführen - siehe oben den Test mit zip nach
> /dev/null - käme nun noch die Netzwerkschnittstelle ins Spiel.
schreiben des Outputs hat immerhin einen Sprung von +120 Sekunden
verursacht; wenn pigz läuft, sehe ich 4 Threads mit fast 100%
CPU-Auslastung - wenn er den Output auf den Server schreibt,
verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter geht
aus
> > aber ich habs auch mal auf meinem Desktop versucht:
> > Ryzen5 5600X, 32GB RAM, per GbE an den Server angebunden und
> > ähnliches Ergebnis: entweder er komprimiert oder er speichert -
> > aber NIEMALS gleichzeitig :(
>
> Woher weißt du, dass der andere Prozess garnichts tut?
>
> Nur weil er nicht oben in htop erscheint?
>
> > Aber es bleibt die Frage: warum kann er nicht gleichzeitig
> > komprimieren UND den Output wegschreiben...
>
> Ein Block muss erst komplett "komprimiert" sein, dann kann pigz den
> ausgeben und die Netzwerkschnittstelle ausgeben. Ist der Block
> weggeschrieben, was keine Last in pigz verursachen wird, wird er
> vermutlich ziemlich flott übertragen, was auch keine große Last
> verursachen wird und bei der relativ kleinen Blockgröße auch ziemlich
> schnell gehen soll.
>
> Um genau zu prüfen, wer zu welchem Zeitpunkt was und wieviel tut,
> sind Tools wie top etc. eher kaum geeignet, weil sie nicht
> kontinuierlich "messen", sondern alle x-Sekunden einen
> Augenblickswert ausgeben.
> Ob dein Backup in vertretbarer Geschwindigkeit läuft, könnte viel
> eher ein kompletter lauf zeigen:
>
> Ausgangsdatenmenge
komprimiert 3,8GB
> Gesamtlaufzeit
500 Sekunden
> Datengröße auf Zielsystem
genau die 3,8GB
und 3,8GB mit 11,7MByte/s schreiben dauert nur 324 Sekunden
> PS: Ein Partitionsimage zu schreiben isr eine Menge Holz jeden Tag;
> ich arbeite lieber auf Dateiebene (z. B. rsync), was nur beim
> erstenmal viel, danach nur geänderte Daten überträgt.
Sicher-ist-sicher-Backup, wenn mal eine SSD stirbt - oder ich Mist
gebaut habe.
Diese Backups haben mir schon mehrfach "den Arsch gerettet" :)
deshalb mache ich das bei ALLEN Maschinen (nicht die Server!!)
Groetjes
Stefan
Stefan Puschek
Nov 2, 2022, 10:31:22 AM11/2/22
to
Hi @ all,
ich bin wohl nicht allein mit dem Problem:
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
Groetjes
Stefan
ich bin wohl nicht allein mit dem Problem:
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
Groetjes
Stefan
Marcus Röckrath
Nov 2, 2022, 10:50:02 AM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
>> Wenn die Datei auf dem Zielsystem nun ca. 5 GB hätte, wäre das doch
>> das Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
>
> bei dieser Maschine 3,8GB
Was zwar nicht der maximale mögliche Übertragunswert wäre, aber auch kein
>> das Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
>
> bei dieser Maschine 3,8GB
dramatischer Einbruch wäre, da die Maschine ja eventuell noch andere Daten
überträgt, zudem ja auch Verwaltungsoverhead dazukommt.
> ich habe aber auch 22GB-Backups von einer anderen Maschine
> aber die Grösse ist doch egal: es geht darum, dass er nicht
> gleichzeitig komprimiert UND den Output wegschreibt sondern immer
> ENTWEDER ODER
>
> und ich will halt wissen, warum das so ist :)
größer als x sein, also wird geswitcht.
Zudem kann pigz einen Block an den Puffer der Netzwerkkarte übergeben, wenn
der überhaupt Daten aufnehmen kann.
Um die ganzen Abläufe genau erklären zu können, bin ich nicht kenntnisreich
genug. Der oben genannten Wert liegt im Bereich des Erwartbaren, womit ich
kein Problem sehe.
Man darf nicht die Vorstellung haben, dass Task 1 (partclone) exklusiv einen
Kern hat, der ebenfalls an den exklusiv pigz zur Verfügung stehenden Kern
übergibt und dann sich auch ein dritter Kern exklusiv um die
Datenübertragung auf der Netzschnittstelle kümmert, die zudem noch andere
Daten austauschen wird, ...
>> > Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
>> > 'komprimieren' und 'auf den Server schreiben' wechselt...
kompletten Vorgang nicht sein!
Wenn das so wäre, dann würde ja in etwa 30 Sekunden jeweils einmal pigz und
die Datenübertragung vorkommen, also in 500 Sekunden also etwa 15 mal
dieser Switch passieren, also in 15 einzelnen Vorgängen jeweils der ein
15tel der Eingangsmenge (10 GB / 15 = ~600 MB von partclone angeliefert;
von pigz dann diese in diesen großen Packen verarbeitet und dann in 15
Einzelschritten dann jeweils 250 MB übertragen werden).
Die Taskwechsel geschehen auf CPU-Eebene viel häufiger und schneller und
zeigt nur, dass Werkzeuge wie top und Co, solche Nanosekunden-Vorgänge
garnicht abbilden können.
Was passiert ohne Komprimierung? Das wird dann vielleicht 400+ Sekunden
dauern.
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 11:00:02 AM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> Moment: von Echtzeit kann ja keine Rede sein: Komprimieren ohne
> schreiben des Outputs hat immerhin einen Sprung von +120 Sekunden
> verursacht;
Daten von einem Datenträger lesen ist bestimmt eine kaum belastende Aufgabe,
> schreiben des Outputs hat immerhin einen Sprung von +120 Sekunden
> verursacht;
als einen Datenstrom zu komprimieren.
Für mich ganz normal.
> wenn pigz läuft, sehe ich 4 Threads mit fast 100%
> CPU-Auslastung - wenn er den Output auf den Server schreibt,
> verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter geht
> aus
gerade (in Summe aller Netzwerkkarten) rund 10 MByte/s.
>> Um genau zu prüfen, wer zu welchem Zeitpunkt was und wieviel tut,
>> sind Tools wie top etc. eher kaum geeignet, weil sie nicht
>> kontinuierlich "messen", sondern alle x-Sekunden einen
>> Augenblickswert ausgeben.
>
> das Update-Interval steht auf 1 Sekunde
werden.
Du kannst mit nice deinen Prozessen natürlich eine höhere Priorität geben.
>> Ob dein Backup in vertretbarer Geschwindigkeit läuft, könnte viel
>> eher ein kompletter lauf zeigen:
>>
>> Ausgangsdatenmenge
> unkomprimiert 10GB
> komprimiert 3,8GB
>
>> Gesamtlaufzeit
> 500 Sekunden
>
>> Datengröße auf Zielsystem
> genau die 3,8GB
>
> und 3,8GB mit 11,7MByte/s schreiben dauert nur 324 Sekunden
Wie schon gesagt: Ich halte das erhaltene Ergebnis für gut genug.
--
Gruß Marcus
Stefan Puschek
Nov 2, 2022, 11:01:05 AM11/2/22
to
Hallo Marcus,
> >> Wenn die Datei auf dem Zielsystem nun ca. 5 GB hätte, wäre das doch
> >> das Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
> >
> > bei dieser Maschine 3,8GB
>
> Was zwar nicht der maximale mögliche Übertragunswert wäre, aber auch
> kein dramatischer Einbruch wäre, da die Maschine ja eventuell noch
> andere Daten überträgt, zudem ja auch Verwaltungsoverhead dazukommt.
das ist ein Rettungssystem auf USB-Stick: der macht sonst nix
> > ich habe aber auch 22GB-Backups von einer anderen Maschine
>
> Das braucht dann halt etwa 2500 Sekunden.
kann ich nicht vergleichen: diese Maschine hat GbE zum Server,
komprimiert stärker und hat einen Ryzen 5600X
ist alles klar - aber die genannten Werte passen schon
> Was passiert ohne Komprimierung? Das wird dann vielleicht 400+
> Sekunden dauern.
dann hat er etwas über 900 Sekunden gebraucht - passt zu 10GB und
11,7MByte/s
Aber wie mittlerweile gefunden:
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
das könnte der Verursacher sein
Groetjes
Stefan
> >> Wenn die Datei auf dem Zielsystem nun ca. 5 GB hätte, wäre das doch
> >> das Maximum. Wie groß ist denn die Backupdatei auf dem Zielsystem?
> >
> > bei dieser Maschine 3,8GB
>
> Was zwar nicht der maximale mögliche Übertragunswert wäre, aber auch
> kein dramatischer Einbruch wäre, da die Maschine ja eventuell noch
> andere Daten überträgt, zudem ja auch Verwaltungsoverhead dazukommt.
> > ich habe aber auch 22GB-Backups von einer anderen Maschine
>
> Das braucht dann halt etwa 2500 Sekunden.
komprimiert stärker und hat einen Ryzen 5600X
> Was passiert ohne Komprimierung? Das wird dann vielleicht 400+
> Sekunden dauern.
11,7MByte/s
Aber wie mittlerweile gefunden:
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
das könnte der Verursacher sein
Groetjes
Stefan
Marcus Röckrath
Nov 2, 2022, 11:30:03 AM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> ich bin wohl nicht allein mit dem Problem:
>
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
Wieso Problem?
>
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
Dort macht sich jemand ähnliche Gedanken, wie du.
Es gibt aber keinen echten Zahlen, an denen man ableiten kann, ob irgendeine
Stelle langsamer als theoretisch erwartbar ist.
In den Erläuterungen sind Gesichtspunkte genannt, die auch hier schon eine
Rolle gespielt haben.
Der Vorgang kann sicherlich nicht als gleichmäßig laufende Flüssigkeit
verstanden werden, dazu arbeiten die Teile der Kette in Blöcken, die zudem
nicht die gleiche Größe haben.
pigz nimmt sich davon z. B. immer eine Kaffeetasse davon, dampft die zu
einem Espresso zusammen und gibt dann den ganzen Espresso auf einmal
weiter.
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 11:30:03 AM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
>> Was passiert ohne Komprimierung? Das wird dann vielleicht 400+
>> Sekunden dauern.
>
> dann hat er etwas über 900 Sekunden gebraucht - passt zu 10GB und
> 11,7MByte/s
Stimmt, meine 400s bezogen sich auf die 3,8GB, aber ohne Komprimierung sind
>> Sekunden dauern.
>
> dann hat er etwas über 900 Sekunden gebraucht - passt zu 10GB und
> 11,7MByte/s
es ja 10 GB.
Runtergerechnet auf 3,8 GB Datenübertragung sind es etwas 350s. Der Rest
bist 500 geht somit auf die Komprimierung und die Pie zurück.
Ich sehe hier weiterhin kein wirklichen Performanceproblem.
> Aber wie mittlerweile gefunden:
>
https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
>
> das könnte der Verursacher sein
Da wirden doch nur Gesichtspunkte genannt, die generell eine Rolle spielen,
aber bei weitem nicht als problematisch, ... bezeichnet werden.
Vielleicht gibt es auch Komprimierer, die schneller arbeiten; mal gz, ...
probiert?
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 12:00:03 PM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> wenn pigz läuft, sehe ich 4 Threads mit fast 100%
> CPU-Auslastung - wenn er den Output auf den Server schreibt,
> verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter geht
> aus
Lasten die 4 Threads auch alle Kernel aus, oder gibt es noch weitere
> CPU-Auslastung - wenn er den Output auf den Server schreibt,
> verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter geht
> aus
CPU-Kerne?
Ob es eine gute Idee ist, einem Prozess zu erlauben dann auch alle Kerne zu
benutzen, scheint mir nicht optimal, denn dann ruhen, in der Zeit alle
weiteren Prozesse.
Allerdings kann auch dann pigz nicht durchgehend 10-20 Sekunden laufen, auch
wenn das die htop Ausgabe suggeriert. Zu den anderen wahrscheinlich eher
weniger rechenintensiven Task wird auch da durchgeschaltet.
--
Gruß Marcus
Thomas
Nov 2, 2022, 12:19:09 PM11/2/22
to
bis die Pipe voll ist. Sonst würde das mit der Erwartung eines
"vollständigen" Backup mit Kompression widersprechen.
Thomas
Nov 2, 2022, 12:30:55 PM11/2/22
to
Wenn ich nach "linux pipe buffer size" im Internet suche, finde ich
viele Seiten zu dem Thema. Die beziehen sich auf named pipes, müssten
aber auch für die "normalen" Pipes in der Shell gelten:
https://www.golinuxhub.com/2018/05/how-to-view-and-increase-default-pipe-size-buffer/
https://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer
https://www.cyberciti.biz/faq/linux-tcp-tuning/
Die letzte Seite finde ich besonders interessant, weil sie auch über die
Größe "des Eimers" für die Netzwerkschnittstellen spricht.
Meine Vermutung ist: Wenn alle Eimer groß genug sind, dürften die Lüfter
nur so lange stillstehen, bis der Datenlieferant neue anliefert.
Gruß
Thomas
Stefan Puschek
Nov 2, 2022, 12:55:06 PM11/2/22
to
Hallo Marcus,
> >> Was passiert ohne Komprimierung? Das wird dann vielleicht 400+
> >> Sekunden dauern.
> >
> > dann hat er etwas über 900 Sekunden gebraucht - passt zu 10GB und
> > 11,7MByte/s
>
> Stimmt, meine 400s bezogen sich auf die 3,8GB, aber ohne
> Komprimierung sind es ja 10 GB.
>
> Runtergerechnet auf 3,8 GB Datenübertragung sind es etwas 350s. Der
> Rest bist 500 geht somit auf die Komprimierung und die Pie zurück.
>
> Ich sehe hier weiterhin kein wirklichen Performanceproblem.
von Performance-Problem habe ich auch nie geschrieben
> > Aber wie mittlerweile gefunden:
> >
> https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
> >
> > das könnte der Verursacher sein
>
> Welche Aussage meinst du da genau?
Why does tar -c dir | pigz > /mnt/nfs/dir.tgz use network, then cpu in
cycles instead of both at once (with one bottlenecking)
...
You might be forgetting the fact that in UNIX/Linux a process can only
do only a single BLOCKING I/O operation at a time. There is no
concurrent read or write operations contained in either the tar or the
compress functions. Nor is there any processing of data within either
of these two processes during its I/O calls.
There are buffering filters that attempt to lessen this effect by using
shared memory and 2 processes: one to read and the other to write.
> Da wirden doch nur Gesichtspunkte genannt, die generell eine Rolle
> spielen, aber bei weitem nicht als problematisch, ... bezeichnet
> werden.
mit den buffering filters werde ich mal testen: buffer und pv
> Vielleicht gibt es auch Komprimierer, die schneller arbeiten; mal gz,
> ... probiert?
den nicht - hole ich nach
xz habe ich probiert: als nach 10 Minuten nur 20% erledigt waren, habe
ich abgebrochen
pigz ist wohl grundsätzlich recht schnell, weil er für jeden CPU-core
bzw. -Thread einen eigenen Thread nutzt.
Groetjes
Stefan
> >> Was passiert ohne Komprimierung? Das wird dann vielleicht 400+
> >> Sekunden dauern.
> >
> > dann hat er etwas über 900 Sekunden gebraucht - passt zu 10GB und
> > 11,7MByte/s
>
> Stimmt, meine 400s bezogen sich auf die 3,8GB, aber ohne
> Komprimierung sind es ja 10 GB.
>
> Runtergerechnet auf 3,8 GB Datenübertragung sind es etwas 350s. Der
> Rest bist 500 geht somit auf die Komprimierung und die Pie zurück.
>
> Ich sehe hier weiterhin kein wirklichen Performanceproblem.
> > Aber wie mittlerweile gefunden:
> >
> https://serverfault.com/questions/321273/why-does-tar-c-dir-pigz-mnt-nfs-dir-tgz-use-network-then-cpu-in-cycles-in
> >
> > das könnte der Verursacher sein
>
> Welche Aussage meinst du da genau?
cycles instead of both at once (with one bottlenecking)
...
You might be forgetting the fact that in UNIX/Linux a process can only
do only a single BLOCKING I/O operation at a time. There is no
concurrent read or write operations contained in either the tar or the
compress functions. Nor is there any processing of data within either
of these two processes during its I/O calls.
There are buffering filters that attempt to lessen this effect by using
shared memory and 2 processes: one to read and the other to write.
> Da wirden doch nur Gesichtspunkte genannt, die generell eine Rolle
> spielen, aber bei weitem nicht als problematisch, ... bezeichnet
> werden.
> Vielleicht gibt es auch Komprimierer, die schneller arbeiten; mal gz,
> ... probiert?
xz habe ich probiert: als nach 10 Minuten nur 20% erledigt waren, habe
ich abgebrochen
pigz ist wohl grundsätzlich recht schnell, weil er für jeden CPU-core
bzw. -Thread einen eigenen Thread nutzt.
Groetjes
Stefan
Stefan Puschek
Nov 2, 2022, 12:57:53 PM11/2/22
to
Hallo Marcus,:
> Allerdings kann auch dann pigz nicht durchgehend 10-20 Sekunden
> laufen, auch wenn das die htop Ausgabe suggeriert. Zu den anderen
> wahrscheinlich eher weniger rechenintensiven Task wird auch da
> durchgeschaltet.
auch klar.
Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
speichert. Nicht mehr und nicht weniger.
Groetjes
Stefan
>
> > wenn pigz läuft, sehe ich 4 Threads mit fast 100%
> > CPU-Auslastung - wenn er den Output auf den Server schreibt,
> > verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter
> > geht aus
>
> Lasten die 4 Threads auch alle Kernel aus, oder gibt es noch weitere
> CPU-Kerne?
>
> Ob es eine gute Idee ist, einem Prozess zu erlauben dann auch alle
> Kerne zu benutzen, scheint mir nicht optimal, denn dann ruhen, in der
> Zeit alle weiteren Prozesse.
das ist der Default von pigz
> > wenn pigz läuft, sehe ich 4 Threads mit fast 100%
> > CPU-Auslastung - wenn er den Output auf den Server schreibt,
> > verschwinden im htop (oder top) alle pigz-Threads - und der Lüfter
> > geht aus
>
> Lasten die 4 Threads auch alle Kernel aus, oder gibt es noch weitere
> CPU-Kerne?
>
> Ob es eine gute Idee ist, einem Prozess zu erlauben dann auch alle
> Kerne zu benutzen, scheint mir nicht optimal, denn dann ruhen, in der
> Zeit alle weiteren Prozesse.
> Allerdings kann auch dann pigz nicht durchgehend 10-20 Sekunden
> laufen, auch wenn das die htop Ausgabe suggeriert. Zu den anderen
> wahrscheinlich eher weniger rechenintensiven Task wird auch da
> durchgeschaltet.
Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
speichert. Nicht mehr und nicht weniger.
Groetjes
Stefan
Marcus Röckrath
Nov 2, 2022, 1:10:02 PM11/2/22
to
Hallo Thomas,
Thomas wrote:
>>> Wenn ich mir die Pipe wie einen Eimer vorstelle, kann der
>>> Erzeuger-Prozess nur so viele Daten schrieben, bis der Eimer voll ist.
>>
>> Oder man läßt ihn überlaufen -> Datenverlust.
>
> Nicht bei einer Pipe. Der Erzeuger-Prozess darf nur so lange schreiben,
> bis die Pipe voll ist. Sonst würde das mit der Erwartung eines
> "vollständigen" Backup mit Kompression widersprechen.
Das war von mir auch nicht als sinnvoller Vorschlag für das Backupszenario
gemeint. :-)
--
Gruß Marcus
Thomas wrote:
>>> Wenn ich mir die Pipe wie einen Eimer vorstelle, kann der
>>> Erzeuger-Prozess nur so viele Daten schrieben, bis der Eimer voll ist.
>>
>> Oder man läßt ihn überlaufen -> Datenverlust.
>
> Nicht bei einer Pipe. Der Erzeuger-Prozess darf nur so lange schreiben,
> bis die Pipe voll ist. Sonst würde das mit der Erwartung eines
> "vollständigen" Backup mit Kompression widersprechen.
gemeint. :-)
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 1:20:02 PM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
> speichert. Nicht mehr und nicht weniger.
Weil ein Block erst komplett komprimiert werden muss, bevor der
> speichert. Nicht mehr und nicht weniger.
Ergebnisblock geschrieben wird.
Komprimierung funktioniert doch nicht so, dass ein Byte reinfliesst und dann
dieses Byte wieder komprimiert ausgegeben wird.
Außerdem führt die Arbeit mit mehreren Threads, dass das Ergebniss erst dann
feststeht, wenn alle Threads ihren teil der Arbeit getan haben:
"Pigz compresses using threads to make use of multiple processors and cores.
The input is broken up into 128 KB chunks with each compressed in parallel.
The individual check value for each chunk is also calculated in parallel.
The compressed data is written in order to the output, and a combined check
value is calculated from the individual check values."
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 1:20:02 PM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
> pigz ist wohl grundsätzlich recht schnell, weil er für jeden CPU-core
> bzw. -Thread einen eigenen Thread nutzt.
gzip gilt auch alt recht schnell; andere Komprimierer schaffenm deutlich
> bzw. -Thread einen eigenen Thread nutzt.
bessere Komprimierungsfaktoren, was aber den Rechenaufwand erhöht.
Die Threads müssen mit dem vorab auf die Threads unterteilten Chunk aber
auch alle fertigwerden, denn aus den x Einzelergebnissen, wird ein
gemeinsames Ausgabeergebnis berechnet (siehe Ziat aus der Manpage gepostet
in meiner anderen Antwort).
--
Gruß Marcus
Marcus Röckrath
Nov 2, 2022, 1:20:03 PM11/2/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
>> Vielleicht gibt es auch Komprimierer, die schneller arbeiten; mal gz,
>> ... probiert?
>
> den nicht - hole ich nach
>
> xz habe ich probiert: als nach 10 Minuten nur 20% erledigt waren, habe
> ich abgebrochen
Hier
>> ... probiert?
>
> den nicht - hole ich nach
>
> xz habe ich probiert: als nach 10 Minuten nur 20% erledigt waren, habe
> ich abgebrochen
https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/
gibt es einen Vergleich verschiedener Komprimierer - es wird deutlich klar,
dass kleinere Archivdatei deutlich zulasten der Geschwindigkeit geht.
--
Gruß Marcus
Kay Martinen
Nov 3, 2022, 1:50:02 PM11/3/22
to
Am 02.11.22 um 18:11 schrieb Marcus Röckrath:
kontinuierlichen Datenstrom hin optimiert sind? Ich denke da an
Audio/Video Streaming oder das Entschlüsseln eines DVD Inhaltes. Mir
wäre jetzt aber auch kein Name dazu präsent.
> Außerdem führt die Arbeit mit mehreren Threads, dass das Ergebniss erst dann
> feststeht, wenn alle Threads ihren teil der Arbeit getan haben:
Das ist mir auch gleich aufgefallen als er die 4 Threads erwähnte.
Vielleicht wäre es gut das mal auf nur einen Thread zu limitieren. Dann
könnte man Wartezeiten auf parallele Rechnungen ausschließen.
> "Pigz compresses using threads to make use of multiple processors and cores.
> The input is broken up into 128 KB chunks with each compressed in parallel.
> The individual check value for each chunk is also calculated in parallel.
> The compressed data is written in order to the output, and a combined check
> value is calculated from the individual check values."
Das würde ich mal so verstehen das man die Eingangs-Blockgröße
idealerweise auf ein vielfaches von 128kB einstellen sollte - wenn
möglich. Wobei das vielfache nicht höher als die Zahl der CPU-Kerne sein
dürfte.
> Stefan Puschek wrote:
>
>> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
>> speichert. Nicht mehr und nicht weniger.
>
> Weil ein Block erst komplett komprimiert werden muss, bevor der
> Ergebnisblock geschrieben wird.
>
> Komprimierung funktioniert doch nicht so, dass ein Byte reinfliesst und dann
> dieses Byte wieder komprimiert ausgegeben wird.
Gibt es nicht komprimierungs-tools die da mehr auf einen
>
>> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
>> speichert. Nicht mehr und nicht weniger.
>
> Weil ein Block erst komplett komprimiert werden muss, bevor der
> Ergebnisblock geschrieben wird.
>
> Komprimierung funktioniert doch nicht so, dass ein Byte reinfliesst und dann
> dieses Byte wieder komprimiert ausgegeben wird.
kontinuierlichen Datenstrom hin optimiert sind? Ich denke da an
Audio/Video Streaming oder das Entschlüsseln eines DVD Inhaltes. Mir
wäre jetzt aber auch kein Name dazu präsent.
> Außerdem führt die Arbeit mit mehreren Threads, dass das Ergebniss erst dann
> feststeht, wenn alle Threads ihren teil der Arbeit getan haben:
Vielleicht wäre es gut das mal auf nur einen Thread zu limitieren. Dann
könnte man Wartezeiten auf parallele Rechnungen ausschließen.
> "Pigz compresses using threads to make use of multiple processors and cores.
> The input is broken up into 128 KB chunks with each compressed in parallel.
> The individual check value for each chunk is also calculated in parallel.
> The compressed data is written in order to the output, and a combined check
> value is calculated from the individual check values."
idealerweise auf ein vielfaches von 128kB einstellen sollte - wenn
möglich. Wobei das vielfache nicht höher als die Zahl der CPU-Kerne sein
dürfte.
Stefan Puschek
Nov 3, 2022, 2:38:04 PM11/3/22
to
Hallo Marcus und Kay,
> > Außerdem führt die Arbeit mit mehreren Threads, dass das Ergebniss
> > erst dann feststeht, wenn alle Threads ihren teil der Arbeit getan
> > haben:
>
> Das ist mir auch gleich aufgefallen als er die 4 Threads erwähnte.
> Vielleicht wäre es gut das mal auf nur einen Thread zu limitieren.
> Dann könnte man Wartezeiten auf parallele Rechnungen ausschließen.
hatte ich schon gemacht: entweder komprimieren 1, 2 oder 3 Cores oder
er speichert auf dem Server - und es dauert länger
> > "Pigz compresses using threads to make use of multiple processors
> > and cores. The input is broken up into 128 KB chunks with each
> > compressed in parallel. The individual check value for each chunk
> > is also calculated in parallel. The compressed data is written in
> > order to the output, and a combined check value is calculated from
> > the individual check values."
>
> Das würde ich mal so verstehen das man die Eingangs-Blockgröße
> idealerweise auf ein vielfaches von 128kB einstellen sollte - wenn
> möglich. Wobei das vielfache nicht höher als die Zahl der CPU-Kerne
> sein dürfte.
das habe ich auch probiert (128k bis 1M), brachte nichts, ausser dass er
länger gebraucht hat.
Nachdem ich jetzt den ganzen Nachmittag mit buffer und pv getestet
habe, weiss ich nicht mehr weiter: ich gebe auf.
Euch beiden vielen Dank für viele gute IDeen, aber er will sich nicht
überlisten lassen :(
Groetjes
Stefan
> >
> >> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
> >> speichert. Nicht mehr und nicht weniger.
> >
> > Weil ein Block erst komplett komprimiert werden muss, bevor der
> > Ergebnisblock geschrieben wird.
> >
> > Komprimierung funktioniert doch nicht so, dass ein Byte reinfliesst
> > und dann dieses Byte wieder komprimiert ausgegeben wird.
>
> Gibt es nicht komprimierungs-tools die da mehr auf einen
> kontinuierlichen Datenstrom hin optimiert sind? Ich denke da an
> Audio/Video Streaming oder das Entschlüsseln eines DVD Inhaltes. Mir
> wäre jetzt aber auch kein Name dazu präsent.
keine Ahnung...
> >> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
> >> speichert. Nicht mehr und nicht weniger.
> >
> > Weil ein Block erst komplett komprimiert werden muss, bevor der
> > Ergebnisblock geschrieben wird.
> >
> > Komprimierung funktioniert doch nicht so, dass ein Byte reinfliesst
> > und dann dieses Byte wieder komprimiert ausgegeben wird.
>
> Gibt es nicht komprimierungs-tools die da mehr auf einen
> kontinuierlichen Datenstrom hin optimiert sind? Ich denke da an
> Audio/Video Streaming oder das Entschlüsseln eines DVD Inhaltes. Mir
> wäre jetzt aber auch kein Name dazu präsent.
> > Außerdem führt die Arbeit mit mehreren Threads, dass das Ergebniss
> > erst dann feststeht, wenn alle Threads ihren teil der Arbeit getan
> > haben:
>
> Das ist mir auch gleich aufgefallen als er die 4 Threads erwähnte.
> Vielleicht wäre es gut das mal auf nur einen Thread zu limitieren.
> Dann könnte man Wartezeiten auf parallele Rechnungen ausschließen.
er speichert auf dem Server - und es dauert länger
> > "Pigz compresses using threads to make use of multiple processors
> > and cores. The input is broken up into 128 KB chunks with each
> > compressed in parallel. The individual check value for each chunk
> > is also calculated in parallel. The compressed data is written in
> > order to the output, and a combined check value is calculated from
> > the individual check values."
>
> Das würde ich mal so verstehen das man die Eingangs-Blockgröße
> idealerweise auf ein vielfaches von 128kB einstellen sollte - wenn
> möglich. Wobei das vielfache nicht höher als die Zahl der CPU-Kerne
> sein dürfte.
länger gebraucht hat.
Nachdem ich jetzt den ganzen Nachmittag mit buffer und pv getestet
habe, weiss ich nicht mehr weiter: ich gebe auf.
Euch beiden vielen Dank für viele gute IDeen, aber er will sich nicht
überlisten lassen :(
Groetjes
Stefan
Kay Martinen
Nov 4, 2022, 12:10:02 PM11/4/22
to
Am 03.11.22 um 19:38 schrieb Stefan Puschek:
bringt aber nur der Vollständigkeit halber hier mal eine mail die mir
mein Proxmox VE sendet wenn er mit dem Backup einer 4 GB VM fertig ist.
Zwischen Quelle und Ziel liegt eine Powerline-Strecke die im Idealfall
so um die 300 Megabit/sek. liefert. Mal mehr mal weniger. Das ist dann
*nur* das dreifache deines 100Mbit Links.
> 105: 2022-10-29 23:00:02 INFO: Starting Backup of VM 105 (qemu)
> 105: 2022-10-29 23:00:02 INFO: status = running
> 105: 2022-10-29 23:00:02 INFO: VM Name: OpenHab2
> 105: 2022-10-29 23:00:02 INFO: include disk 'scsi0' 'local-lvm:vm-105-disk-0' 4G
> 105: 2022-10-29 23:00:03 INFO: backup mode: snapshot
> 105: 2022-10-29 23:00:03 INFO: ionice priority: 7
> 105: 2022-10-29 23:00:03 INFO: creating vzdump archive '/mnt/pve/PVEC/dump/vzdump-qemu-105-2022_10_29-23_00_02.vma.lzo'
> 105: 2022-10-29 23:00:03 INFO: issuing guest-agent 'fs-freeze' command
> 105: 2022-10-29 23:00:03 INFO: issuing guest-agent 'fs-thaw' command
> 105: 2022-10-29 23:00:03 INFO: started backup task 'f2e430db-b58f-460f-a99a-df6fadb90329'
> 105: 2022-10-29 23:00:03 INFO: resuming VM again
> 105: 2022-10-29 23:00:06 INFO: 4% (174.0 MiB of 4.0 GiB) in 3s, read: 58.0 MiB/s, write: 36.5 MiB/s
> 105: 2022-10-29 23:00:09 INFO: 7% (297.2 MiB of 4.0 GiB) in 6s, read: 41.1 MiB/s, write: 41.1 MiB/s
> 105: 2022-10-29 23:00:12 INFO: 10% (427.8 MiB of 4.0 GiB) in 9s, read: 43.5 MiB/s, write: 40.5 MiB/s
> 105: 2022-10-29 23:00:15 INFO: 13% (547.9 MiB of 4.0 GiB) in 12s, read: 40.1 MiB/s, write: 37.0 MiB/s
> 105: 2022-10-29 23:00:18 INFO: 16% (668.8 MiB of 4.0 GiB) in 15s, read: 40.3 MiB/s, write: 40.0 MiB/s
> 105: 2022-10-29 23:00:21 INFO: 19% (790.8 MiB of 4.0 GiB) in 18s, read: 40.6 MiB/s, write: 40.6 MiB/s
> 105: 2022-10-29 23:00:24 INFO: 22% (916.7 MiB of 4.0 GiB) in 21s, read: 42.0 MiB/s, write: 41.6 MiB/s
> 105: 2022-10-29 23:00:27 INFO: 25% (1.0 GiB of 4.0 GiB) in 24s, read: 39.8 MiB/s, write: 39.5 MiB/s
> 105: 2022-10-29 23:00:30 INFO: 28% (1.1 GiB of 4.0 GiB) in 27s, read: 39.2 MiB/s, write: 38.7 MiB/s
> 105: 2022-10-29 23:00:33 INFO: 29% (1.2 GiB of 4.0 GiB) in 30s, read: 23.9 MiB/s, write: 23.4 MiB/s
> 105: 2022-10-29 23:00:36 INFO: 30% (1.2 GiB of 4.0 GiB) in 33s, read: 6.0 MiB/s, write: 6.0 MiB/s
> 105: 2022-10-29 23:00:39 INFO: 33% (1.3 GiB of 4.0 GiB) in 36s, read: 41.2 MiB/s, write: 41.2 MiB/s
> 105: 2022-10-29 23:00:42 INFO: 36% (1.5 GiB of 4.0 GiB) in 39s, read: 41.1 MiB/s, write: 40.6 MiB/s
> 105: 2022-10-29 23:00:45 INFO: 38% (1.5 GiB of 4.0 GiB) in 42s, read: 28.9 MiB/s, write: 28.8 MiB/s
> 105: 2022-10-29 23:00:48 INFO: 41% (1.6 GiB of 4.0 GiB) in 45s, read: 37.5 MiB/s, write: 37.5 MiB/s
> 105: 2022-10-29 23:00:51 INFO: 44% (1.8 GiB of 4.0 GiB) in 48s, read: 39.8 MiB/s, write: 39.7 MiB/s
> 105: 2022-10-29 23:00:54 INFO: 47% (1.9 GiB of 4.0 GiB) in 51s, read: 40.9 MiB/s, write: 40.9 MiB/s
> 105: 2022-10-29 23:00:57 INFO: 50% (2.0 GiB of 4.0 GiB) in 54s, read: 44.9 MiB/s, write: 42.0 MiB/s
> 105: 2022-10-29 23:01:01 INFO: 53% (2.1 GiB of 4.0 GiB) in 58s, read: 27.8 MiB/s, write: 26.4 MiB/s
> 105: 2022-10-29 23:01:05 INFO: 54% (2.2 GiB of 4.0 GiB) in 1m 2s, read: 9.3 MiB/s, write: 9.3 MiB/s
> 105: 2022-10-29 23:01:08 INFO: 57% (2.3 GiB of 4.0 GiB) in 1m 5s, read: 44.0 MiB/s, write: 44.0 MiB/s
> 105: 2022-10-29 23:01:11 INFO: 59% (2.4 GiB of 4.0 GiB) in 1m 8s, read: 32.1 MiB/s, write: 32.1 MiB/s
> 105: 2022-10-29 23:01:15 INFO: 60% (2.4 GiB of 4.0 GiB) in 1m 12s, read: 7.2 MiB/s, write: 7.2 MiB/s
> 105: 2022-10-29 23:01:18 INFO: 62% (2.5 GiB of 4.0 GiB) in 1m 15s, read: 33.7 MiB/s, write: 31.2 MiB/s
> 105: 2022-10-29 23:01:21 INFO: 65% (2.6 GiB of 4.0 GiB) in 1m 18s, read: 41.4 MiB/s, write: 41.4 MiB/s
> 105: 2022-10-29 23:01:24 INFO: 68% (2.7 GiB of 4.0 GiB) in 1m 21s, read: 38.8 MiB/s, write: 38.8 MiB/s
> 105: 2022-10-29 23:01:27 INFO: 71% (2.9 GiB of 4.0 GiB) in 1m 24s, read: 39.1 MiB/s, write: 39.0 MiB/s
> 105: 2022-10-29 23:01:30 INFO: 74% (3.0 GiB of 4.0 GiB) in 1m 27s, read: 44.2 MiB/s, write: 44.2 MiB/s
> 105: 2022-10-29 23:01:33 INFO: 77% (3.1 GiB of 4.0 GiB) in 1m 30s, read: 38.1 MiB/s, write: 33.1 MiB/s
> 105: 2022-10-29 23:01:36 INFO: 80% (3.2 GiB of 4.0 GiB) in 1m 33s, read: 40.2 MiB/s, write: 38.9 MiB/s
> 105: 2022-10-29 23:01:39 INFO: 100% (4.0 GiB of 4.0 GiB) in 1m 36s, read: 265.8 MiB/s, write: 20.6 MiB/s
> 105: 2022-10-29 23:01:39 INFO: backup is sparse: 866.85 MiB (21%) total zero data
> 105: 2022-10-29 23:01:39 INFO: transferred 4.00 GiB in 96 seconds (42.7 MiB/s)
> 105: 2022-10-29 23:01:42 INFO: archive file size: 1.58GB
> 105: 2022-10-29 23:01:42 INFO: Finished Backup of VM 105 (00:01:40)
Wie man sehen kann sind 4 GB Die Ausgangsgröße die er mit LZO auf 1,58
GB eindampft und für runde 42,7 MBit pro Sekunde dann 1 minute 40 Sek.
(also 100 Sekunden) braucht. Dabei macht er einen Snapshot (AFAIR per
LVM) und der Quellhost hat Zwei Octacore Xeons, 32 GB RAM und arbeitet
auf einem HW Raid1 aus 2,5" S-ATA Platten + eine einzelne 500 GB
Der hat natürlich GbE, hängt auch an einem solchen Switch aber dann
kommt die PWL-Verbindung als Engpaß und ein Weitere GbE Switch von dem
es dann (mit GbE) auf den nfs-server geht. Der hat einen 4 Kern Pentium
und 4 GB RAM und div. S-ATA Platten.
Ich kann dem auch über die WebUI zusehen und sehe dann wie die einzelnen
obigen Zeilen jeweils einzeln auftauchen. Allerdings habe ich da nie mit
(h)top nachgeschaut ob die Last zyklisch hoch und runter geht weil der
vielleicht; wie bei dir; zwischen komprimieren und übertragen wechselte.
Da der Engpaß für mich unvermeidbar ist habe ich damit auch kein Problem
- weil die Backups sowieso automatisch laufen. Ich weiß zwar wann, aber
mich interessiert da nur das es klappte.
> Hallo Marcus und Kay,
>>>
>>>> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
>>>> speichert. Nicht mehr und nicht weniger.
>>>
>>>> Aber ich will doch nur wissen, warum pigz entweder komprimiert ODER
>>>> speichert. Nicht mehr und nicht weniger.
>> Gibt es nicht komprimierungs-tools die da mehr auf einen
>> kontinuierlichen Datenstrom hin optimiert sind?
>> kontinuierlichen Datenstrom hin optimiert sind?
> Nachdem ich jetzt den ganzen Nachmittag mit buffer und pv getestet
> habe, weiss ich nicht mehr weiter: ich gebe auf.
>
> Euch beiden vielen Dank für viele gute IDeen, aber er will sich nicht
> überlisten lassen :(
Ich weiß ja nicht ob dir das vielleicht weiter hilft oder eine Idee
> habe, weiss ich nicht mehr weiter: ich gebe auf.
>
> Euch beiden vielen Dank für viele gute IDeen, aber er will sich nicht
> überlisten lassen :(
bringt aber nur der Vollständigkeit halber hier mal eine mail die mir
mein Proxmox VE sendet wenn er mit dem Backup einer 4 GB VM fertig ist.
Zwischen Quelle und Ziel liegt eine Powerline-Strecke die im Idealfall
so um die 300 Megabit/sek. liefert. Mal mehr mal weniger. Das ist dann
*nur* das dreifache deines 100Mbit Links.
> 105: 2022-10-29 23:00:02 INFO: Starting Backup of VM 105 (qemu)
> 105: 2022-10-29 23:00:02 INFO: status = running
> 105: 2022-10-29 23:00:02 INFO: VM Name: OpenHab2
> 105: 2022-10-29 23:00:02 INFO: include disk 'scsi0' 'local-lvm:vm-105-disk-0' 4G
> 105: 2022-10-29 23:00:03 INFO: backup mode: snapshot
> 105: 2022-10-29 23:00:03 INFO: ionice priority: 7
> 105: 2022-10-29 23:00:03 INFO: creating vzdump archive '/mnt/pve/PVEC/dump/vzdump-qemu-105-2022_10_29-23_00_02.vma.lzo'
> 105: 2022-10-29 23:00:03 INFO: issuing guest-agent 'fs-freeze' command
> 105: 2022-10-29 23:00:03 INFO: issuing guest-agent 'fs-thaw' command
> 105: 2022-10-29 23:00:03 INFO: started backup task 'f2e430db-b58f-460f-a99a-df6fadb90329'
> 105: 2022-10-29 23:00:03 INFO: resuming VM again
> 105: 2022-10-29 23:00:06 INFO: 4% (174.0 MiB of 4.0 GiB) in 3s, read: 58.0 MiB/s, write: 36.5 MiB/s
> 105: 2022-10-29 23:00:09 INFO: 7% (297.2 MiB of 4.0 GiB) in 6s, read: 41.1 MiB/s, write: 41.1 MiB/s
> 105: 2022-10-29 23:00:12 INFO: 10% (427.8 MiB of 4.0 GiB) in 9s, read: 43.5 MiB/s, write: 40.5 MiB/s
> 105: 2022-10-29 23:00:15 INFO: 13% (547.9 MiB of 4.0 GiB) in 12s, read: 40.1 MiB/s, write: 37.0 MiB/s
> 105: 2022-10-29 23:00:18 INFO: 16% (668.8 MiB of 4.0 GiB) in 15s, read: 40.3 MiB/s, write: 40.0 MiB/s
> 105: 2022-10-29 23:00:21 INFO: 19% (790.8 MiB of 4.0 GiB) in 18s, read: 40.6 MiB/s, write: 40.6 MiB/s
> 105: 2022-10-29 23:00:24 INFO: 22% (916.7 MiB of 4.0 GiB) in 21s, read: 42.0 MiB/s, write: 41.6 MiB/s
> 105: 2022-10-29 23:00:27 INFO: 25% (1.0 GiB of 4.0 GiB) in 24s, read: 39.8 MiB/s, write: 39.5 MiB/s
> 105: 2022-10-29 23:00:30 INFO: 28% (1.1 GiB of 4.0 GiB) in 27s, read: 39.2 MiB/s, write: 38.7 MiB/s
> 105: 2022-10-29 23:00:33 INFO: 29% (1.2 GiB of 4.0 GiB) in 30s, read: 23.9 MiB/s, write: 23.4 MiB/s
> 105: 2022-10-29 23:00:36 INFO: 30% (1.2 GiB of 4.0 GiB) in 33s, read: 6.0 MiB/s, write: 6.0 MiB/s
> 105: 2022-10-29 23:00:39 INFO: 33% (1.3 GiB of 4.0 GiB) in 36s, read: 41.2 MiB/s, write: 41.2 MiB/s
> 105: 2022-10-29 23:00:42 INFO: 36% (1.5 GiB of 4.0 GiB) in 39s, read: 41.1 MiB/s, write: 40.6 MiB/s
> 105: 2022-10-29 23:00:45 INFO: 38% (1.5 GiB of 4.0 GiB) in 42s, read: 28.9 MiB/s, write: 28.8 MiB/s
> 105: 2022-10-29 23:00:48 INFO: 41% (1.6 GiB of 4.0 GiB) in 45s, read: 37.5 MiB/s, write: 37.5 MiB/s
> 105: 2022-10-29 23:00:51 INFO: 44% (1.8 GiB of 4.0 GiB) in 48s, read: 39.8 MiB/s, write: 39.7 MiB/s
> 105: 2022-10-29 23:00:54 INFO: 47% (1.9 GiB of 4.0 GiB) in 51s, read: 40.9 MiB/s, write: 40.9 MiB/s
> 105: 2022-10-29 23:00:57 INFO: 50% (2.0 GiB of 4.0 GiB) in 54s, read: 44.9 MiB/s, write: 42.0 MiB/s
> 105: 2022-10-29 23:01:01 INFO: 53% (2.1 GiB of 4.0 GiB) in 58s, read: 27.8 MiB/s, write: 26.4 MiB/s
> 105: 2022-10-29 23:01:05 INFO: 54% (2.2 GiB of 4.0 GiB) in 1m 2s, read: 9.3 MiB/s, write: 9.3 MiB/s
> 105: 2022-10-29 23:01:08 INFO: 57% (2.3 GiB of 4.0 GiB) in 1m 5s, read: 44.0 MiB/s, write: 44.0 MiB/s
> 105: 2022-10-29 23:01:11 INFO: 59% (2.4 GiB of 4.0 GiB) in 1m 8s, read: 32.1 MiB/s, write: 32.1 MiB/s
> 105: 2022-10-29 23:01:15 INFO: 60% (2.4 GiB of 4.0 GiB) in 1m 12s, read: 7.2 MiB/s, write: 7.2 MiB/s
> 105: 2022-10-29 23:01:18 INFO: 62% (2.5 GiB of 4.0 GiB) in 1m 15s, read: 33.7 MiB/s, write: 31.2 MiB/s
> 105: 2022-10-29 23:01:21 INFO: 65% (2.6 GiB of 4.0 GiB) in 1m 18s, read: 41.4 MiB/s, write: 41.4 MiB/s
> 105: 2022-10-29 23:01:24 INFO: 68% (2.7 GiB of 4.0 GiB) in 1m 21s, read: 38.8 MiB/s, write: 38.8 MiB/s
> 105: 2022-10-29 23:01:27 INFO: 71% (2.9 GiB of 4.0 GiB) in 1m 24s, read: 39.1 MiB/s, write: 39.0 MiB/s
> 105: 2022-10-29 23:01:30 INFO: 74% (3.0 GiB of 4.0 GiB) in 1m 27s, read: 44.2 MiB/s, write: 44.2 MiB/s
> 105: 2022-10-29 23:01:33 INFO: 77% (3.1 GiB of 4.0 GiB) in 1m 30s, read: 38.1 MiB/s, write: 33.1 MiB/s
> 105: 2022-10-29 23:01:36 INFO: 80% (3.2 GiB of 4.0 GiB) in 1m 33s, read: 40.2 MiB/s, write: 38.9 MiB/s
> 105: 2022-10-29 23:01:39 INFO: 100% (4.0 GiB of 4.0 GiB) in 1m 36s, read: 265.8 MiB/s, write: 20.6 MiB/s
> 105: 2022-10-29 23:01:39 INFO: backup is sparse: 866.85 MiB (21%) total zero data
> 105: 2022-10-29 23:01:39 INFO: transferred 4.00 GiB in 96 seconds (42.7 MiB/s)
> 105: 2022-10-29 23:01:42 INFO: archive file size: 1.58GB
> 105: 2022-10-29 23:01:42 INFO: Finished Backup of VM 105 (00:01:40)
Wie man sehen kann sind 4 GB Die Ausgangsgröße die er mit LZO auf 1,58
GB eindampft und für runde 42,7 MBit pro Sekunde dann 1 minute 40 Sek.
(also 100 Sekunden) braucht. Dabei macht er einen Snapshot (AFAIR per
LVM) und der Quellhost hat Zwei Octacore Xeons, 32 GB RAM und arbeitet
auf einem HW Raid1 aus 2,5" S-ATA Platten + eine einzelne 500 GB
Der hat natürlich GbE, hängt auch an einem solchen Switch aber dann
kommt die PWL-Verbindung als Engpaß und ein Weitere GbE Switch von dem
es dann (mit GbE) auf den nfs-server geht. Der hat einen 4 Kern Pentium
und 4 GB RAM und div. S-ATA Platten.
Ich kann dem auch über die WebUI zusehen und sehe dann wie die einzelnen
obigen Zeilen jeweils einzeln auftauchen. Allerdings habe ich da nie mit
(h)top nachgeschaut ob die Last zyklisch hoch und runter geht weil der
vielleicht; wie bei dir; zwischen komprimieren und übertragen wechselte.
Da der Engpaß für mich unvermeidbar ist habe ich damit auch kein Problem
- weil die Backups sowieso automatisch laufen. Ich weiß zwar wann, aber
mich interessiert da nur das es klappte.
Stefan Puschek
Nov 5, 2022, 6:33:05 AM11/5/22
to
Hallo Kay,
> Ich weiß ja nicht ob dir das vielleicht weiter hilft oder eine Idee
> bringt aber nur der Vollständigkeit halber hier mal eine mail die mir
> mein Proxmox VE sendet wenn er mit dem Backup einer 4 GB VM fertig
> ist.
>
> Zwischen Quelle und Ziel liegt eine Powerline-Strecke die im
> Idealfall so um die 300 Megabit/sek. liefert. Mal mehr mal weniger.
> Das ist dann *nur* das dreifache deines 100Mbit Links.
DAS hätte ich auch gerne gehabt: aber die beiden damals gekauften
Adapter haben sich auf dieser Strecke bei mir nicht einaml gesehen,
also noch schlechter als langsaaaaam :(
ich kann es leider auch nicht ändern - aber ich kann damit leben, dass
bei dem Backup entweder komprimiert ODER geschrieben wird.
Groetjesund vielen Dank nochmal
Stefan
> Ich weiß ja nicht ob dir das vielleicht weiter hilft oder eine Idee
> bringt aber nur der Vollständigkeit halber hier mal eine mail die mir
> mein Proxmox VE sendet wenn er mit dem Backup einer 4 GB VM fertig
> ist.
>
> Zwischen Quelle und Ziel liegt eine Powerline-Strecke die im
> Idealfall so um die 300 Megabit/sek. liefert. Mal mehr mal weniger.
> Das ist dann *nur* das dreifache deines 100Mbit Links.
Adapter haben sich auf dieser Strecke bei mir nicht einaml gesehen,
also noch schlechter als langsaaaaam :(
bei dem Backup entweder komprimiert ODER geschrieben wird.
Groetjesund vielen Dank nochmal
Stefan
Marcus Röckrath
Nov 5, 2022, 9:10:03 AM11/5/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
>> > Aber all das erklärt nicht, warum er immer 10-20 Sekunden zwischen
>> > 'komprimieren' und 'auf den Server schreiben' wechselt...
>>
>> Woher entnimmst du, dass 10-20 Sekunden zwischen den Tasks gewechselt
>> wird?
>
> man sieht es im htop oder top, man hört es wenn beim komprimieren der
> Lüfter läuft und beim schreiben (sieht man im iftop) wieder ausgeht
Du könntest auf dem Zielsystem in einer Konsole auch mal
>> > 'komprimieren' und 'auf den Server schreiben' wechselt...
>>
>> Woher entnimmst du, dass 10-20 Sekunden zwischen den Tasks gewechselt
>> wird?
>
> man sieht es im htop oder top, man hört es wenn beim komprimieren der
> Lüfter läuft und beim schreiben (sieht man im iftop) wieder ausgeht
while true ; do ls -la pfad/../.../zieldatei ; done
laufen lassen, ob da wirklich längere Zeit keine Größenänderung der
Zieldatei festzustellen ist.
--
Gruß Marcus
Stefan Puschek
Nov 5, 2022, 9:22:51 AM11/5/22
to
Hallo Marcus,
darauf bin ich auch schon gekommen, weil ich am Server dem iftop nicht
getraut habe...
auch zur Sicherheit noch ein sync in der Schleife hat nicht geholfen...
Groetjes
Stefan
getraut habe...
auch zur Sicherheit noch ein sync in der Schleife hat nicht geholfen...
Groetjes
Stefan
Marcus Röckrath
Nov 5, 2022, 2:00:03 PM11/5/22
to
Hallo Stefan,
Stefan Puschek wrote:
Stefan Puschek wrote:
>> Du könntest auf dem Zielsystem in einer Konsole auch mal
>>
>> while true ; do ls -la pfad/../.../zieldatei ; done
>>
>> laufen lassen, ob da wirklich längere Zeit keine Größenänderung der
>> Zieldatei festzustellen ist.
>
> darauf bin ich auch schon gekommen, weil ich am Server dem iftop nicht
> getraut habe...
>
> auch zur Sicherheit noch ein sync in der Schleife hat nicht geholfen...
Helfen soll es auch nicht, sondern zeigen,, ob da wirklich 10-20 Sekunden
>>
>> while true ; do ls -la pfad/../.../zieldatei ; done
>>
>> laufen lassen, ob da wirklich längere Zeit keine Größenänderung der
>> Zieldatei festzustellen ist.
>
> darauf bin ich auch schon gekommen, weil ich am Server dem iftop nicht
> getraut habe...
>
> auch zur Sicherheit noch ein sync in der Schleife hat nicht geholfen...
die Datei nicht größer wird.
--
Gruß Marcus
Uwe Z.
Nov 6, 2022, 7:50:40 AM11/6/22
to
Moin Stefan!
Am 05.11.2022 um 11:33 schriebst du:
Phasen hast (steht im Zweifel auf deinem Stromzähler) und die
Powerline-Adapter hängen in unterschiedlichen Phasen, kann das durchaus
passieren. Da hilft dann nur eine Phasenbrücke (für Powerline) vom
freundlichen Elektriker des geringsten Misstrauens.
--
Viele Grüße
Uwe
Am 05.11.2022 um 11:33 schriebst du:
> DAS hätte ich auch gerne gehabt: aber die beiden damals gekauften
> Adapter haben sich auf dieser Strecke bei mir nicht einaml gesehen,
> also noch schlechter als langsaaaaam :(
Sicher, dass die an der gleichen Pahse hingen? Wenn du zu Hause drei
> Adapter haben sich auf dieser Strecke bei mir nicht einaml gesehen,
> also noch schlechter als langsaaaaam :(
Phasen hast (steht im Zweifel auf deinem Stromzähler) und die
Powerline-Adapter hängen in unterschiedlichen Phasen, kann das durchaus
passieren. Da hilft dann nur eine Phasenbrücke (für Powerline) vom
freundlichen Elektriker des geringsten Misstrauens.
--
Viele Grüße
Uwe
Kay Martinen
Nov 6, 2022, 10:40:04 AM11/6/22
to
Am 06.11.22 um 13:50 schrieb Uwe Z.:
Probieren. In einer Reihe der Typischen Verteilung passen 12 Automaten.
Die sind üblicherweise mit einer 3-Phasenschiene gekoppelt. Das heißt es
geht links beim ersten Automaten mit L1 los, dann L2 dann L3 und der
vierte ist wieder L1. Der Zwölfte am Ende ist dann wieder L3. Übrigens
unabhängig davon ob es wirklich L1 ist die auf dem Ersten läge. Die
Abfolge 1,2,3,1,2,3 ist durch die Schiene vorgegeben und man braucht nur
den passenden Stromkreis nach Beschriftung oder Probieren (Ausschalten
und sehen wo was aus ist) versuchen.
Wenn L1 jetzt Licht Wohnraum ist und der vierte Automat Licht küche und
man wollte vom Wohnraum in die Küche per Powerline, dann muß man die
Adapter an den Steckdosen unter den Lichtschaltern von Wohnraum und
Küche probieren. Lichtkreise werden gern zusammen gefasst, Steckdosen
weniger und eher getrennt abgesichert. Küche und Bad sind auch oft getrennt.
Gleiche gälte also für Steckdosen-Kreise. Die Chance ist da recht groß
das man an beiden Enden eine Steckdose erwischen kann die nur über die
Automaten aber an der gleichen Phase hängt. Dann braucht man keinen
Phasenkoppler. So heißen diese "Brücken" übrigens. Nötig ist nur hin
sehen und Probieren.
Koppler gab es auch schon für die Wechselsprechgeräte in den 80'n. Nur
das die dort mit ca. 180KHz modulierten und nicht mit dem breiten
Spektrum von neuen PWL-Adaptern.
> Moin Stefan!
>
> Am 05.11.2022 um 11:33 schriebst du:
>> DAS hätte ich auch gerne gehabt: aber die beiden damals gekauften
>> Adapter haben sich auf dieser Strecke bei mir nicht einaml gesehen,
>> also noch schlechter als langsaaaaam :(
>
> Sicher, dass die an der gleichen Phase hingen? Wenn du zu Hause drei
>
> Am 05.11.2022 um 11:33 schriebst du:
>> DAS hätte ich auch gerne gehabt: aber die beiden damals gekauften
>> Adapter haben sich auf dieser Strecke bei mir nicht einaml gesehen,
>> also noch schlechter als langsaaaaam :(
>
> Phasen hast (steht im Zweifel auf deinem Stromzähler) und die
> Powerline-Adapter hängen in unterschiedlichen Phasen, kann das durchaus
> passieren. Da hilft dann nur eine Phasenbrücke (für Powerline) vom
> freundlichen Elektriker des geringsten Misstrauens.
Oder der Blick auf den Sicherungskasten. Dann muß man zählen und
> Powerline-Adapter hängen in unterschiedlichen Phasen, kann das durchaus
> passieren. Da hilft dann nur eine Phasenbrücke (für Powerline) vom
> freundlichen Elektriker des geringsten Misstrauens.
Probieren. In einer Reihe der Typischen Verteilung passen 12 Automaten.
Die sind üblicherweise mit einer 3-Phasenschiene gekoppelt. Das heißt es
geht links beim ersten Automaten mit L1 los, dann L2 dann L3 und der
vierte ist wieder L1. Der Zwölfte am Ende ist dann wieder L3. Übrigens
unabhängig davon ob es wirklich L1 ist die auf dem Ersten läge. Die
Abfolge 1,2,3,1,2,3 ist durch die Schiene vorgegeben und man braucht nur
den passenden Stromkreis nach Beschriftung oder Probieren (Ausschalten
und sehen wo was aus ist) versuchen.
Wenn L1 jetzt Licht Wohnraum ist und der vierte Automat Licht küche und
man wollte vom Wohnraum in die Küche per Powerline, dann muß man die
Adapter an den Steckdosen unter den Lichtschaltern von Wohnraum und
Küche probieren. Lichtkreise werden gern zusammen gefasst, Steckdosen
weniger und eher getrennt abgesichert. Küche und Bad sind auch oft getrennt.
Gleiche gälte also für Steckdosen-Kreise. Die Chance ist da recht groß
das man an beiden Enden eine Steckdose erwischen kann die nur über die
Automaten aber an der gleichen Phase hängt. Dann braucht man keinen
Phasenkoppler. So heißen diese "Brücken" übrigens. Nötig ist nur hin
sehen und Probieren.
Koppler gab es auch schon für die Wechselsprechgeräte in den 80'n. Nur
das die dort mit ca. 180KHz modulierten und nicht mit dem breiten
Spektrum von neuen PWL-Adaptern.
0 new messages