我给postgres多少ram？ [英] how much ram do i give postgres?

问题描述

我知道这有点像辩论，但是我给了postgres多少ram？

我见过很多地方说10-15％左右或有些人说25％.... ...如果这台服务器正在运行的所有

运行postgres，为什么我不能给它75％+？

应该尽可能多的限制只要服务器没有
使用任何交换？


任何想法都会很棒，但我想知道原因。


谢谢。


-Josh


------------ ---------------（播出结束）---------------------------

提示8：解释分析是你的朋友

I know this is kinda a debate, but how much ram do I give postgres?
I''ve seen many places say around 10-15% or some say 25%....... If all
this server is doing is running postgres, why can''t I give it 75%+?
Should the limit be as much as possible as long as the server doesn''t
use any swap?

Any thoughts would be great, but I''d like to know why.

Thanks.

-Josh

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

推荐答案

Josh Close< na **** @ gmail。 COM>写道：

Josh Close <na****@gmail.com> writes:

我知道这有点像辩论，但是我给了多少公羊？
我见过很多地方说10-15％左右或者说25％左右。 ......如果这台服务器正在运行的是postgres，为什么我不能给它75％+？
只要服务器没有，限制应该尽可能多吗？ 't
使用任何交换？

I know this is kinda a debate, but how much ram do I give postgres?
I''ve seen many places say around 10-15% or some say 25%....... If all
this server is doing is running postgres, why can''t I give it 75%+?
Should the limit be as much as possible as long as the server doesn''t
use any swap?

简短的回答是否定的; shared_buffers的最佳位置通常是10000个缓冲区的顺序，并试图选择75％的RAM。除了伤害之外，我不会做任何事情。对于很长的答案，请参阅

pgsql-performance列表档案。


问候，tom lane


- -------------------------（播出结束）-------------------- -------

提示1：订阅和取消订阅命令转到 ma **** ***@postgresql.org

The short answer is no; the sweet spot for shared_buffers is usually on
the order of 10000 buffers, and trying to go for "75% of RAM" isn''t
going to do anything except hurt. For the long answer see the
pgsql-performance list archives.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

2004年10月19日星期二17:42:16 -0400，Tom Lane< tg * @ sss.pgh.pa.us>写道：

On Tue, 19 Oct 2004 17:42:16 -0400, Tom Lane <tg*@sss.pgh.pa.us> wrote:

简短的回答是否定的; shared_buffers的最佳位置通常是10000个缓冲区的数量级，并试图选择75％的RAM。除了伤害之外什么都不会做任何事情。对于很长的答案，请参阅
pgsql-performance list archives。

问候，tom lane

The short answer is no; the sweet spot for shared_buffers is usually on
the order of 10000 buffers, and trying to go for "75% of RAM" isn''t
going to do anything except hurt. For the long answer see the
pgsql-performance list archives.

regards, tom lane

好​​吧，我没有'''在list-archives中找到了很多，所以我通过电子邮件发送了

列出了更多问题。我的postgres服务器现在只是

爬行:(


-Josh


------ ---------------------（广播结束）------------------------ ---

提示5：您是否检查了我们广泛的常见问题解答？

http://www.postgresql.org/docs/faqs/FAQ.html

Well, I didn''t find a whole lot in the list-archives, so I emailed
that list whith a few more questions. My postgres server is just
crawling right now :(

-Josh

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

2004年10月19日17:35，Josh Close写道：

On 19 Oct 2004 at 17:35, Josh Close wrote:

好吧，我在列表档案中找不到很多内容，所以我通过电子邮件发送了

Well, I didn''t find a whole lot in the list-archives, so I emailed
that list whith a few more questions. My postgres server is just
crawling right now :(

与许多其他数据库引擎不同，Postgres的共享缓冲区是
不是数据库数据的私有缓存。它是一个工作区域，在所有后端进程之间共享

。这需要针对数量进行调整

连接和总体工作量，*不是*金额你希望保留在内存中的数据库

。关于什么是甜蜜点的问题仍有很多争论。是。也许没有一个，但它通常不是75％的内存。


如果有的话，effective_cache_size需要75％（可用） ）

RAM因为这告诉Postgres你的数据库* OS *是可能缓存在内存中的
。


话虽如此，我认为您需要定义抓取。它是b / b
更新/插入的速度慢吗？这可能是触发/规则/参考

完整性检查等正在减慢它。如果选择速度很慢，则此b / b
可能是不正确的索引或次优查询。你需要向我们展示

你要做什么以及结果如何。


问候，

加里。

---------------------------（广播结束）----------- ----------------

提示9：如果您的

加入专栏，计划员将忽略您选择索引扫描的愿望的数据类型不匹配

Unlike many other database engines the shared buffers of Postgres is
not a private cache of the database data. It is a working area shared
between all the backend processes. This needs to be tuned for number
of connections and overall workload, *not* the amount of your database
that you want to keep in memory. There is still lots of debate about what
the "sweet spot" is. Maybe there isn''t one, but its not normally 75% of
RAM.

If anything, the effective_cache_size needs to be 75% of (available)
RAM as this is telling Postgres the amount of your database the *OS* is
likely to cache in memory.

Having said that, I think you will need to define "crawling". Is it
updates/inserts that are slow? This may be triggers/rules/referential
integrity checking etc that is slowing it. If it is selects that are slow, this
may be incorrect indexes or sub-optimal queries. You need to show us
what you are trying to do and what the results are.

Regards,
Gary.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column''s datatypes do not match

这篇关于我给postgres多少ram？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！