IO读取每个文件的写入

数据库pipe理员（DBA）领域有一个阵营（最近我还没有经过这个阵营）认为，通过对存储基础架构进行微观pipe理，系统和存储pipe理员拥有最佳性能走开，给他们一堆硬盘，一两台服务器，偶尔还会帮忙。

这些系统通常最终会有大量的RAID1对，数据文件有目的地，系统地分布在每一个数据文件中。 日志驱动器将被使用和类似的隔离。 这个方法背后的想法非常简单：

• 通过这样做，您可以将数据库从其他大型IOP消费者中分离出来，这样大用户永远不会影响系统的其他部分。
• 通过拥有大量驱动器，系统的总IOPS非常高。
• 通过最大限度地减less存储抽象层，使系统整体更可靠，重要的是延迟更低。

这种方法有一个重大的问题，Chopper3钉住了它：可维护性。

像这样的系统将需要持续不断的关注和微调，以便随着数据库的增长/缩小，使用情况的变化，应用程序和使用模式的变化，从失控情况的恢复以及维护周期的变化，继续保持“最佳” 。 上面描述的这种体系结构最适合写几乎从不读/读的工作负载。

当数据库真正重要的是使硬件的每一个性能比例达到最小值的时候，它也被使用。 在许多情况下，这是一个预算决定，在这种情况下，DBA时间比硬件更便宜。 但是，有一些高性能计算的情况下，不可能制造更大的盒子，所以你必须优化你的产品。 对于我们其他人不使用怪物数据库服务器，总是有升级。

另一个阵营，和我所说的阵营，处理方式不同。 它把更多的信念放在存储抽象上，并且趋于更好地扩展。 将所有这些对放入一个RAID10集合，而不是空对R10对; 或者less量的RAID10集合。 这允许IOP聚合与上面相同，但是每个数据文件/表空间/数据库可以获得相当多的浪涌容量。 通过使用多个R10集，您可以为那些需要它的关键数据库和日志文件提供I / O分隔。 微观pipe理每个文件的性能需求大大降低。

你的想法似乎过于复杂，脆弱和难以pipe理 – 你不能把磁盘放到RAID 10arrays中，这样会平均地将数据和IOPS分散在磁盘之间 – 这是其他人所做的。

您可以使用systemtap脚本监视每个文件的I / O。 请参阅： iotime.stp