为大量的ram调整postgresql

前端之家收集整理的这篇文章主要介绍了为大量的ram调整postgresql前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有两个相同的服务器(在硬件方面),它们都是 windows server 2008 r2的标准安装,安装了最少的软件(基本上是我的代码和jvm等所需的东西).

在一台服务器上,我在第二台服务器postgresql 9.1上运行sql server 2005. b / n这两个服务器的性能差异是惊人的,它在postgresql上是如此糟糕,我很遗憾我的初始“让我们使用postgresql而不是支付sql server license”的演讲给我的老板.我们说的是相同命令的30秒与15分钟之间的差异,并且不仅仅是这一个命令,它是我抛出的任何查询或命令.它们都具有几乎相同的数据(记录以不同的顺序插入),并且两个数据库具有完全相同的结构/索引等.

但我希望这只是性能调整的问题.问题是,sql server几乎在服务器上使用所有32演出的ram,而postgresl没有使用任何东西,肯定不到一个演出虽然我还没有真正弄清楚它的细节.

如何让postgresql使用20演出的ram?这些服务器是专门为这个数据库构建的,因此我认为任何未被数据库支持流程使用的ram都被浪费了.

有许多可调整的常量,通过postgres.conf初始化.最重要的是:

> max_connections:并发会话数
> work_mem:用于中间结果(如哈希表)和排序的最大内存量
> shared_buffers专用于’固定’缓冲区空间的内存量.
> effective_cache_size OS的LRU缓冲区假定使用的内存量.
> random_page_cost:磁盘搜索相对成本的估算值.

max_connections不应设置得高于所需,连接成本资源即使在空闲时也是如此;在大多数情况下,连接会花费更多时间在室内等待而不是在外面等(以并发的代价)一个很好的经验法则是“处理器X的主轴数”

work_mem很棘手:可以应用于每个子查询,因此使用5个HASHJOINS的查询可能需要花费5 * work_mem.对于最坏情况,您还应该考虑使用此数量的多个会话(同样是保持max_connections低的原因).

shared_buffers是(恕我直言)被高估了.通常建议将其设置为所有可用“空闲”内存的大约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上搜索几乎是免费的.

原文链接:https://www.f2er.com/postgresql/192228.html

猜你在找的Postgre SQL相关文章