当一台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这些调度程序。