我最近遇到一篇有趣的文章 ，使用IO统计数据来确定性能问题的原因。 在检查了我的统计数据后，我发现我有一个“IO子系统的瓶颈”。
不幸的是，我不知道这意味着什么。 从我在网上find的东西，抛出一些更多的内存可能会有所帮助（我假设，因为它不必写入磁盘，但我很好奇，如果有人知道一个好的方法来确定如何继续？
IO子系统通常处理存储到磁盘。 当数据必须被写入或读取时，会发生这种情况。 一般来说，您需要监视磁盘队列的深度。 我不完全记得这些build议，但是我认为这是1.5 *物理磁盘的数量。
有几个潜在的解决scheme取决于你find的。
首先，在服务器中获得足够的RAM，这样基本上可以将整个数据库保存在内存中，并有足够的空间来执行查询。 越less的时间，你可以保持从传呼到磁盘越好越好。 这包括拥有足够的RAM来将临时表保存在RAM中，而不是将这些表分页到磁盘中。
其次，获得更快的磁盘。 15k SCSI驱动器适当突袭。 如果适用，您甚至可以调查SSD; 在你做之前，要意识到自己的局限性。 将日志文件放在单独的磁盘系统上，并且可能将表分区，以便它们位于不同的磁盘上。 这个可以变得复杂而且非常昂贵。
第三，调整你的查询来更好地使用你的索引，当服务器必须去磁盘拉取完整的logging时，这也应该有助于限制下来。
最后，除非是真正的问题，否则不要冒汗。 如果你的应用程序正在快速移动，那么find一个不同的区域来“修复”如果这是一个实际的问题，那么决定是否是时间来扩展你的服务器。
在开始升级IO系统之前，您需要查看索引。 如果您的索引不正确，这将显示在磁盘上更多的IO负载。 一旦你解决了索引问题，如果你仍然有IO问题，那么你将需要添加更多的主轴或切换到闪存驱动器。
IO子系统基本上是指磁盘/存储。 如果这真的是你的瓶颈，你可以通过添加更多和/或更快的磁盘来提高性能。 select正确的RAID级别也很重要，对于数据库，RAID 10的性能通常优于RAID 5，特别是对于写入负载较高的情况。
但是从确保你的服务器不浪费磁盘带宽开始。 数据库性能必须适当的索引。 更多的内存caching也可以降低IO负载。 根据访问模式，重新组织数据以获得更好的位置可能会有所帮助。