在一台服务器上,我在第二台服务器postgresql 9.1上运行sql server 2005. b / n这两个服务器的性能差异是惊人的,它在postgresql上是如此糟糕,我很遗憾我的初始“让我们使用postgresql而不是支付sql server license”的演讲给我的老板.我们说的是相同命令的30秒与15分钟之间的差异,并且不仅仅是这一个命令,它是我抛出的任何查询或命令.它们都具有几乎相同的数据(记录以不同的顺序插入),并且两个数据库具有完全相同的结构/索引等.
但我希望这只是性能调整的问题.问题是,sql server几乎在服务器上使用所有32演出的ram,而postgresl没有使用任何东西,肯定不到一个演出虽然我还没有真正弄清楚它的细节.
如何让postgresql使用20演出的ram？这些服务器是专门为这个数据库构建的,因此我认为任何未被数据库和支持流程使用的ram都被浪费了.
> 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上搜索几乎是免费的.
