FileOutputStream close()方法瓶颈问题

现在要把收到的每个报文记录到单独的文件中,在做压力测试时发,FileOutputStream 中 close()方法执行需要的时间,随着系统持续压力测试时间的增长而增长,最后导致close()执行的时间在整个线程的执行时间占比越来越高,有没有什么方法改变一下这个情况。相关代码如下
[code="java"]
public static void write(byte[] msg, String fileName) {

    if (fileName.indexOf(File.separator) != -1) {
        String dirPath = fileName.substring(GatewayConstants.ZERO_INT, fileName.lastIndexOf(File.separatorChar));
        createDir(dirPath);
    }

    FileOutputStream os = null;
    try {
        os = new FileOutputStream(createFile(fileName));
        os.write(msg);
        os.flush() ;
    } catch (FileNotFoundException e) {
        logger.error("fileNotFoundException exception"+fileName, e);
    } catch (IOException e) {
        logger.error("fileOutputStream closed exception", e);
    }finally{
        try {
            if(os !=null)
                os.close() ;
        } catch (IOException e) {
            logger.error("fileOutputStream closed exception", e);
        }
    }
}

[/code]

6个回答

刚才看了你的回复:
[quote]
1、根据JPROFILE监控的数据是close()执行的时间长。
2、将每个报文记录到单独的文件中,分开不同的文件。
3、关于磁盘响应,有什么比较好的方式监控,这个还请赐教。
4、不用取文件,每次文件都是新增。目录之前是按年月日小时,后来我也以为是文件太多,再加了一层分钟,但还是没什么效果。 2012-09-18 15:01
[/quote]

90%的可能是IO写的瓶颈问题,而不是程序:
测试办法:
1. 找一台有固态硬盘的电脑
2. 先使用普通硬盘的测试下
3. 再使用固态硬盘的测试下
4. 再对比两者差别。
分析:如果固态硬盘依然慢,就说明是程序瓶颈,否则就是硬盘IO瓶颈。

优化建议:
1. 使用一个线程写文件,而不是多个线程同时写(IO写基本上单线程最优)
2. 基于条件1,写一个文件而不是多个文件。

对比:java里面的日志记录,基本上都是多个线程同时在写日志,一般优化都是先缓冲,积累日志,再写入文件。

你怎么知道是在close耗时还是write, flush耗时?
整个压力测试是在写文件,是写同一个文件还是不同的文件?
磁盘响应如何?压力大的情况下写不同文件肯定耗时增加啊!
写的都是在同一个目录下?同一目录下文件越多,你不去write,光取一个文件都要耗很大资源。

所有问题都理清了再说。

diggywang
diggywang 你测试压力具体有多大?在什么系统下测的?打开的文件句柄数有没有到达当前系统用户极限? PS,win7的资源监视器可以看磁盘IO。
大约 7 年之前 回复
weixin_42501834
曹璐 1、根据JPROFILE监控的数据是close()执行的时间长。 2、将每个报文记录到单独的文件中,分开不同的文件。 3、关于磁盘响应,有什么比较好的方式监控,这个还请赐教。 4、不用取文件,每次文件都是新增。目录之前是按年月日小时,后来我也以为是文件太多,再加了一层分钟,但还是没什么效果。
大约 7 年之前 回复

试试jdk7

skzr_org
时空之蕊 你换一个固态硬盘再测试下。。。再对比两者差别。 如果固态硬盘依然慢,就说明是程序瓶颈,否则就是硬盘write瓶颈。
大约 7 年之前 回复
weixin_42501834
曹璐 老兄,这种情况下是不是和磁盘的性质有关?换个好点的硬盘可以解决不?有没有建议解决方案
大约 7 年之前 回复
skzr_org
时空之蕊 就象期望通过一个小水渠把一湖的水排到另一个大湖中,无论你有多少个水泵都不顶用,水渠只有那么粗。
大约 7 年之前 回复
skzr_org
时空之蕊 老实说,这个与你的IO本身就有关系的啊。 看上去好象是程序瓶颈,实际上是因为底层io的瓶颈导致的。
大约 7 年之前 回复

建议加上 BufferedOutputStream做缓冲

close时间比write时间还长?换NIO试试呢?

iteye_16124
iteye_16124 有没有可能不分文件了,合成一个文件,或者存Redis,硬盘处理小文件本来就不快,再或者考虑加两块硬盘?
大约 7 年之前 回复
weixin_42501834
曹璐 之前也想过用NIO,后来查了资料发现NIO在这情况下和IO效率差别不大
大约 7 年之前 回复
iteye_16124
iteye_16124 不用试了,相距应该不大
大约 7 年之前 回复

先确定真正原因
RandomAccessFile
这个类操作文件效率高。

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!