当一台Linux服务器正在提供许多并发请求来读取许多不同的文件时,是否这样做:
寻findFile_1,读取整个文件,然后寻找File_2,读取整个文件,然后寻找File_3等
寻findFile_1,读取它的一部分(直到readahead的值?),然后寻找File_2,读取它的一部分,然后回到它已经离开的File_1,多读取它,然后寻找File_3等,等等
如果是第二种情况,那么服务器做的比寻求更多,这会大大减缓。 在那种情况下,我可以做些什么调整?
在磁盘I / O中有一个叫做电梯的东西。 磁盘子系统试图避免在盘片上颠簸盘头。 它将对I / O请求进行重新sorting(如果没有禁止,例如通过屏障),以便磁头从磁盘内部移动到外部,然后返回,在途中执行所请求的I / O。
第二件事是I / O请求合并。 如果在短时间窗口内有很多请求访问文件的不同部分,那么I / O子系统将尝试一次获取所有数据,而不是发出多个不相关的请求。
至于调整。 如果你是应用程序的作家,你可以做很多事情。 您可以随时发出大量的顺序I / O,并使用fsync()et.al. 当你需要确定数据在盘片上时。
如果你是一个系统pipe理员,你绝对知道,2个应用程序的数据请求leapfrog,他们试图连续读取文件(例如,你有2个DVD并行转码),那么是的,增加readahead应该有所帮助。 否则,在进行任何调整之前,您需要查看您的I / O模式和大小,考虑RAID级别(如果有)以及其他因素。 看看你真正的瓶颈是什么,在开始调整之前,可能很难猜到,什么是真正限制你的系统。
在linux中,你可以定义你自己的调度algorithm,你有不同的可能性,我不得不在学校做一件事情,红帽的这篇文章帮了我很多。 虽然它专门用于Red Hat,但几乎可以在任何Linux发行版中find这些调度程序。