Wie kann ich Prozesse beschleunigen?

Hallo,
bin neu hier, aber habe schon ein paar Jahrzehnte IT- und ein paar Monate Linux-Erfahrung. ;-)

Als Grundlage für eine verschlüsselte Festplatte beschreibe gerade 500GB mit Zufallsdaten. Das dauert ewig (6-7 Tage), aber der Prozessor arbeitet auch nicht wirklich. Er hat überwiegend 0%-2% Last, also Leerlauf, und nur ab und zu steigt das auf 10%-15% an. Weiterhin läuft er mit der halben Taktrate, in die er nur bei niedriger Last geht.
Ich weiß, dass das Erstellen von Zufallszahlen etwas dauert, aber das sollte dann doch auch mit Rechenlast verbunden sein, oder? Die Platte ist momentan mit USB2.0 angebunden, an der Schnittstelle sollte es also nicht liegen. Warum trödelt der Rechner so rum? Wenn er mehr Rechenleistung in den Prozess stecken würde, könnte er viel schneller fertig sein.

Meine Frage: Wie kann ich Befehle wie z.B.
dazu bringen, die verfügbare Rechenleistung optimal auszunutzen? Geht das mit weniger "nice"? Wenn ja, wie?

Systeminfo: (mein alter) Pentium M mit 1.6GHz, OpenSuse 10.2; zu beschreibende Platte: SATA, via USB 2.0 und PCMCIA-Adapter.

Vielen Dank schon vorab!
Markus

Schau dir mal die Manpage von "renice" an.

Wenn ich das richtig sehe, versucht dein Rechner jetzt eine Zufallszahl zu erstellen die genau auf deinen Plattenplatz passt. Versuche mal mit den Optionen bs und count ein bißchen zu spielen evtl geht es dann schnelller.

Graf Zahl schrieb:

Wenn er mehr Rechenleistung in den Prozess stecken würde, könnte er viel schneller fertig sein.

Zum Vergrößern anklicken....

ist nicht mal unbdingt gesagt, etwas vielleicht, ein Hauptproblem sind deine Optionen.
Um was geht es dir, den Rechner mal zum Qualmen zu bringen oder die Platte zu überschreiben?

Auch wenn deine Platte USB2 angeschlossen ist, heißt das nicht das da auch Daten jenseits von gut und böse drauf geschrieben werden können.
Mit einem Porsche kann man auf einem Waldweg auch keine 200km/h fahren, auch wenn der Motor erst bei 250 abregeln würde

Probier mal folgendes,
Platte ist hoffentlich komplett nicht mehr gemountet.

neue bash aufmachen, eine Namedpipe anlegen, (die Pipe möglichst aus Sicherheitsgründen nicht im Rootverzeichnis anlegen), einen dd Prozess aus der Pipe auf die Platte schreiben lassen und mit 10 Prozessen Zufallszahlen in die Pipe schreiben. Ich nenne die Pipe mal /tmp/testpipe und die Platte zum überschreiben sdc


Das kannst du dir dann ein bischen mit top oder was weiß ich anschauen, der dd Prozess mit der wahrscheinlich kleinsten ProzessID ist der der auf die Platte schreibt, Wenn du genug gesehen hast, dann
damit killst du den Prozess der auf die Platte schreibt, der beendet dann die anderen 10 Prozesse automatisch mit.

Viel Spaß beim staunen, hatte es eben mal so auf einer 4 Prozessormaschine am laufen, allerdings kein USB2. on Board.

robi

Ich würde mal mit dem Befehl top schauen wo es hängt. Vor allem die Zeile

• 
  Cpu(s): 3.0%us, 0.7%sy, 0.0%ni, 95.8%id, 0.3%wa, 0.0%hi, 0.2%si, 0.0%st

könnte helfen, am besten hier mal zeigen. Würde mich nicht wundern wenn vor wa ein großer Zahl steht.

Und mal nebenbei, mit nice wird kein Prozess schneller sondern erhält nur Vorrang vor anderen. Quasi wie ein Blaulicht bei der Polizei, dadurch werden deren Autos auch nicht schneller, aber die anderen müssen sie vorbei lassen.

Meine Frage: Wie kann ich Befehle wie z.B.

Code:

# dd if=/dev/urandom of=/dev/sdc

dazu bringen, die verfügbare Rechenleistung optimal auszunutzen? Geht das mit weniger "nice"? Wenn ja, wie?

Zum Vergrößern anklicken....

In dem du die Blocksize hochsetzt, denn je kleiner sie ist, desto mehr Systemcalls werden gemacht, und das wird ineffizient wenn man für jedes Byte oder Klumpen read() aufriefe. Standardmäßig ist bs 512 Bytes bei dd, bei dd_rescue hingegen schonmal sinnvollere 64K, deswegen sollte man letzteres Programm nehmen, zumal das auch eine Statusanzeige hat.

jengelh schrieb:

In dem du die Blocksize hochsetzt, denn je kleiner sie ist, desto mehr Systemcalls werden gemacht, und das wird ineffizient wenn man für jedes Byte oder Klumpen read() aufriefe. Standardmäßig ist bs 512 Bytes bei dd, bei dd_rescue hingegen schonmal sinnvollere 64K, deswegen sollte man letzteres Programm nehmen, zumal das auch eine Statusanzeige hat.

