为什么Java磁盘I / O的执行速度比用C编写的等效I / O代码慢得多?

时间:2015-06-27 23:00:45

标签: java performance io java-8 ssd

我有一个SSD磁盘,每个规格应提供不低于10k的IOPS。我的基准确认它可以给我20k IOPS。

然后我创建了这样一个测试:

private static final int sector = 4*1024;
private static byte[] buf = new byte[sector];
private static int duration = 10; // seconds to run
private static long[] timings = new long[50000];
public static final void main(String[] args) throws IOException {
    String filename = args[0];
    long size = Long.parseLong(args[1]);
    RandomAccessFile raf = new RandomAccessFile(filename, "r");
    Random rnd = new Random();
    long start = System.currentTimeMillis();
    int ios = 0;
    while (System.currentTimeMillis()-start<duration*1000) {
        long t1 = System.currentTimeMillis();
        long pos = (long)(rnd.nextDouble()*(size>>12));
        raf.seek(pos<<12);
        int count = raf.read(buf);
        timings[ios] = System.currentTimeMillis() - t1;
        ++ios;
    }
    System.out.println("Measured IOPS: " + ios/duration);
    int totalBytes = ios*sector;
    double totalSeconds = (System.currentTimeMillis()-start)/1000.0;
    double speed = totalBytes/totalSeconds/1024/1024;
    System.out.println(totalBytes+" bytes transferred in "+totalSeconds+" secs ("+speed+" MiB/sec)");
    raf.close();
    Arrays.sort(timings);
    int l = timings.length;
    System.out.println("The longest IO = " + timings[l-1]);
    System.out.println("Median duration = " + timings[l-(ios/2)]);
    System.out.println("75% duration = " + timings[l-(ios * 3 / 4)]);
    System.out.println("90% duration = " + timings[l-(ios * 9 / 10)]);
    System.out.println("95% duration = " + timings[l-(ios * 19 / 20)]);
    System.out.println("99% duration = " + timings[l-(ios * 99 / 100)]);
}

然后我运行这个例子并得到2186 IOPS:

$ sudo java -cp ./classes NioTest /dev/disk0 240057409536
Measured IOPS: 2186
89550848 bytes transferred in 10.0 secs (8.540234375 MiB/sec)
The longest IO = 35
Median duration = 0
75% duration = 0
90% duration = 0
95% duration = 0
99% duration = 0

为什么它比C中的同一测试慢得多?

更新:这里是Python代码,它提供了20k IOPS:

def iops(dev, blocksize=4096, t=10):

    fh = open(dev, 'r')
    count = 0
    start = time.time()
    while time.time() < start+t:
        count += 1
        pos = random.randint(0, mediasize(dev) - blocksize) # need at least one block left
        pos &= ~(blocksize-1)   # sector alignment at blocksize
        fh.seek(pos)
        blockdata = fh.read(blocksize)
    end = time.time()
    t = end - start
    fh.close()

Update2 :NIO代码(只是一块,不会复制所有方法)

...
RandomAccessFile raf = new RandomAccessFile(filename, "r");
InputStream in = Channels.newInputStream(raf.getChannel());
...
int count = in.read(buf);
...

4 个答案:

答案 0 :(得分:7)

您的问题基于错误的假设,即与您的Java代码类似的C代码的表现与IOMeter一样。因为这个假设是错误的,所以C性能和Java性能之间没有差异来解释。

如果您的问题是您的Java代码相对于IOMeter表现如此糟糕的原因,那么答案是IOMeter不会像您的代码那样一次发出一个请求。要从SSD获得完整性能,您需要保持其请求队列非空,并等待每次读取完成后才能发出下一个读取队列。

尝试使用线程池来发出请求。

答案 1 :(得分:3)

从这篇文章开始,传统的Java随机访问速度要慢2.5到3.5倍。这是一份研究pdf,所以不要责怪我点击它。

链接:http://pages.cs.wisc.edu/~guo/projects/736.pdf

  

Java原始I / O比C / C ++慢,因为Java中的系统调用是   更贵;缓冲可以提高Java I / O性能   减少系统调用,但更大的缓冲区大小没有大的收益;   直接缓冲优于Java提供的缓冲I / O.   类,因为用户可以根据自己的需要定制它;增加   操作大小有助于I / O性能而无需开销;和系统   调用在Java本机方法中是便宜的,而调用的开销   原生方法相当高。当本机呼叫的数量是   适当减少,可以实现与C / C ++相当的性能。

那个时代就是你的代码。现在让我们不要使用java.nio重写它,而是使用#include<stdio.h> #define BUF_SIZE 1024 char buf[BUF_SIZE]; char arr[20]; int main() { FILE* fs=fopen("test.txt","r"); setvbuf(fs,buf,_IOFBF,1024); fread(arr,1,1,fs); printf("%s",arr); getchar(); return 0; } 吗?

我有一些我们可以反对的nio2代码。可以排除垃圾收集:)

答案 2 :(得分:1)

因为你正在使用RandomAccessFile,这是Java中最慢的磁盘I / O方法之一。

尝试更快地使用某些内容,例如BufferedInputStreamBufferedOutputStream,并查看速度。

如果您想知道为什么这会对SSD产生影响(因为SSD应该擅长随机访问),那么它与访问的随机性无关;它是关于带宽的。如果您的SSD具有1024位宽的总线,但您每次写入只写64位(正如您通过编写longdouble s所做的那样),您和#39;慢慢来。 (当然,这些数字仅用于举例目的。)

现在,我可以看到,这不是您的代码正在做的事情(或者至少看起来似乎在做什么),但RandomAccessFile很可能在这种情况下实现它引擎盖。再次尝试使用缓冲流,看看会发生什么。

答案 3 :(得分:1)

RandomAccess在Java中大多快,但不能与C进行比较。 但是如果你想在JVM上更好地比较IO Performance,请阅读Martin Thompson关于这个主题的优秀博客:http://mechanical-sympathy.blogspot.co.uk/2011/12/java-sequential-io-performance.html