![使用 RAM 磁盘加速 SQL Server 临时表处理](https://linux22.com/image/610078/%E4%BD%BF%E7%94%A8%20RAM%20%E7%A3%81%E7%9B%98%E5%8A%A0%E9%80%9F%20SQL%20Server%20%E4%B8%B4%E6%97%B6%E8%A1%A8%E5%A4%84%E7%90%86.png)
我们正在开发的系统由 Web 应用程序前端和后端组成,后端使用 SQL Server 2008 R2 中的存储过程进行大量数据处理(请不要问为什么……)。这些存储过程大量使用临时表(创建、插入、连接),因此临时数据库写入和读取的 i/o 速率很高。我们的客户需要速度,因此我们即将提出以下建议:
- 购买带有 RAID 1 SSD 阵列的服务器来存储主数据库(如果有钱的话也可以使用 RAID10),使用另一个硬盘来安装操作系统和 SQL Server,以便重要数据以复制形式存储在快速驱动器中,并配备 64 GB RAM。
- 使用 Ramdisk 来存储临时数据库数据库,因此临时表(我们认为是最大的性能瓶颈)在 RAM 中处理。
一些上下文数据:
- 我们的数据库使用量不超过 10 GB,预期增长率非常低。Tempdb 通常增长不超过 2-3 GB。
- 该服务器将用于数据库和 Web 服务器。
- Ramdisk软件可以在windows启动时挂载ramdisk。
我们在一台内存很大的笔记本电脑上测试了 ramdisk 方法。速度至少是显著的(存储过程执行时间缩短至 1/3)。
我需要帮助来确定这是否是一个好的解决方案,并发现我可能忽略的任何缺陷(明显的或不太明显的)。
编辑:感谢您迄今为止的回答!我忘了明确提到会有并发用户使用该应用程序,因此将运行多个临时表操作。此外,混合使用 Web 服务器和 DB 服务器不是我们的选择,我们已经知道这不是最佳选择 ;)
答案1
这不仅仅是速率,也是等待。正确进行基准测试。检查 IOPS 以及磁盘队列长度。使用 Perfmon 和 SQL 分析。继续 - 我会等待。
您已经知道,如果您确实有实际的性能问题,操作系统应该位于一组主轴上,MDF 位于另一组主轴上,LDF 位于另一组主轴上,而 tempdb 文件位于另一组主轴上。如果您不能承诺这样做,请对其进行基准测试并找出您的优先事项。此外,不同的读写模式可以决定每个 RAID 级别的不同。
您可能会发现,具有正确 RAID 配置的标准磁盘可以满足您的需求,而无需使用企业级 SSD。但是,如果 tempdb 受到的打击足够大,单个 SSD 可能就很合适。可能不需要 RAID 来提高性能,但对于冗余来说,这可能是一个好主意。当然,这取决于您的预算以及您可以停机多长时间。
您也知道 SQL 服务器应该与 Web 服务器分开,对吧?如果性能是个问题?即使您现在没有遇到问题,但如果您发展壮大,您将很难确定哪个服务器受到的打击更大,以及适当的修复方法是什么。
答案2
RAID 用于冗余,性能就会受到影响。例如,对于 RAID 5 来说,读取一段数据全部必须读取组件磁盘,并检查奇偶校验(即是比从单个磁盘读取慢,磁头移动不一定会同步,因此你需要等待最长写入操作(即读取全部数据(而不仅仅是平均值))意味着读取所有内容、计算奇偶校验并写入新数据和奇偶校验,这显然比单纯写入要慢。
是的,良好的 RAID 实施和智能操作系统可以大大缓解这种情况(必须这样做,即使单个磁盘相对于 RAM 来说也非常慢,因此任何有价值的操作系统都会无论磁盘如何都进行大量缓存)。
是的,智能 DBMS 还会尽可能地将数据缓存在 RAM 中(尊重对数据一致性、抗故障性等方面的承诺;在需要时,它会明确等待数据安全地存储在磁盘上后再继续)。
对于任何数据库来说,RAMdisk 都是纯粹的毒药(“数据明确写入磁盘,因此是安全的”不是)。
答案3
感谢大家的回答。它们非常有帮助。经过一些后续研究,我发现 I/O 速度并不是这种特定情况下的主要瓶颈,尽管它通常很重要。tempdb 管理的最佳实践包括至少有 4 个数据文件。Microsoft 还建议每个 CPU 核心有 1 个数据文件。拥有更多文件有助于减少某些争用问题。
关于此内容的一些链接:
答案4
因此 tempdb 的写入和读取 I/O 速率较高
RAM 太少。tempdb 仅在溢出时才进行 IO - 否则 SQL Server 不会将 tempdb 页面转储到磁盘。
因此,RAM 磁盘无济于事 - 最好添加更多内存。