PostgresSQL-内存分配

postgresql的内存分配主要由shared_buffers、temp_buffers、work_mem、maintenance_work_mem参数控制。

shared_buffers又能够叫作共享缓冲区，postgresql对数据操做时都要先将数据从磁盘读取到内存中，而后进行更新，最后再将数据写回磁盘。shared_buffers的功能就是用于存放从磁盘读取的数据。根据文档参数的设置范围通常在25%~40%之间。windows与linux对内存的管理方式不一样，在linux中须要注意共享段大小的设置(kernel.shmmax)。

temp_buffers称之为临时缓冲区，用于数据库会话访问临时表数据，系统默认值为8M。能够在单独的session中对该参数进行设置，尤为是须要访问比较大的临时表时，将会有显著的性能提高。

work_mem能够称之为工做内存或者操做内存。其负责内部的sort和hash操做，合适的work_mem大小可以保证这些操做在内存中进行。定义过小的话，sort或者hash操做将须要与硬盘进行swap，这样会极大的下降系统的性能；太大的话导致在可以在内存中完成的操做数量减小，其余的部分须要与磁盘进行swap操做，增长IO下降性能。系统提供的默认值是1M，在实际的生产环境中，要对系统监控数据进行分析，做出最好的选择。
大体有两种方式：估计方法与计算方法。第一种是能够根据业务量的大小和类型，通常语句运行时间，来粗略的估计一下。第二种方式是经过对数据库的监控，数据采集，而后计算其大小。总之合适的大小对系统的性能相当重要。
在实际的维护中能够经过explain analyze分析语句的work_mem大小是否合适。在语句中设置work_mem参数的大小能够充分利用内存，提升语句的执行效率。
对于work_mem内存分配时还要考虑数据库的并发状况，max_connections决定了系统的最大的并发链接数。不论如何调整work_mem都要考虑max_connections*work_mem+shared_buffers+temp_buffers+maintenance_work_mem+操做系统所需内存不可以超过整个的RAM大小，这是很是重要的。
work_mem参数对系统的性能是如此的重要，让其实时的适应数据库的运行情况显的不太可能，可是能够经过对数据库运行周期的监控，总结相应的数据，而后定制一个专用的脚本，专门用来修改work_mem的大小，使其阶段性的更加适应系统的情况，不失为一种好的方法。

maintenance_work_mem称之为维护工做内存，主要是针对数据库的维护操做或者语句。尽可能的将这些操做在内存中进行。主要针对VACUUM，CREATE INDEX，REINDEX等操做。在对整个数据库进行VACUUM或者较大的index进行重建时，适当的调整该参数很是必要。
postresql文档提示在启用了autoacuum功能的状况下，该参数不能配置的过大。

监听IPv4的全部IP.

listen_addresses = '0.0.0.0'

最大容许1000个链接.

max_connections = 1000

为超级用户保留3个可用链接.

superuser_reserved_connections = 3

默认的unix socket文件放在/tmp, 修改成$PGDATA, 以确保安全.

unix_socket_directory = '/pgdata/digoal/1921/data02/pg_root'

默认的访问权限是0777, 修改成0700更安全.

unix_socket_permissions = 0700

Linux下面默认是2小时.tcp的keepalives包发送间隔以及重试次数, 若是客户端没有响应, 将主动释放对应的SOCKET.

tcp_keepalives_idle = 60

tcp_keepalives_interval = 10

tcp_keepalives_count = 6

大的shared_buffers须要大的checkpoint_segments,同时须要申请更多的System V共享内存资源.

这个值不须要设的太大, 由于PostgreSQL还依赖操做系统的cache来提升读性能, 另外, 写操做频繁的数据库这个设太大反而会增长checkpoint压力.

shared_buffers = 512MB

这个值越大, VACUUM, CREATE INDEX的操做越快, 固然大到必定程度瓶颈就不在内存了, 多是CPU例如建立索引.

这个值是一个操做的内存使用上限, 而不是一次性分配出去的. 而且须要注意若是开启了autovacuum, 最大可能有autovacuum_max_workers*maintenance_work_mem的内存被系统消耗掉.

maintenance_work_mem = 512MB

通常设置为比系统限制的略少,ulimit -a : stack size              (kbytes, -s) 10240

max_stack_depth = 8MB

手动执行vacuum操做时, 默认是没有停顿执行到底的, 为了防止VACUUM操做消耗太多数据库服务器硬件资源, 这个值是指vacuum在消耗多少资源后停顿多少时间,以便其余的操做可使用更多的硬件资源.

