假设一个进程需要在许多（1000+）个位置访问文件系统，并且该顺序对程序逻辑并不重要。但是，如果文件系统存储在（旋转）硬盘上，则顺序显然对性能很重要。
应用程序员如何与操作系统进行通信，以便最佳地安排访问？启动1000多个线程似乎并不实用。数据库管理软件是否实现了这一点，如果是，那么如何实现？
其他详细信息：我有一个大型（1TB +）mmapped文件，我需要读取大约1KB的1000多个块，每次都在新的，不可预测的位置。
答案 0 :(得分：2)
文件及其交易缓存在您计算机的各种设备中; RAM和高速缓存是最常用的地方。文件系统驱动程序还可以实现IO事务队列，碎片整理和纠错逻辑，这使得想要控制文件访问的每个方面的开发人员变得复杂。这种复杂程度最终旨在提供系统所有进程的文件访问的完整性，安全性，性能和协调。
优化工作不应该干扰系统自己的缓存和预测算法，不仅仅是IO，而是所有缓存。试图猜测你的系统是浪费你的时间和处理器的时间。
很可能您的IO操作和数据将保留在缓存中，然后在操作系统认为合适时将其提交到存储设备。
也就是说，数据库套件，mmap，预读机制以及驱动器的直接IO等选项总是存在。您需要投入时间对任何努力进行基准测试。我建议不要使用多个IO线程，因为缓存争用会比一个线程更慢。
答案 1 :(得分：2)
在早期，像Wikipedia: Hard disk drive performance characteristics → Seek time这样的参数非常昂贵且因此非常重要，数据库供应商关注磁盘上的数据表示和布局，例如可以看到在Oracle8i: Designing and Tuning for Performance → Tuning I/O。
重要的优化参数随着固态驱动器（SSD）的外观而变化，其中寻道时间为0（或至少恒定），因为没有任何旋转。一些新参数由Wikipedia: Solid-state drive (SSD) → optimized file systems解决。
但即使这些优化参数也会因使用Wikipedia: In-memory databases而消失。 list of vendors很长，很重要。
因此，如何最佳地安排访问取决于用例（1000个并发命中不足以解决问题）并购买一些RAM是其中一个选项而且＆＃34; 程序员如何与之通信操作系统＆＃34;将是最后（不是第一个）问题之一
答案 2 :(得分：1)
如果内核来自各种进程或线程，则内核已经对读/写请求进行了重新排序（例如，以适应机械磁盘的旋转）。顺便说一句，大多数读取＆amp;写入将转到内核文件系统缓存，而不是磁盘。
您可以考虑使用posix_fadvise(2)＆amp;也许（在一个单独的线程中）readahead(2)。如果 - 而不是read(2) - 你使用mmap(2)将一些文件部分投影到虚拟内存，你也可以使用madvise(2)
当然，文件系统通常不保证文件的连续部分在物理上顺序位于磁盘上（甚至磁盘固件可能会重新排序扇区）。请参阅Ext2 wikipage中的图片，该图片也与Ext4相关。在这方面，某些文件系统可能更好，您可以调整其块大小（mkfs时间）。
我不建议有数千个线程（最多只有几十个）。
最后，可能值得购买一些SSD或更多RAM（用于文件缓存）。见http://linuxatemyram.com/
实际性能在很大程度上取决于特定的系统和硬件。
也许使用像GDBM这样的索引文件库或数据库Sqlite（或像PostGreSQL这样的真实数据库）可能是值得的！也许文件较少，但较大的文件可能会有所帮助。
顺便说一句，你是mmap - 并且读取1K的小块（小于4K的页面大小）。你可以使用madvise（如果可能的话），但是你应该尝试阅读更大的块，因为每个文件访问都会带来至少一整页。
你真的应该做基准！