Input/Output NIO: Block-Move

[Bernd Hohmann]

Ich hab hier ein RandomAccessFile, was serialisierte Datenblöcke unterschiedlicher Grösse (zwischen 1KB und 100MB) enthält. Jetzt soll das File reorganisiert - also gelöschte Blöcke entfernt - werden.

Also von vorne nach hinten durch eine Liste mit den Blöcken gehen, Datenblock lesen und weiter vorne wieder wegschreiben.

Funktioniert mit normalem IO ganz gut, ich hab das jetzt nach NIO umgeschrieben und es ist auch schon etwas schneller geworden.

Was mich an der derzeitigen Programmierung stört ist das ständige Neuanlegen des ByteBuffers. Konstante Buffergrösse geht leider nicht weil die Chunks unterschiedliche Grösse haben. Nur einen Teil eines grösseren Buffers zu nutzen hab ich nicht gefunden.

Kann man die Datei nicht komplett in den Speicher mappen und dann die MMU die Arbeit erledigen lassen? channel.transferTo/transferFrom geht anscheinend nur wenn unterschiedliche Channels genutzt werden.

Oder irgendeine andere Idee?

Hier das Stückchen Code:

		FileChannel fc = rafCache.getChannel();
		ArrayList<Chunk> lstNew = new ArrayList<Chunk>();
		long lngNewOffset = 0;
		int size = lstChunk.size();
		for (int i = 0; i < size; i++) {
			Chunk c = lstChunk.get(i);
			if (c.intIdx == -1) continue; // empty chunk

			// read chunk
			ByteBuffer bb = ByteBuffer.allocateDirect(c.intSize);
			fc.read(bb, c.lngOffset);

			// create new chunk entry
			[...]
			n.lngOffset = lngNewOffset;

			// write chunk back
			bb.flip();
			fc.position(n.lngOffset);
			while (bb.hasRemaining())
				fc.write(bb);

			lngNewOffset = lngNewOffset + c.intSize;
		}

Bernd

 

[Marco13]

Nur überflogen, aber...

Nur einen Teil eines grösseren Buffers zu nutzen hab ich nicht gefunden.

ByteBuffer bb = ...
bb.position(start);
bb.limit(start+length);
ByteBuffer slice = bb.slice();

!?

 

[Marco13]

Nochmal überflogen : Könnte sowas wie FileChannel (Java Platform SE 7 ) für sowas nicht praktisch sein?

 

[Bernd Hohmann]

Ja, den MappedByteBuffer hab ich mir angeschaut und nach durchlesen aller Dokus das so verstanden:

1) FileChannel vom RandomAccessFile geben lassen,

2) MappedByteBuffer mbb = fc.map(FileChannel.MapMode.READ_WRITE,0, lngFileLength) um das gesamte File ins VM zu Mappen

3) mbb.position(wo_soll_gelesen_werden)

4) mbb.get(buffer,0,chunk_length)

5) mbb.flip();

6) mbb.position(wo_soll_geschrieben werden)

7) mbb.put(buffer,0,chunk_length)

NUR: mbb.position(int) statt (long), damit hab ich ein 2GB Limit - irgendwas stimmt da nicht.

Bernd

 

[Bernd Hohmann]

Ok, ich hab gerade gesehen: es gibt tatsächlich ein 2GB Limit.

Ach wie blöde ^^

Bernd

 

[Noctarius]

Du kannst aber den Bereich der gemapped werden soll aufteilen wenn du mehr als 2GB brauchst, also 0->2GB, 2GB - 4GB, ...

 

[Bernd Hohmann]

Nur überflogen, aber...

Jo, das mit dem ".limit(...)" war es. Statt beim read/write die anzahl der Bytes anzugeben setzt man das interne Limit des Buffers vorher. Wenn man es weiss, eigentlich eine schöne Konstruktion.

In wie weit das natürlich intern irgendwelche Bottlenecks und zusätzliche Pagefaults erzeugt ist kaum feststellbar.

Bernd

 

[Bernd Hohmann]

Du kannst aber den Bereich der gemapped werden soll aufteilen wenn du mehr als 2GB brauchst, also 0->2GB, 2GB - 4GB, ...

Ja, ich hab gesehen dass man da ByteBuffer-Arrays erstellen kann. Muss mal schauen ob das noch rentiert.

Mit NIO schaffe ich es in 36s statt 1m10s die 4GB übers Netz zu reorganisieren, nächstes Bottleneck ist der Sort.

Bernd

 

[Noctarius]

Das klingt doch schon mal nach einem netten Zeitgewinn

 

[Bernd Hohmann]

Das klingt doch schon mal nach einem netten Zeitgewinn

Jo. Und als letztes:

ByteBuffer bb = ByteBuffer.allocateDirect(intUpbBufferSize);
//ByteBuffer bb = ByteBuffer.allocate(intUpbBufferSize);

Der Buffer, der von .allocateDirect(..) kommt ist langsamer als der von .allocate(...) - warum auch immer.

Bernd

 

[Noctarius]

[c]allocateDirect[/c] ist nur schneller wenn man auf external Memory weiterarbeitet. Da aber der Kram über HeapBuffer verarbeitet wird muss alles hin und her kopiert werden. Bei SocketChannels wäre der DirectBuffer schneller

 

[Bernd Hohmann]

Ah, danke!

Bernd

 

[Bernd Hohmann]

[c]allocateDirect[/c] ist nur schneller wenn man auf external Memory weiterarbeitet

Sagmal: wird der ByteBufer im Virtuellen Adressraum abgebildet sodass ich einen Buffer allokieren könnte der grösser als der freie Speicher ist?

Mir ist aufgefallen, dass es bei der Reorganisation immer mehrere zusammenhängende Blöcke gibt die ich zusammen verschieben könnte und frage mich, was ich als Limit nehmen soll (gerade auf 32bit Maschinen mit wenig RAM).

Bernd

 

[Noctarius]

Mit DirectByteBuffern / HeapByteBuffern geht das nicht:
Diese werden im vorher definierten Heap bzw im RAM neben der JVM initialisiert. Generell natürlich mit virtuellen Speicheradressen (diese nutzt ja das OS) aber müssen in den verfügbaren Speicher passen.

Mit Mapped Files geht das:
Generell kannst du mehr Speicher mappen als der Rechner hat (wie du bereits sagst, es ist nur der virtuelle Adressraum), allerdings ist auf 32Bit Betriebssystemen der virtuelle Speicherbereich für Anwendungen irgendwo bei 3,x GB zuende. Die 4GB pro Prozess erreicht man nicht ganz. Auf 64Bit Betriebssystemen und einer 32Bit Anwendung gilt dieses Problem auch noch, erst mit einer 64Bit Anwendung hast du da keine Probleme mehr.
Über MemoryMapped Files kannst du theoretisch Terrabyte an "Anwendungsspeicher" zur Verfügung stellen (das machen OS ja auch mit dem Auslagerungs- / Swapspeicher).

 

[Bernd Hohmann]

Über MemoryMapped Files kannst du theoretisch Terrabyte an "Anwendungsspeicher" zur Verfügung stellen (das machen OS ja auch mit dem Auslagerungs- / Swapspeicher).

Ok, danke! Dann werde ich mir das mal genauer anschauen.

Bernd