PostgreSQL将在Windows上使用多少内存？

Question

我有Windows 2003 64位上的PostgreSQL 9.0 64位.该系统具有8x3 3GHz的CPU和8GB的内存。

如何/应该如何配置下列设置？

• shared_buffers
• work_mem
• maintenance_work_mem

这个数据库是用来进行分析的。在任何给定的时间，只连接两个或三个用户，运行查询。我认为，数据集可以在100万到1500万行之间。

底层存储是一个连接光纤通道的EMC CX存储阵列.这里的表演相当不错。

Answer 1

您将在调优PostgreSQL服务器上找到这三个参数的详细答案，以及可能需要调整的其他一些参数的建议。您将无法在Windows上使用shared_buffers的大型设置，在此情况下，它将停止帮助512 to左右。打开log_temp_files，看看会出现什么情况来确定您是否真的需要提高work_mem。基于您对数据集的看法，这听起来不像是会发出大量的单独查询，您甚至不需要担心这个问题。适度提升maintenance_work_mem可能有助于背景自动真空工作，但除非这对您成为一个问题，它不是关键的调整非常高。

Answer 2

正确的值取决于使用模式。然而，以下是一些指导方针

shared_buffers:专用postgresql服务器内存大小的25%。work_mem:用于排序之类的操作。单个连接可以多次使用此数量，因此，如果有大量的查询同时运行，请对此进行小心处理。这一项需要进行大量测试，以确定它是否提高了性能，但并没有使系统使用更多的内存。因此，如果增加内存，请确保系统不会开始使用过多的内存。就我个人而言，我经常从4MB这样的东西开始。

maintenance_work_mem:这是用于某些维护操作，如真空和索引设置相当高，一般是保存。64M或128 m通常是足够的。

还设置了有效的缓存大小。这是对计划器的提示，应该设置为os +共享缓冲区大小作为磁盘缓存使用的内存量。

如果您想进行广泛的调优，我建议您阅读一本关于它的好书：PostgreSQL 9.0高性能。

Answer 3

对于非常大的数据集，您可能会发现SAN不是最优的。SAN擅长于大量的小型ios系统，非常快。它们通常在顺序吞吐量方面是正常的，除非您有一个非常快速的连接到它们，而且即使这样，它们也常常不是针对顺序吞吐量进行优化的。我在我的机器上测试了顺序和随机读写性能，包括Areca和LSI RAID卡、带电池支持缓存的RAID卡、带有linux软件RAID的本机SAS接口以及后端的SAN。随机访问的最快速度接近于SAN和RAID卡，但对于顺序吞吐量，linux软件RAID将它们踩在地上。在HW RAID可以获得350米/S，而SAN在100米/S范围内(它连接在现场)，使用SW RAID的本地SAS可以读取1G/80，而在写时大约有80%。当然都是顺序的。不要以为你的SAN对于你正在做的事情来说是超快的，它可能是，也许不是。用bonnie++或dd之类的方法测试它，以了解它的实际速度。如果你得到的~100 10/S顺序，那么它将痛苦地慢在一个更便宜的机器与4或8 7200 for驱动器运行RAID-10进行分析。

当你说8x3GHz CPU时，你是指每个有4个或8个核心的8x插座吗？还是8个核心？还是有超线程的4个核心？对于你这样的工作来说，任何超过4个核心的东西总有可能是一种浪费。任何超过8个核心绝对是一种浪费。使用OLAP / Analytics，如果可以获得更少的更快的CPU，您就需要更少的CPU。

进入你的设置。shared_mem不需要成为真正的大人物。在windows上，共享内存的实现对于较大的值来说不是最优的，使其更大很少有助于提高性能。话虽如此，我还是会测试各种不同的值，但几百个梅格的速度可能很快。维修工作我可以在现场范围内，但最大的收益是它的曲柄超过100米左右。work_mem是postgresql的脚枪。如果您要将其升级，并且我建议在您的机器上至少运行16或32M，请确保将postgresql的max_connections参数限制在最多几十个连接上。如果有人同时启动了一堆查询，那么您就会很快耗尽RAM。不太好。OTOH，一些测试可能会显示，任何超过100左右的东西都不会有多大帮助。

将work_mem调高的危险在于，它最终会将操作系统缓存的数据推出缓存，而只需要重新加载。访问磁盘以获取数据的成本通常要高于真正提高数据的增益。

一个好的经验法则是保持work_mem*max_connections*2 < 1/4的记忆。因此，在一台有64G内存和100个连接的机器上，您可能希望work_mem*200 < 16G或大约80Megsmax。这确保了所有连接都运行多种类型的任何病态行为都不会太容易杀死机器。

如果您发现1G的work_mem比100 M等好得多，那么您可以通过让普通的work_mem更低的安全性和让运行大型查询的单线程在连接上设置自己的work_mem来折衷。

我同意前面的招贴画，windows对于pgsql来说不是最优的，并强调对于OLAP来说，更糟的是，能够分配更多的shared_memory对于pg / linux来说是一个优势。