主页 / server / 问题 / 77779
Accepted
AngryHacker
Asked: 2009-10-24 13:27:46 +0800 CST

服务器实际需要多少 RAM？

  • 772

我在世界各地部署了很多服务器。他们运行 Windows 2003 x64 和 SQL Server 2005 x64 和 6 GB RAM。这些盒子没有最好的（甚至是可接受的）配置，因为多年前订购它们的人并不真正知道他在做什么。

这些盒子相当一致地耗尽内存，最终使用页面文件并且一切都变慢了。通常，提交费用是 5.8GB，然后当有人需要做一些密集的事情（例如运行报告）时，这个数字就会飙升。

我一直试图获得订购更多内存的权力，但我遭到了强烈反对（例如，使软件性能更高，所有这些服务器的成本过高，或者证明盒子没有足够的内存等。 ..)。

是否有关于我可以向非技术人员展示一个盒子需要多少 RAM 的指南（或公式），以便我们最终可以订购更多内存？

windows-server-2003

7 个回答

  1. 查看是否需要更多 RAM 的一种简单方法是绘制 Page Life Expectancy perfmon 计数器图表。此计数器告诉您 SQL Server 认为在需要为其他数据腾出空间之前，数据将在缓冲池中保留多长时间。您希望这个数字尽可能高。安装了 6 Gigs 的 RAM（您应该将 SQL 设置为最大可能 4 gigs），您可能最多只能将数据在内存中保存几分钟，当有人运行大型报告时，您会看到这个数字坦克减少到几秒钟。您拥有的 RAM 越多，内存中保存的数据就越长，需要从磁盘读取的数据就越少。

    例如，我目前使用的系统有 256 Gigs 的 RAM，我们将数据在内存中保存大约 12000 秒左右。

    请不要要求达到目标数字，您只希望数字尽可能高。在不了解您的系统的更多信息的情况下，我无法给出一个好的数字来拍摄。

    • 12
  2. Best Answer

    没有任何方法可以轻松分辨，因为它完全取决于您的使用情况和应用程序。您正在最大化数据库服务器...数据库有多大？你的交易统计是什么？

    在您的场景中，现实世界的限制是显而易见的。您在 6 gig 上运行了一段时间没有问题，然后它正在交换和颠簸。因此 6 gig 是不够的。

    如果性能足以影响业务，那么您的上级应该听到足够多的抱怨，因此谨慎地增加内存。算出你的时间成本，然后算出“调优”服务器和排除调优故障的成本，当内存添加到服务器时，可以很好地解决内存成本问题，不到半小时停机时间。

    在您在实际使用中实际部署并从那里开始工作之前，您不会知道所需的确切内存量。

    也就是说，您可能想要验证您的应用程序确实是瓶颈。运行 Windows 性能监视器以查看您的磁盘 i/o 统计信息和网络吞吐量。看看你的碎片级别是多少（谷歌是这里的好朋友）。您也可以尝试在查询非常低效的情况下审核代码以解决明显的问题（再次谷歌）。

    但同样，这一切都取决于这对业务的影响有多严重。是否值得在调优上投入更多资金，还是先扔硬件然后再尝试调优就够糟糕了？

    • 9

  3. 嗯。好吧，6 gigs 是相当数量的 ram，即使对于大型 MSSQL 安装也是如此。您可能实际上想要查看并确保您的代码确实有效。6 gig 交易有点不寻常...我在全州范围内工作过的工资系统在 1099 年末处理时没有超过 gig...并且经常运行？我不知道。您正在处理什么样的数据？

    话虽这么说，你可以在 64 位的盒子里装多少你喜欢的 RAM，而且 ram 很便宜，所以不妨尽可能多地放在那里……真的不能有太多的 RAM数据库服务器。

    编辑：这现在已经过时了。我有带有 256 GB RAM 的 MSSQL 盒子。

    编辑：每五年就会变得更有趣。

    • 6

  4. 在您急于购买更多内存（或任何其他组件）之前，我建议您在服务器上运行性能分析。您可以使用 perfmon 自己执行此操作，也可以考虑使用第三方工具。您应该分析操作系统和 SQL 服务器的性能。恕我直言，我们经常在进行适当分析之前就准备好将硬件投入问题。就目前所知，这可能是查询、存储过程、执行计划、磁盘 I/O、CPU 利用率等方面的问题。内存压力通常是系统中另一个瓶颈的征兆。

    • 4

  5. 正如“Satanicpuppy”所说，没有太多的RAM，但6GB应该没问题，也许你应该重新考虑一下你的服务器是做什么的，我不认为你有“硬件”问题，你应该专注于您的 SQL 编程...

    • 1

  6. 对于数据库服务器，没有“足够”内存之类的东西。当然，这取决于他们实际做什么和运行什么，但如果它是一个经常使用的数据库，其中包含大量数据并执行复杂的查询 - 6 GB 很容易严重不足。

    我首先将一台麻烦的服务器升级到至少 32 或 64 GB，看看它是否有帮助。如果没有，请转向数据库调优、应用程序故障排除和调试——除非白痴设计了数据库，否则所有这些都比几块服务器级内存要多得多（即使是白痴设计的东西，甚至得到明显的设计通过保留支持修复的错误可能是一个相当大的挑战）。

    也就是说，正如其他人所说 - 它可能是其他阻碍它的东西（除了软件设计问题），比如缺乏磁盘或网络 I/O 性能 - 聘请 DBA 专业人员只是通过基本的 SQL 性能监控天可能会被证明是有用的。

    • 1

  7. 您应该考虑构建更多索引。我认为一般来说，大多数人的数据库索引不足。

    这仍然是空气代码，我还没有完全测试，但它应该让你朝着正确的方向前进

    http://accessadp.com/2011/08/22/missing-indexes-great-script-for-determining-roi/

    Select ‘create index IX_’ +
 sys.objects.name +
 isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) +
 isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ +
 sys.objects.name +
 ‘(‘ +
 coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) +
 ‘) ‘ +
 isnull(‘ include (‘ + included_columns + ‘)’, ”)
 as CreateIndexSql,
 (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score,
 sys.schemas.schema_id,
 sys.schemas.name AS schema_name,
 sys.objects.object_id,
 sys.objects.name AS object_name,
 sys.objects.type,
 partitions.Rows, partitions.SizeMB,
 sys.dm_db_missing_index_details.equality_columns,
 sys.dm_db_missing_index_details.inequality_columns,
 sys.dm_db_missing_index_details.included_columns,
 sys.dm_db_missing_index_group_stats.unique_compiles,
 sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans,
 sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact,
 sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan,
 sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans,
 sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact,
 sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan
 FROM
 sys.objects
 JOIN (
 SELECT
 object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows,
 CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB
 FROM sys.dm_db_partition_stats
 WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table
 GROUP BY object_id
 ) AS partitions ON sys.objects.object_id=partitions.object_id
 JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id
 JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id
 JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle
 JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle
 WHERE
 sys.dm_db_missing_index_details.database_id=DB_ID()
 AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100
    • 0

相关问题