Postgres DISK IO很高。我该怎么做才能立即减少呢？

13

我知道比使用的磁盘快的磁盘会有所帮助，但这会花费更长的时间，因此我尝试使用一些紧急措施来减少磁盘IO。atop几乎一直在报告红色的DSK使用情况。这是针对postgres 8.3的。

我的shared_buffers设置为24MB，尽管服务器有16GB的ram没有得到充分利用。我的第一个想法是为数据库提供尽可能多的内存，但是我不确定如何做到这一点（这是一台专用的数据库服务器）。

任何不需要重启的解决方案都是可取的，但是我将尽我所能。

谢谢！

linux postgresql hard-drive

— 哈雷尔
source

这个问题应该在Serverfault上问-Francisco

— R

您可以尝试shared_buffers在postgresql.conf配置文件中增加。此更改需要重新启动。另外，您可能需要在此/proc/sys/kernel/shmmax之前增加其值。

— 哈立德

12

24MB shared_buffers设置是保守的默认设置，对于具有16GB RAM的专用数据库，它的设置需要高很多。但是，是的，您必须重新启动服务器以调整其大小。http://wiki.postgresql.org/wiki/Performance_Optimization是开始获得性能配置准则的好地方。将shared_buffers设置为4GB或6GB似乎更合理。

请注意，在Linux上，您需要调整kernel.shmmax sysctl设置（在/etc/sysctl.conf中，或者仅通过编写/ proc / sys / kernel / shmmax）来分配大量共享内存的块。如果不这样做，将会出现错误，指出请求的数量，您必须将kernel.shmmax设置得更高。

由于您有很多内存，因此您可能还考虑将默认的work_mem设置得更高，这样会使诸如排序和散列（组/顺序/区别等）之类的事情倾向于在内存中工作，而不是使用临时文件。您无需重新启动服务器即可执行此操作，只需更新配置文件，重新加载服务即可，新会话将获得新设置。会话的默认工作内存为1MB，您可以计算一次可以使用的最大内存，work_mem * max_client_connections并估算将产生的影响。

您还应该增加effective_cache_size，以向计划者表明，内核FS层可能正在PostgreSQL共享缓冲区之外的内存中缓存很多页面。

等等。希望这能使您有个良好的开端。

— 阿拉克尼德
source

好的帖子，只有您的内存使用估算值有点危险。work_mem是每个sort / hash操作的最大值，因此复杂的查询可以具有多个sort / hash操作，因此可以使用一个以上的work_mem。

— Eelke 2011年

谢谢，它帮了很多忙！另一个重大更改是checkpoint_segment和checkpoint_completion_target，它们对我的磁盘使用率和总体性能产生了重大影响。避免危机。（wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server）

— Harel的

3

使用noatime重新挂载磁盘

— 杰姆斯波
source

2

除了此处提供的建议外，您可能还需要研究自动真空设置。默认情况下，它将在大约50次更新后触发，并且如果您的数据库正在执行大量更新/插入操作，这可能会触发不必要的真空语句，从而产生大量的IO。

— 吉士
source

1

在非常接近正常运行期间最大I / O吞吐量的系统上，您可能需要增加checkpoint_completion_target来减少来自checkpoint的I / O负载。这样做的缺点是延长检查点会影响恢复时间，因为需要保留更多的WAL段以用于恢复中

在这里查看更多。

— 基督教
source

0

如果postgresql的磁盘空间很高，则应检查正在运行的语句，尤其是对于语句，在磁盘上进行“排序”，并设置适当的索引。

仅在Google上搜索“ Postgresql Performance Tuning”，您就会找到足够的后盾。

— 托马斯·伯格
source