我有一个 Sun M4000，它连接到一个带有大量写入数据库的 EMC CX4-120 阵列。写入峰值约为 1200 IO/s 和 12MB/s。
根据 EMC 的说法，我正在使 EMC 阵列上的写入缓存饱和。
我认为最简单的解决方案是将重做日志移动到基于 DRAM 的 SSD。这会将 EMC 阵列上的负载减少一半，并且应用程序不会看到日志缓冲区等待。是的，DBWR 可能会成为瓶颈，但应用程序不会等待它（就像他们在重做提交时所做的那样！）
我目前循环使用大约 4 个 4GB 的重做日志，所以即使是 20GB 左右的 SSD 也会有很大的不同。由于这是短期存储并且不断被覆盖，因此基于闪存的 SSD 可能不是一个好主意。
M4000 没有任何额外的驱动器，所以 PCI-E 卡将是完美的，我可以去外部或将启动卷移动到 EMC 并释放本地驱动器。
Sun 出售 Flash Accelerator F20 PCIe 卡，但这似乎是一些 SATA 磁盘的缓存，而不是 DRAM SSD 解决方案。细节是粗略的，它没有将 M4000 列为受支持的，而且我厌倦了与 Sun 的电话树斗争以寻求人类帮助。:(
其他人是否同意 DRAM SSD 是必经之路？有什么硬件推荐吗？
更新 除了下面评论中的信息外，我还尝试了“commit_write”的各种设置，但没有任何区别。
首先 - 我猜你阵列中的磁盘很少。12 个旋转磁盘可以轻松支持 1200IOPS（每个磁盘 100 IOPS 非常合理）。如果缓存无法处理它，则意味着您 1200 IOPS 的持续写入速率远远超出了您的磁盘所能支持的范围。
无论如何，用于重做日志的 SSD 不太可能有帮助。首先，您的会话是否主要等待 COMMIT 语句？检查 statspack / AWR 中最重要的等待事件以进行验证。我猜大约 95% 的 I/O 根本不是重做日志。例如，对具有 5 个索引的表进行单行插入可以执行 1 次 I/O 以读取表块（具有该行的空间）、读取 5 个索引块（更新它们）、写入 1 个数据块、1 次撤消块和 5 个索引块（或更多，如果更新了非叶块）和 1 个重做块。因此，检查 statspack 并查看您的等待事件，您可能正在等待大量的 READ 和 WRITE 以获取数据/索引。等待读取会减慢 INSERT 的速度，而 WRITE 活动会使 READ 更慢——它是相同的磁盘（顺便说一句——你真的需要所有的索引吗？删除那些不需要的索引会加速插入）。
要检查的另一件事是 RAID 定义 - 是 RAID1（镜像 - 每次写入是两次写入）还是 RAID 5（每次写入是 2 次读取和两次写入以进行校验和计算）。RAID 5 在写入密集型负载中速度较慢。
顺便说一句 - 如果磁盘无法处理写入负载，DBWR 将成为瓶颈。您的 SGA 将充满脏块，并且在 DBWR 可以将一些脏块写入磁盘之前，您将没有空间来读取新块（例如需要处理/更新的索引块）。同样，检查 statspack / awr report /addm 以诊断瓶颈是什么，通常基于前 5 个等待事件。
我看到一篇关于使用“forcedirectio”选项挂载 UFS 分区并将 Oracle 参数“filesystemio_options”设置为“setall”的帖子。
我尝试了一下，发现 Oracle 写入速度提高了 4-5 倍！是的！
主要症状是吞吐量低，但磁盘响应时间长。这似乎对某些人有帮助，但对另一些人却没有帮助。它确实适合我。
我可能会考虑在新服务器上使用 SSD，但该服务器现在运行良好。
罗伯特
| 归档时间： |
|
| 查看次数： |
4443 次 |
| 最近记录： |