06月18, 2019

postgresql参数调整和性能优化

在最近的项目中在使用postgresql存储大量半结构化数据,最大的表在1000万行以上。由于应用中使用了较复杂的SQL,查询必能明显变慢。

在综合比较列存储方案如cstore_fdw,clickhouse, greenplum 后,决定继续使用postgresql,避免上层应用修改。通过调整pg参数,充分使用硬件资源来改进性能,同时利用POSTGRESQL多种类型的索引。

主要选项

选项 默认值 修改值 说明 是否优化 原因
max_connections 100 允许客户端连接的最大数目 因为在测试的过程中,100个连接已经足够
fsync on off 强制把数据同步更新到磁盘 因为系统的IO压力很大,为了更好的测试其他配置的影响,把改参数改为off
shared_buffers 24MB 8GB 决定有多少内存可以被PostgreSQL用于缓存数据(推荐内存的1/4) 在IO压力很大的情况下,提高该值可以减少IO
work_mem 1MB 64MB 使内部排序和一些复杂的查询都在这个buffer中完成 有助提高排序等操作的速度,并且减低IO
effective_cache_size 128MB 2GB 优化器假设一个查询可以用的最大内存,和shared_buffers无关(推荐内存的1/2) 设置稍大,优化器更倾向使用索引扫描而不是顺序扫描
maintenance_work_mem 16MB 512MB 这里定义的内存只是被VACUUM等耗费资源较多的命令调用时使用 把该值调大,能加快命令的执行
wal_buffer 768kB 16MB 日志缓存区的大小 可以降低IO,如果遇上比较多的并发短事务,应该和commit_delay一起用
checkpoint_segments 3 设置wal log的最大数量数(一个log的大小为16M) 默认的48M的缓存是一个严重的瓶颈,基本上都要设置为10以上
checkpoint_completion_target 0.5 0.9 表示checkpoint的完成时间要在两个checkpoint间隔时间的N%内完成 能降低平均写入的开销
commit_delay 0 10 事务提交后,日志写到wal log上到wal_buffer写入到磁盘的时间间隔。需要配合commit_sibling 能够一次写入多个事务,减少IO,提高性能
commit_siblings 5 4 设置触发commit_delay的并发事务数,根据并发事务多少来配置 减少IO,提高性能

1.shared_buffers

PostgreSQL既使用自身的缓冲区,也使用内核缓冲IO。这意味着数据会在内存中存储两次,首先是存入PostgreSQL缓冲区,然后是内核缓冲区。这被称为双重缓冲区处理。对大多数操作系统来说,这个参数是最有效的用于调优的参数。此参数的作用是设置PostgreSQL中用于缓存的专用内存量。

shared_buffers的默认值设置得非常低,因为某些机器和操作系统不支持使用更高的值。但在大多数现代设备中,通常需要增大此参数的值才能获得最佳性能。

建议的设置值为机器总内存大小的25%,但是也可以根据实际情况尝试设置更低和更高的值。实际值取决于机器的具体配置和工作的数据量大小。举个例子,如果工作数据集可以很容易地放入内存中,那么可以增加shared_buffers的值来包含整个数据库,以便整个工作数据集可以保留在缓存中。 在生产环境中,将shared_buffers设置为较大的值通常可以提供非常好的性能,但应当时刻注意找到平衡点。 查看当前shared_buffers的值:

postgres=# show shared_buffers;
 shared_buffers 
----------------
 128MB

2.effective_cache_size

优化器假设一个查询可以用的最大内存,和shared_buffers无关(推荐内存的1/2)

effective_cache_size提供可用于磁盘高速缓存的内存量的估计值。它只是一个建议值,而不是确切分配的内存或缓存大小。它不会实际分配内存,而是会告知优化器内核中可用的缓存量。在一个索引的代价估计中,更高的数值会使得索引扫描更可能被使用,更低的数值会使得顺序扫描更可能被使用。在设置这个参数时,还应该考虑PostgreSQL的共享缓冲区以及将被用于PostgreSQL数据文件的内核磁盘缓冲区。默认值是4GB。

3.wal_buffers

PostgreSQL将其WAL(预写日志)记录写入缓冲区,然后将这些缓冲区刷新到磁盘。由wal_buffers定义的缓冲区的默认大小为16MB,但如果有大量并发连接的话,则设置为一个较高的值可以提供更好的性能。

4.work_mem

此配置用于复合排序。内存中的排序比溢出到磁盘的排序快得多,设置非常高的值可能会导致部署环境出现内存瓶颈,因为此参数是按用户排序操作。如果有多个用户尝试执行排序操作,则系统将为所有用户分配大小为work_mem *总排序操作数的空间。全局设置此参数可能会导致内存使用率过高,因此强烈建议在会话级别修改此参数值。默认值为4MB

5.maintenance_work_mem

maintenance_work_mem是用于维护任务的内存设置。默认值为64MB。设置较大的值对于VACUUM,RESTORE,CREATE INDEX,ADD FOREIGN KEY和ALTER TABLE等操作的性能提升效果显著。

6.synchronous_commit

此参数的作用为在向客户端返回成功状态之前,强制提交等待WAL被写入磁盘。这是性能和可靠性之间的权衡。如果应用程序被设计为性能比可靠性更重要,那么关闭synchronous_commit。这意味着成功状态与保证写入磁盘之间会存在时间差。在服务器崩溃的情况下,即使客户端在提交时收到成功消息,数据也可能丢失。

7.checkpoint_timeout和checkpoint_completion_target

PostgreSQL将更改写入WAL。检查点进程将数据刷新到数据文件中。发生CHECKPOINT时完成此操作。这是一项开销很大的操作,整个过程涉及大量的磁盘读/写操作。用户可以在需要时随时发出CHECKPOINT指令,或者通过PostgreSQL的参数checkpoint_timeout和checkpoint_completion_target来自动完成。 checkpoint_timeout参数用于设置WAL检查点之间的时间。将此设置得太低会减少崩溃恢复时间,因为更多数据会写入磁盘,但由于每个检查点都会占用系统资源,因此也会损害性能。此参数只能在postgresql.conf文件中或在服务器命令行上设置。 checkpoint_completion_target指定检查点完成的目标,作为检查点之间总时间的一部分。默认值是 0.5。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。高频率的检查点可能会影响性能。

参考来源

感谢网络上博主的分享

本文链接:http://57km.cc/post/postgresql db turning.html

-- EOF --

Comments