vacuum_cost_delay = 10ms

#vacuum_cost_page_hit = 1               # 0-10000 credits

#vacuum_cost_page_miss = 10             # 0-10000 credits

#vacuum_cost_page_dirty = 20            # 0-10000 credits

#vacuum_cost_limit = 200                # 1-10000 credits

默认bgwriter进程执行一次后会停顿200ms再被唤醒执行下一次操做, 当数据库的写操做很频繁的时候, 200ms可能太长, 致使其余进程须要花费过多的时间来进行bgwriter的操做.

bgwriter_delay = 10ms

若是须要作数据库WAL日志备份的话至少须要设置成archive级别, 若是须要作hot_standby那么须要设置成hot_standby, 因为这个值修改须要重启数据库, 因此先设置成hot_standby比较好. 固然hot_standby意味着WAL记录得更详细, 若是没有打算作hot_standby设置得越低性能越好.

wal_level = hot_standby

wal buffers默认是-1 根据shared_buffers的设置自动调整shared_buffers*3% .最大限制是XLOG的segment_size.

wal_buffers = 16384kB

多少个xlog file产生后开始checkpoint操做, 这个值越大, 容许shared_buffer中的被频繁访问的脏数据存储得更久. 必定程度上能够提升数据库性能. 可是太大的话会致使在数据库发生checkpoint的时候须要处理更多的脏数据带来长时间的IO开销. 过小的话会致使产生更多的WAL文件(由于full page writes=on,CHECKPOINT后的第一次块的改变要写全块, checkpoint越频繁, 越多的数据更新要写全块致使产生更多WAL).

checkpoint_segments = 64

这个和checkpoint_segments的效果是同样的, 只是触发的条件是时间条件.

checkpoint_timeout = 5min

归档参数的修改也须要重启数据库, 因此就先打开吧.

archive_mode = on

这个是归档调用的命令, 我这里用date代替, 因此归档的时候调用的是输出时间而不是拷贝wal文件.

archive_command = '/bin/date'

若是要作hot standby这个必须大于0, 而且修改以后要重启数据库因此先设置为32.

max_wal_senders = 32

这是个standby 数据库参数, 为了方便角色切换, 我通常是全部的数据库都把他设置为on 的.

hot_standby = on

这个参数是说数据库中随机的PAGE访问的开销占seq_page_cost的多少倍 , seq_page_cost默认是1. 其余的开销都是seq_page_cost的倍数. 这些都用于基于成本的执行计划选择.

random_page_cost = 2.0

和上一个参数同样, 用于基于成本的执行计划选择. 不是说会用多少cache, 它只是个度量值. 表示系统有多少内存能够做为操做系统的cache. 越大的话, 数据库越倾向使用index这种适合random访问的执行计划.

effective_cache_size = 12000MB

下面是日志输出的配置.

log_destination = 'csvlog'

logging_collector = on

log_directory = '/var/applog/pg_log/digoal/1921'

log_truncate_on_rotation = on

log_rotation_age = 1d

log_rotation_size = 10MB

这个参数调整的是记录执行时间超过1秒的SQL到日志中, 通常用于跟踪哪些SQL执行时间长.

log_min_duration_statement = 1000ms

记录每一次checkpoint到日志中.

log_checkpoints = on

记录锁等待超过1秒的操做, 通常用于排查业务逻辑上的问题.

log_lock_waits = on

deadlock_timeout = 1s

记录DDL语句, 通常用于跟踪数据库中的危险操做.

log_statement = 'ddl'

这个本来是1024表示跟踪的SQL在1024的地方截断, 超过1024将没法显示全SQL. 修改成2048会消耗更多的内存(基本能够忽略), 不过能够显示更长的SQL. 

track_activity_query_size = 2048

默认autovacuum就是打开的, log_autovacuum_min_duration = 0记录全部的autovacuum操做.

autovacuum = on

log_autovacuum_min_duration = 0

这个模块用于记录数据库中的最近的1000条SQL以及这些SQL的统计信息, 如执行了多少次, 总共耗时是多少. 通常用于发现业务上最频繁调用的SQL是什么, 有针对性的进行SQL优化.

shared_preload_libraries = 'pg_stat_statements'

custom_variable_classes = 'pg_stat_statements'

pg_stat_statements.max = 1000

pg_stat_statements.track = all