Puffergröße beim Dateikopieren

[Kr0e]

Hallo,

immer wieder hat mich verwundert, wieviel die Puffergröße beim Kopieren von Dateien von einer lokalen Festplatte auf eine andere lokale Festplatte ausmacht.

Ich meine jetzt nicht, dass es Vorteile bringt statt 128 byte Puffer einen 8192 byte Puffer zu benutzen. Ich meine, dass es (jenachdem welche Festplatten man hat!!) massive Unterschiede macht, ob man 32kb, 64kb oder vlt sogar 128kb benutzt.

Mein Problem ist, dass ich iwie das Gefühl hab, dass es da kein Patentrezept gibt, sondern es stark auf die Festplatte ankommt, die man benutzt.

Ich habe da ein paar Daten die bei einer recht gründlichen Testreihe entstanden sind:

Szenario:
900mb Datei auf Laufwerk C -> Kopieren auf Laufwerk D (Beides sind physikalische Laufwerke, beide SATA-II)
Die Laufwerke haben etwa eine Leistung um die 90-95 MB pro Sekunde. HD Tune hat diese Werte geliefert,
simples Kopieren mit Windows bestätigt dies.

Der Code:

        String file1 = "C:/test.ogg";
        String file2 = "D:/test.ogg";

        FileChannel input = new FileInputStream(file1).getChannel();
        FileChannel output = new FileOutputStream(file2).getChannel();

        ProgressFuture progress = new ProgressFuture(input.size());
        progress.addListener(new ProgressFutureListener() {

            public void operationUpdated(ProgressFuture future) throws Throwable {
                if (future.getLatestRateClock().getTimeValue(TimeUnit.Seconds) >= 1) {
                    System.out.println(future.getLatestRate(TimeUnit.Seconds));
                }
            }

            public void operationDone(ProgressFuture future) throws Throwable {
            }
        });

        ByteBuffer buffer = ByteBuffer.allocateDirect("Einer der Werte, die gleich beschrieben werden");

        while (!progress.isDone()) {
            int amount = input.read(buffer);
            buffer.flip();

            output.write(buffer);
            buffer.clear();

            progress.update(amount);
        }

1. Versuch (8192 Byte Puffer): zwischen 55 - 60 mb/s
2. Versuch (64*1024 Byte Puffer): zwischen 93-96 mb/s !!! (Sehr guter Wert!)
3. Versuch (128*1024 Byte Puffer): zwischen 20-70 mb/s (Schwankte stark, Durchschnitt war ebenfalls 55-60 wie beim 1. Versuch)

So, erst dachte ich "Gut, immer 64*1024" verwenden. Beim Testen auf einem anderen Computer, der sehr viel älter war und noch IDE Festplatten hatte, erreichte ich statt 35mb/s (Das war das Höchste, was dort HD Tune ermittelte) mit 64*1024 nur noch um die 18-20 mb/s. Dort waren 8192 Byte Puffer der Bringer.

Was habt ihr dabei für Erfahrungen ? Mir ist das Problem schon öfter mal aufgefallen, aber da ich nie riesige Dateien kopieren musste in meinen vorherigen Projekten, spielte das nur eine untergeordnete Rolle (mehr aus Interesse).

Gibt es eine Möglichkeit die ideale Puffergröße zu ermitteln ?

Meine Theorie dabei ist, dass Festplatten eine bestimmte Datenmenge effektiver lesen können, als andere Größen. Das z.B. beim Lesen von 128*1024 statt 64*1024 meine SATA Festplatten effezienter arbeiten. Aber ist nur eine Theorie.

Meine nächste Idee wäre mal, diese ganze Sache mal mit asynchronen FileChannels aus dem JDK7 zu probieren, diese können alle I/O-Operationen asynchron ausführen, bei Windows z.B. sind das die Completion Ports, die ein Event senden, wenn ein gewisser Vorgang fertig ist. Damit könnte man z.B. auf die 2. Festplatte Daten schreiben, während von der ersten Festplatte bereits Daten gelesen werden. Ich könnte mir vorstellen, dass man damit bestimmt bessere Geschwindigkeiten erzielen kann!

