我有一个我在 Python3.4 中开发的科学应用程序，它使用 struct 包来生成我在后面的分析步骤中使用的条目的紧凑二进制表示。这些结构存储在一个大型二进制文件（300+ Gb）中，我称之为缓存文件。这个缓存文件被排序和索引。该文件的索引很容易放入内存中，并进行二进制搜索以找到缓存文件中的位置，我应该开始顺序读取缓存文件以检索所需的条目。此外，这些条目“引用”另一个缓存文件（基本缓存文件），我必须从中为缓存文件中的每个检索到的条目检索另一个条目，这个较小的基本缓存文件通常小于 1GB。这是通过寻找条目指定的位置并读取该位置的条目来实现的。
这个实现可以正常工作，但是我将大部分运行时都花在了磁盘访问上，我想尽量减少这种情况。我无法显着更改应用程序的设计，但我可以控制硬件的配置方式。我目前正在使用由 5 个三星 950 专业人士组成的条带 LVM，缓存和基本缓存都驻留在该 LVM 上。我没有硬件 raid 控制器，我使用的是 CentOS6，系统有 256GB 的 RAM。我经常使用相同的缓存和基本缓存文件运行多个分析实例。我不知道我使用当前解决方案实现的队列深度。
有人对如何优化此任务的存储配置有任何提示吗？我假设在文件中查找受 IOPS 的限制比阵列的总带宽更多。在 Python 中查找是否比顺序对数组的随机性能征税更多？将基本缓存放在单独的设备上是否明智？Ramdisk 可能是一种选择，但如果可能的话，我想避免这种情况。在这种情况下，较小的条带尺寸是否比较大的条带尺寸更好？
我目前正在对数组、条带大小和文件系统的一些组合进行置换，但一些指导将最大限度地减少测试的可能性。