RMu*_*esi 11 performance sql-server ssrs sql-server-2008-r2 hardware
我对 DBA 工作没有经验,但我正在尝试为我们的 sql server 请求额外资源提供一个案例,并希望我可以让一些聪明的人粗略估计我们应该运行的内容。我怀疑 IT 分配给我们的生产 sql server 的资源分配很低。
硬件软件:
数据库:sql server 2008 r2 企业数据库
Windows:Windows 2008 r2 Enterprise 64 位,非常确定可以在 VMware 上运行。
处理器:Intel(R) Xeon(R) CPU E7-4860 @ 2.27GHz 2.26 GHz(2 个处理器)
安装内存:4GB
数据库文件硬盘:300GB
备份硬盘:150GB
日志硬盘:100GB
应用:
我们有 3 个主要数据库,数据加起来大约为 170GB,同一台服务器上的 Reporting Services 数据库 (SSRS) 可能包含每天生成的 10 个不同的报告(每个报告平均包含 70 万条记录)。我们的用户群大约有 20 个同时使用的用户,其中 5 个可能被认为是“资源密集型”,生成数据处理大型报告。大多数用户通过asp.net 网站和报表服务器网站与数据库进行交互。此外,我们的开发人员通过直接远程连接到服务器(最多 2 个远程连接)在 BIDS 中广泛使用 SSIS。最后,我们有一个相当复杂的数据仓库操作,它可能每天通过也在服务器上运行的 SSIS 包带来 300 万条记录。
当前问题:
我们有长期的服务器超时,对网站的响应时间非常糟糕。我怀疑我们拥有的内存量(4GB)可能是一个很大的瓶颈。我们之前对额外内存的请求已被拒绝,因为我们需要执行更多查询优化的常见响应。虽然我们不是 sql 专业人士或(我相信您可以通过我们的设置看出)db admin 专业人士,但我想确保我不会花费所有时间试图挤出一点潜在的性能,如果硬件是瓶颈。
感谢所有人的 tl;dr 回避!
Jon*_*gel 14
......希望我能得到......对我们应该运行的粗略估计。
如果没有关于您的查询和数据大小的更多信息,就很难给您任何类型的估计,更不用说准确的估计了。
数据库:sql server 2008 r2 企业数据库
Windows:Windows 2008 r2 Enterprise 64 位,非常确定可以在 VMware 上运行。
处理器:Intel(R) Xeon(R) CPU E7-4860 @ 2.27GHz 2.26 GHz(2 个处理器)
安装内存:4GB
两个处理器(我假设这在 VM 中公开为 2 个内核)可能会或可能不会配置不足。分配给 VM 的内核不一定直接映射到物理内核(甚至在需要时允许 100% 使用单个内核!),因此您可能会发现这是比内存更灵活的资源。如果没有关于您的工作负载或硬件/虚拟化配置的更多信息,我会说将其增加到 4 会很好。
内存分配。好家伙。这对于工作负载来说严重不足。Windows 本身至少需要 2-3 GB 的空间才能保持快乐,而在机器上运行 BIDS 的 2 个用户中的每个用户至少需要 500 MB。有了这个,盒子已经用完了,我什至没有开始弄清楚数据库需要多少。
大多数用户通过asp.net 网站和报表服务器网站与数据库进行交互。
您没有说,但是如果它们在同一台机器上运行,则还需要考虑它们的内存要求。
最后,我们有一个相当复杂的数据仓库操作,它可能每天通过也在服务器上运行的 SSIS 包带来 300 万条记录。
假设它在系统上没有实时用户的晚上运行,除非运行时间太长,否则我不认为这是一个问题。这部分事情是你最不担心的;活用户更重要。
我们之前对额外内存的请求已被拒绝,因为我们需要执行更多查询优化的常见响应。
正如我上面所展示的,当前配置的内存量是完全不够的。但与此同时,在频谱的另一端,您极不可能获得足够的内存供应,以便能够一次将整个数据库保存在内存中。
即使您得到了这样的全面回应(顺便说一句,这可能更多地与您对额外资源的理由的说服力有关,而不是实际资源使用本身),但数据库的效率很可能是改进。然而,单靠调整无法解决您现在遇到的问题;这个建议对我来说完全是不可能的。
我会采取整体方法,即当前提供的内存量低于所需的最小值(应尽快更正),并且可能需要额外的资源来将用户体验提高到可用水平,同时进行改进以提高效率系统。
以下是一些想法(按攻击顺序):
如果您能证明每次获得更多资源时性能会提高多少,您就会获胜。使用性能监视器日志记录跟踪性能指标(注意:日志记录部分非常重要),如果可以,包括网站响应时间。在做任何其他事情之前,现在就开始这样做。当您最终达到最小内存量(您不会立即获得 32 GB)时,突然间您现在有证据表明增加的内存改善了一些事情……这意味着增加更多的内存可能也会有所帮助!如果您不收集当前配置的基线,那么当事情达到推荐的最低水平时,您将错失良机。
分析服务器的等待统计信息。这将告诉您系统中最大的瓶颈是什么。您可能会遇到PAGEIOLATCH_XX
最常见/最长的等待时间,这表明正在执行过多的 I/O 以从磁盘获取页面。这可以通过添加内存来缓解,因此物理 I/O 变得不那么频繁,因为所需的数据已经在内存中。虽然此分析几乎已成定局,但您已经收集了这些统计数据的事实在证明对资源的需求合理时为您提供了更多弹药。
正如我上面提到的,没有满足对内存的最低要求。为您正在运行的所有软件收集一组推荐的硬件要求,也许还可以抓取任务管理器的屏幕截图。仅此一项就足以立即证明至少多 4-8 GB。如果他们仍然拒绝,请尝试说服他们允许您试用一周,然后再将其退回(您正在收集性能统计数据,因此您不需要退回,因为您在周中)将能够证明它在多大程度上改善了情况)。如果他们仍然拒绝,你就注定要失败;网址。
如果您可以卸载一些工作负载(特别是,尽可能避免远程处理),这将增加可用于数据库的内存量,这一点更为关键。
您将无法一次将整个数据库放入内存中,这意味着您需要非常小心地设置 SQL Server 的最大内存设置,以防止内存过度使用,这会像其他任何事情一样扼杀性能。过度提交实际上比根本无法将所有数据放入内存中更糟糕。您现在很可能处于这种情况,因为根本没有可用内存,并且最大内存设置很可能设置为默认值(无限制)。
由于您运行的是 SQL Server 企业版,并且内存非常宝贵,因此我强烈考虑实施数据压缩。这将权衡 CPU 使用率的增加以节省内存空间(从而减少磁盘访问,这相对非常慢)。
调优数据库。就索引和访问模式而言,结构和查询可能会使用改进。此外,如果经常扫描和聚合大量数据,创建索引视图、汇总表或预先计算的报告可能会非常有用。
这可能是一个长期目标,因为它可能意味着更多的硬件配置,但要实施缓存解决方案。最快的查询是您从未进行过的查询。
这些只是一些想法。最重要的是,单独调整不能解决这里的问题,单独硬件也不能解决问题,即使后者可能会缓解大多数直接问题。这确实是这样的:在短期内将硬件投入到问题中以扑灭大火,并在长期内对问题进行调整以尽可能地解决根本原因。
这是帐户“豆子计数器”的疯狂。您花在 RAM 上的 1100-2500 美元可能会在一周内收回成本!
他们为 20 名员工安排了休假,其中 5 人从事“资源密集型”工作。我想他们的时间并不便宜,而且其中一些报告是老板不会在薪水上签字的人会喜欢的。这是大量浪费的重新传输和处理挫折。
向他们解释他们可能会考虑每 GB 15-20 美元的 RAM。现在 128GB 的 RAM 大约为 2200-2500 美元,而且 RAM 价格目前略有上涨。即使你的服务器主板不能支持它(这会很奇怪),那么 64GB 也将是 1100-1200 美元(我刚刚查了一下,这是戴尔的服务器内存质量,没有折扣)。即使是 64GB 的内存也会产生巨大的差异(特别是如果我们确保避免对大表进行表扫描)。
弄清楚浪费了多少时间,并询问他们是否值 1100-2500 美元。如果您只花费 1100 美元并获得 64GB 内存,请确保避免在大表上进行表扫描。使用更多带有索引的磁盘(如果您有支持它的延迟)以避免大扫描转储内存。
归档时间: |
|
查看次数: |
13983 次 |
最近记录: |