Zum Vergrößern anklicken....

Ist vom Prinzip richtig, bringt aber hier auch nicht allzuviel, wie man in dem kurzem Beipiel von mir oben sehr gut erkennen müsste, erzeugt der Aufruf von /dev/urandom nicht unbeträchtlich Systemlast. (vermutlich wird sie sogar vom Coprozessor getragen, während die eigentliche CPU darauf wartet.) Man kann hier durchaus mit Optionen spielen und wird in einem gewissen Grade durchaus Verbesserungen oder Verschlechterungen feststellen, aber keinen echten Durchbruch erreichen. Da es fast egal ist, ob ich diese Systemlast erzeuge indem ich nun nun jeweils in kurzer Zeit kleine Blöcke errechne, oder entsprechen länger brauche um großen Blöcke zu errechnen. Der Unterschied ist nur, es werden weniger Anfangs-Initialisierungen des Randomgenerators ausgeführt, die von dem Rechenaufwand durchaus ins Gewicht fallen. (Wesshalb auch in LINUX /dev/random hier absolut ungeeignet ist, da hier vor dem Erzeugen jeder einzelnen Zahl eine Neu-Initialisierung vorgenommen wird)

Wer hier wirklich an die Grenzen der Schreibgeschwindigkeit gehen will, hat fast keine andere Chance als zB eine große Randomdatei zu erzeugen die gerade so im Speicher komplett gecacht werden kann, und diese dann in einer Endlosschleife fortlaufend zB mit dd, dd_rescue, mbuffer oder anderen und einem vielfachen von 512 als Blockgröße auf die Platte zu schreiben (bis auf die meist gewünschte Blockung genausogut gänge aber auch cat oder die normale Konsolumleitung) . Der theroretische Sicherheitsverlust durch das wiederholte schreiben langer Zufallssequenzen ist minimal, und kann wenn wirklich notwendig auch noch verbessert werden. In der Zeit in der man eine Platte mit urandom neu vollgerechnet hätte, hat man so eine Platte schon mehrfach mit jeweils anderen Zufallssequenzen überschieben.


robi

robi schrieb:

Ist vom Prinzip richtig, bringt aber hier auch nicht allzuviel, wie man in dem kurzem Beipiel von mir oben sehr gut erkennen müsste, erzeugt der Aufruf von /dev/urandom nicht unbeträchtlich Systemlast. (vermutlich wird sie sogar vom Coprozessor getragen, während die eigentliche CPU darauf wartet.)

Zum Vergrößern anklicken....

Ja, in dem Falle ist die eigentliche Nummerngeneration das Bottleneck, da ist es nichtmal soviel Syscalls oder Re-Opens. Aber ich wollte ja auch generell bleiben, denn ab und zu kopiert man damit ja auch von und zu nicht-Pseudodevices, mit anderen Worten, Dateien oder Platten. Und die geben schon megabyteprosekundemäßig mehr ab als urandom.

Ich (der OP) entschuldige mich für die späte Antwort, zumal ich von der Geschwindigkeit, mit der die ersten Lösungsvorschläge gekommen sind, beeindruckt bin. Das lag ja im Minutenbereich, toll!

Ich habe Eure Vorschläge ausprobiert, um zu sehen, wie das funktioniert. Zusammenfassend die Eindrücke meiner Versuche:

1) renice klappte hier leider nicht. Ich nehme an, dass es daran liegt, dass der Rechner eh' kaum was tut, da nützt eine höhere prio wohl auch nichts - es wäre ja immer genug Platz, wenn dd mal etwas CPU-time will. Dennoch ist renice gut, ich habe das später mal woanders unter Vollast getestet - da glaube ich, Geschwindigkeitssteigerungen bei den weniger "nice"-en Prozessen zu erkennen. Wieder was gelernt...

2)
> Wenn ich das richtig sehe, versucht dein Rechner jetzt eine Zufallszahl zu erstellen
> die genau auf deinen Plattenplatz passt.
Ich glaube, dass das in vielen kleineren Schritten geschieht. Wenn ich dd in eine reale Datei schreiben lasse, wächst die Datei in kleineren Schritten an. Es werden aber auf keinen Fall 4GB-Blöcke auf einmal geschrieben (weil ich z.B. ca 4GB RAM hätte).

2b) Die Blocksize von dd scheint tatsächlich nicht der bottleneck zu sein, denn nach Abschluss der Aktion habe ich das Ganze mit 64k Blocksize angetestet (nur ca. 30min), aber ich konnte mit Hilfe von "pkill" keine Geschwindigkeitssteigerung feststellen.

Die CPU wurde übrigens auch nicht wegen thermischer Probleme gedrosselt, laut gkrellm lag T immer im grünen Bereich.

Auf einem anderen Rechner habe ich das ganze dann auch mal angetestet, da bekam/nutzte dd 60% eines Prozessors.

Leider habe ich also nicht herausgefunden, was da los ist, aber dennoch vielen Dank für Eure Antworten und Lösungsvorschläge! Ich habe die Platte jetzt einfach 7 Tage laufen lassen, und bin nun hoffentlich gut gegen böse Krypto-Angriffe geschützt. Des weiteren habt ihr mich angeregt, mich intensiver mit mir bisher unbekannten Funktionen von Linux auseinanderzusetzen - und das finde ich klasse.

Vielen Dank,
Markus