服务器，我在第二台服务器postgresql 9.1上运行sql server 2005。这两个服务器在性能方面的差异是惊人的，在postgresql上是如此糟糕，以至于我对老板最初的“让我们使用postgresql而不是为sql server许可证付费”感到遗憾。对于同一条命令，我们说的是30秒与15分钟之间的差异，这不只是一个命令，而是我向它抛出的任何查询或命令。它们都具有几乎相同的数据（记录以不同的顺序插入），并且两个数据库具有完全相同的结构/索引等。
但是我希望这只是性能调整的问题。事实是，sql server几乎在服务器上使用了所有32 gig的ram，而postgresl却什么也没用，虽然我实际上还没有弄清楚它的细节，但绝对少于gig。
如何获取postgresql使用20多个演出的ram？这些服务器是专门为此数据库材料构建的，因此，我认为数据库和支持过程未使用的所有内存都是浪费的。
#1 楼
有许多可调整的常量，通过postgres.conf初始化。最重要的是：max_connections：并发会话数work_mem：用于中间结果的最大内存量例如哈希表，以及用于排序shared_buffers专用于“固定”缓冲区空间的内存量。effective_cache_size操作系统的LRU假定使用的内存量random_page_cost：磁盘搜索相对成本的估计。max_connections不应设置得比需要的高，即使空闲，连接也会占用资源。在大多数情况下，连接在内部等待的时间比在外部等待的时间更多。 （以并发为代价）一个很好的经验法则公式是“主轴数+处理器数+ X” work_mem棘手：可以应用于每个子查询，因此查询5个HASHJOINS的价格可能是5 * work_mem。对于最坏的情况，您还应该考虑多个会话消耗此数量（这也是将max_connections保持在较低水平的原因）。shared_buffers被（IMHO）高估了。通常建议将其设置为所有可用“空闲”内存的大约1/4 ... 1/2，但我倾向于将其设置为较低，并将effective_cache_size设置为所有可用“空闲”内存。 random_page_cost是在磁盘上进行查找和读取的成本。它相对于sequential_disk_cost（为1）而言。对于现代计算机和网络存储，random_page_cost的默认值（4）设置得太高，通常可以将其降低到2和1.x之间。对于SSD磁盘，您甚至可以将其设置为1.0，因为在SSD上搜索几乎是免费的。评论
优秀的！我从来没有见过有效的缓存大小的重要性，它总是只与shared_buffers混为一谈。这确实产生了很大的变化。我也运行pgtune，它建议将20GB的96用于shard_buffers，但将64GB用作有效的cache_size。谢谢！
–user44466
14年7月26日在22:28
FWIW，我仔细阅读了Postgres文档中建议的这些设置和其他设置，并对服务器进行了分析。
– mlissner
2015年11月19日，0：28
非常感谢您的回答。我可以问一下，当max_connections默认为100且服务器RAM为32GB（专用的postgres服务器）时，推荐的work_mem是什么吗？我知道我需要根据每天的查询自行进行调整。我只是想知道您是否可以告诉我“一种尺寸能解决所有问题”的值（或起点值）。 50MB太大了吗？非常感谢。
– sgon00
19年6月12日14:00
这取决于计算机上典型的并发活动。 100个会话需要50M（在其10.20M之上）可能适合。或者，可能不会。要获得印象，请监视vmstat或top。加：这取决于您的查询（和其他）。看看计划。
–wildplasser
19年6月12日在14:20
@wildplasser非常感谢您的快速回复。我找到了一个有趣的网站pgtune.leopard.in.ua。我认为我将以40MB为起点，并根据其建议进行调整。干杯。
– sgon00
19年6月12日在15:43
#2 楼
考虑使用PGTune帮助您调整PostgreSQL配置。PostgreSQL的默认配置非常保守，该工具旨在帮助您解决这种确切情况。该文档非常容易阅读，并且使用该工具非常简单。
请记住，无需使用PGTune的确切建议。玩游戏的设置并查看对conf文件的最终更改，可以使您更好地了解PostgreSQL的配置以及如何手动对其进行调整。
有关PGTune和名为ClusterControl的替代工具的更多信息：PGTune替代品-ClusterControl PostgreSQL配置
评论
pgtune的最新更新是在5年前的2009年，并且仍在不断增长。我想知道它是否仍适用于9.1-9.2-9.3系列。
–索林
2014年2月12日下午13:35
pgtune现在可以在线使用
– Alfabravo
2015年12月2日在18:29
pgtune网址指向另一个网站。
– Dimitrios Desyllas
20年7月23日在12:47
@DimitriosDesyllas已修复，谢谢！
– Paul Bellora
20/07/27在20:59
#3 楼
如果每个查询或命令运行缓慢，我怀疑：您为运行的每个查询连接到数据库；
您已配置了某种身份验证方法，但该方法没有工作，并会暂停查询，直到此特定的身份验证方法超时为止。
请告诉我们运行
select version()之类的查询需要多少时间？如果应该是即时的（在我的工作站上为0.16ms）。#4 楼
如果每个查询的速度都慢得多，则服务器或某些设备完全错误。以我的经验，每个数据库都有一些比其他数据库更好的地方，但是性能明智的pgsql很容易与mssql服务器处于同一领域。那么，您在哪个操作系统上运行pgsql？什么硬件？您已经更改了哪些设置？您的数据集有多大？不良查询的示例是什么，解释输出的输出是什么（像这样运行查询：
解释分析select ...其余查询在这里...;
将输出发布到http://explain.depesz.com/并在此处发布链接。
评论
是的，每个查询/命令运行缓慢，是的，“某事”是完全错误的，因此是我的问题。问题在于，mssql正在充分利用服务器上的可用ram（如此繁重的缓存），而psql却没有。我感谢您的意见和建议，但是您一定错过了我的大部分问题和主题行本身。我只是想知道如何使用可用的ram来获取psql；目前正在尝试其他人列出的一些建议...
–user85116
2012年5月29日20:39
使用您的内存不是问题。 Postgresql依赖操作系统来执行大多数缓存。因此，不需要使用所有RAM。同样，您错过了我的大部分观点。您给我们的宝贵帮助很少。我以5000 TPS postgresql集群为生。您可以听取我的建议，或者继续认为自己知道pgsql的工作原理并进行争论。
–斯科特·马洛（Scott Marlowe）
2012年5月29日23:00
@ user85116，请听到Scott的声音，我们已经有了MySQL的工作流，该工作流依赖于超级延迟，因此，当前MySQL正在使用64GB ram来快速执行该查询，而在具有实体化视图的2G Postgres上可以实现相同的功能。将所有数据库缓存到RAM不会解决您的问题，只会使其不那么可见。如果您在数据库结构中存在相同的问题，Postgres将不会为您修复它，也不会尝试将其隐藏。
–kworr
19年4月24日在20:23
评论
您是否对初始调整进行了任何更改？第一步：设置有效缓存大小= 18G； （默认设置非常低）BTW：假设这是一台64位计算机（无PTE）您确实没有给我们足够的帮助。除了“很慢”以外，我们对您的数据集不了解很多，您如何访问它，通常哪种类型的查询运行缓慢，您已经完成了调优（甚至可能调错）服务器的工作。哎呀，在具有许多内核和内存通道的Linux机器上，在安装postgresql之前，您可能会获得糟糕的性能。您受CPU或IO约束吗？您已经有哪些非默认设置？哪种查询速度慢？
Postgres不会像您所说的那样“使用ram”。它的大部分缓存都依赖于OS文件系统页面缓存，因此，当您在运行postgres的系统上观看ram使用情况时，通常会看到OS缓冲区/缓存正在使用许多GB，而单个postgres后端进程仅使用了几个每个数十MB。
看到这个链接：tekadempiere.blogspot.ae/2014/09/…并从这里找到基于资源的conf值：pgtune.leopard.in.ua
相关的问题，可能感兴趣：stackoverflow.com/questions/47311485/…