Using tmpfs to speed up "disk" access

Overview

If you have an application which performs a lot disk reads/writes and a modest amount of data, you don't need to keep. e.g. a unit tests, application builds. Using tmpfs may be the answer speeding up the process.

In this article I compare using a tmpfs, an SSD, a hard drive and an NFS drive.

Comparing creating a file and deleting it

Small files (256 bytes) are created repeatedly and an average time taken. These files are deleted in a second test.

File system typemachinefile creationfile deletion
tmpfsfast7.2 us3.9 us
tmpfsolder19.9 us8.9 us
SSD ext4fast22.9 us9.1 us
7200 RPM ext4older42.9 us24.1 us
NFS-11,238 us5,294 us

The "fast" machine was a 3.8 GHz i7 with 1600 MHz memory.

The "older" machine was a 2.5 GHz AMD 4800 with 533 MHz memory.

The NFS drive is a QNAP TS-210 with mirrored 7,200 RPM drives over a home plug network.

The write cache for the 7,200 RPM disk is making a big difference. Without the disk cache the performance would closer to that of the NFS file system.

In each case, the tmpfs was limited to 80% of the total main memory. Using a larger tmpfs will impact performance.

The Code

The core part of the test looks like this.
byte[] bytes = new byte[256];
long start = System.nanoTime();
for (int i = 0; i < files; i++) {
    File file = new File(dir, Integer.toString(i));
    FileOutputStream fos = new FileOutputStream(file);
    fos.write(bytes);
    fos.close();
}
long time = System.nanoTime() - start;
System.out.printf("Took an average of %.1f us to write to LOCAL filesystem%n", time/1e3/files);
OpenCloseFilesTest.java

Conclusion

Using a tmpfs can be 2-3x faster than a local disk with write cache. When you have working data you don't need to keep it can speed up your process.

Comments

Popular posts from this blog

Low Latency Microservices, A Retrospective

Unusual Java: StackTrace Extends Throwable

System wide unique nanosecond timestamps