Chinaunix
标题:
linux系统下开发-海量文件读写后导致的文件缓存过大但又不释放的问题,如何解决?
[打印本页]
作者:
sdeven.lee
时间:
2006-11-22 11:08
标题:
linux系统下开发-海量文件读写后导致的文件缓存过大但又不释放的问题,如何解决?
我们的程序需要读写大量的数据,但是在发现这样一个问题,但我们读写某个文件后,系统就把此部分操作进行了缓存
导致现在出现文件缓存不断的增大,使用free命令后发现,总共4G的内存,文件缓存就占了3.9G.现在程序在系统上运行的效率很差,资源不足.
我们分析的情况可能是2个问题:
1.linux系统的文件缓存机制是不可释放的(除非把那个文件给删除了,那么文件缓存就能释放),所以导致系统内
存越来越少.当内存用完时(其实真正大部分内存被cache占用,但没有释放),就导致可能系统使用交换分区,导致
系统运行长时间后速度越来越慢!
2.以上观点是基于我们原来的观点:linux系统下文件缓存是不可手工释放的(除非删除源文件)
如果我们的观点错误的话,那么可能是这样的情况,cache中的资源是可再利用的,那么当内存不足时,假如其
他程序再申请内存,系统将回权衡效率,是从cache中取资源呢?还是从交换分区中取资源?由于此是cache也是
非常的大,很有可能从cache中取回资源的效率也很差,所以就从swap中取,导致性能越来越差.
现在问题正解决中,希望大家发表下观点,不知道有什么解决方法没?
关键是如何解决所囤积的大量文件缓存!
开发环境是RedHat AS3 + oracle 10g
程序将会读取本地的大量数据(doc,pdf,ppt等各种文件类型),生成新文件进行分析和存储,并将某些相关信息存储到数据库中.
[
本帖最后由 sdeven.lee 于 2006-11-22 11:10 编辑
]
作者:
sunkez
时间:
2006-11-22 11:35
标题:
回复 1楼 sdeven.lee 的帖子
我也是遇到这中情况,cache不回收,结果用SWAP了,等待高手解答!
作者:
longshort
时间:
2006-11-23 10:12
linux系统的文件缓存机制是不可释放的(除非把那个文件给删除了,那么文件缓存就能释放),所以导致系统内
可能有一点误解:
一般情况下,操作系统保留最少的内存区域作为备用,比如只有8MB-16MB左右。例如:
[~/src/db_campus]$ free
total used free shared buffers cached
Mem: 515112 498716 16396 0 278448 54572
-/+ buffers/cache: 165696 349416
Swap: 2101032 0 2101032
[~/src/db_campus]$
这是我开机没多久的情况,尽管free项下只有16MB,但执行任何程序都很顺畅,并不进入到交换区内。原因是由于操作系统的算法决定了凡是公共可读的数据,一概放在高速缓冲区中,其存在寿命由用户使用的频度来决定。
通常情况下,只要使用的数据不超过系统内定的cache大小,系统总是把它放在cache中。在楼主的情况下,能够完整地存放在cache中的文件只要是持续在使用的,一般都位于内存之中,而无法完整放在内存中的文件,由于使用频度也很高,系统会将它放入交换区。
在cache和buffer区域中,如果有需要放入新的数据,那么操作系统将会寻找可用的内存。如果没有,系统会检查数据的使用频度,最早和最少使用的数据将首先被系统从内存中移到交换区去,把腾出来的空间用于新数据的存放。
可以根据操作系统的这种特点来重新决定您的系统应该有多大的内存空间和硬盘交换区的大小。不过,对交换区不要存在太多的偏见,一个重负载的系统是不可能不使用交换区的,不管您的硬件条件有多优秀。
作者:
longshort
时间:
2006-11-23 10:20
关键是如何解决所囤积的大量文件缓存!
不必考虑文件缓存是否囤积的问题,只要您的数据足够新,系统会给您找空间的,关键是您需要改变一下系统设计的思路,换个角度看问题。
另外,凡是用完的文件应立刻关闭,否则有多少资源也是不够用的。同时打开的文件应该有个比较严格的限制,环境保护的观念在这里完全适用。
作者:
marshal209
时间:
2006-11-23 16:41
以前实习的时候做过这个项目 我们做的是从网上直接抓包大概流量在800Mbyte/s实时保存,用的是linux2.4版本,如果要消除这个问题那么你就要建立自己的文件系统使用Raw I/o而且要修改操作系统的内核,将两次copy变成一次copy这样性能才可以达到要求,提供解决的一个思路!
欢迎光临 Chinaunix (http://bbs.chinaunix.net/)
Powered by Discuz! X3.2