Also, was meint ihr zu diesem Thema ? Ist irgendwem das schonmal aufgefallen ? Liegt das vlt an schlecht fragmentierten Dateien ? Wobei ich mein System grad erst neu aufgesetzt hab und eigentlich sowas nicht zu erwarten ist...

Danke schonmal

Gruß,
Chris

 

[moormaster]

Hast Du mal versucht, statt der read(ByteBuffer dst) - Methode
mal die read(ByteBuffer[] dsts, int offset, int length) - Methode zu benutzen?

ich könnte mir vorstellen, dass letztere unter Umständen bei hinreichend großem Puffer besser funktioniert, weil sie nicht zwingend den gesamten Puffer vollmacht bevor sie endet. Ist aber nur ne Vermutung

 

[Wildcard]

Der Puffer arbeitet am schnellsten wenn der Puffer ein n-faches der Blockgröße des Dateisystems beträgt, leider lässt sich die nicht ohne weiteres herausfinden.
Große Dateien lassen sich wesentlich schneller per FileChannel kopieren. Das lohnt sich schon ab ein paar hundert Kilobyte

 

[Kr0e]

Hallo Zusammen,

den Effekt mit den Puffergrößen habe ich sowohl bei FileChannel als auch bei Streams gemerkt. Bei 64k sind beide sehr schnell, FileChannels etwas schneller als Streams (5-8mb/s). Aber bei z.B. 128k Blöcken sind sowohl Streams als auch Channels recht lahm.

Ich habe nun eine halb-Lösung:

Ich habe dieses asynchrone Lesen/Schreiben nun selbst implementiert (also ohne die JDK7 Klassen, da diese ja noch nicht Standard sind.) Quasi mit einem Threadpool... Nun erreiche mit 8k und höher die Maximalgeschwindigkeit der Festplatten. Ich benutze WIn7 übrigens. Beim Testen auf anderen Rechnern erziele ich gleiche Werte. Werde aber deim Release von JDK7 umsteigen auf die asynchronen Klassen, da dort OS-Threadpools im Spiel sind, die das ganze extremst beschleunigen können.

Danke und Gruß,

Chris

 

[Wildcard]

Warum nimmst du nicht einfach FileChannel#transferTo? Dafür brauchst du kein JDK 7 und es ist sehr performant.

 

[Kr0e]

Vlt. lieg ich jetzt falsch, aber dort wird doch auch nur häppchenweise übertragen..
transferTo(offset, count, writeableChannel). Wenn ich bei offset null eingebe und für count channel.size() nehme,
bekomm ich erstmal ne OutOfMemory Exception. Diese Funktion mapped dnan nämlich ebenfalls die gesamte Datei in den Ram...
Was nciht sehr schlau ist. Also wahrscheinlich auch immer in kleinen Blöcken... Und dann hab ich den selben Effekt komischerweise...
bei Häppchen von 64k ist es am schnellsten .. Langsam hab ich das Gefühl, dass mit meiner JVM was nicht stimmt.. Weil es offensichtlich keiner nachvollziehen kann =(. Ich habe die JVM 64bit für Win7 64bit.

 

[Wildcard]

Das passt schon. Mit channel.size() ist es am schnellsten, braucht bei sehr großen Dateien aber zuviel Heap. 64k Chunks ist sicherlich kein schlechter Standard Wert, denn den optimalen bekommt man leider nicht so einfach raus. Irgendwo ist in der API Doc AFAIR auch vermerkt das die Buffer Größe einen großen Einfluss auf die Performance nimmt und die ideale Größe Systemabhängig ist.
Mit einer nicht zu kleinen 2er Potenz macht man zumindest nichts falsch, insofern ist 64k wohl schon ok.

 

[Kr0e]

Werd ich mir merken, danke soweit erstmal Man kann ja im Programm die Möglichkeit geben, diese Puffergröße einzustellen, sofern nicht zufriedenstellende Transferraten erreicht werden, bzw. nicht erreicht werden.

Gruß,

Chris

 

[moormaster]

... oder du bastelst ne Art Benchmark, den der User laufen lassen kann, um den besten Wert für sein System zu ermitteln.