PG资源消耗相关参数

资源消耗


1、内存
shared_buffers(integer)
设置数据库服务器将使用的共享内存缓冲区数量，通常缺省是4000（32MB），如果有专用的1GB或更多内存的数据库服务器，一个合理的shared_buffers开始值可以是25%，最好不要超过40%。Windows上可用的范围是64M到512M。


temp_buffers（integer)
设置每个数据库会话使用的临时缓冲区的最大数目，缺省是1000（8MB）。


max_prepared_transaction(integer)
设置可以同时处于预备状态的事务的最大数目，把这个参数设置为0则关闭预备事务的特性。这个值只能在服务器启动的时候设置。
当运行一个备库时，这个参数至少与主库上的一样大，否则备库上将不会执行查询。


work_mem(integer)
声明内部排序操作和hash表在开始使用临时磁盘文件之前使用的内存数目。
ORDER BY，DISTINCT和融合连接都要用到排序操作。Hash表在散列连接、散列为基础的聚集、散列为基础的IN 子查询处理中都要用到。 


maintenance_work_mem(integer)
声明在维护性操作（比如vacuum,create index,alter table add froeign key等）中使用的最大内存数。缺省16M。因为在一个数据库会话里，任意时刻只有一个这样的操作可以运行，并且一个数据库通常不会有太多这样的工作并发执行，把这个数值设置的比work_mem更大是安全的。更大的设置可以改进清理和恢复数据库转储的速度。


max_stack_depth(integer)
声明服务器的执行堆栈的最大安全深度。


2、磁盘
temp_file_limit(integer)
指定会话可以使用的临时文件的最大磁盘空间，如排序和哈希临时文件，或持有游标的存储文件。一个事务试图超过这个限制将被取消。缺省为-1，意味着没有限制，只有超级用户可以修改此限制。


3、内核资源
max_files_per_process(integer)
设置每个服务器进程允许同时打开的最大文件数目，缺省1000。如果有"too many open files"现象，尝试缩小这个设置，这个设置只能在服务器启动时设置。


shared_preload_libraries(string)
声明一个或多个在服务器启动的时候预先装载的共享库启动。可以用这个方法预先装载你PG的过程语言库。
通过预先加载共享库，可以避免第一次使用这个库的加载时间，不过服务器启动时间也会增加。如果没有找到声明的库，那么服务器将启动失败。


4、基于开销的清理延迟
在 VACUUM 和 ANALYZE 命令执行过程中，系统维护一个内部的记数器， 跟踪所执行 的各种I/O操作的近似开销。如果积累的开销达到了 vacuum_cost_limit声明的限制，那么执行这个操作的进程将睡眠 vacuum_cost_limit指定的时间。然后它会重置记数器然后继续执行。
这个特性的目的是允许管理员减少这些命令在并发活动的数据库上的 I/O 影响。比如，像 VACUUM 和 ANALYZE 这样的维护命令并不需要迅速完成，并 且不希望它们严重干扰系统执行其它的数据库操作。
这个特性是缺省关闭的。此功能默认情况下禁用手动发出 VACUUM 命令， 要想打开它，把 vacuum_cost_delay 变量设置为一个非零值。 


vacuum_cost_delay(integer)
以毫秒计算的时间长度，如果超过限制，那么进程将睡眠一会，缺省为0。
设置为10的倍数。


vacuum_cost_page_hit(integer)
清理一个在共享缓存里找到的缓冲区的预计开销，它代表锁住缓冲池、查找共享hash表、扫描页面内容的开销，缺省为1。


vacuum_cost_page_miss(integer)
清理一个要从磁盘上读取的缓冲区的预计开销，缺省为10。


vacuum_cost_page_dirty(integer)
清理修改一个原先是干净的块的预计开销。代表把一个脏块再次刷到磁盘上的额外开销，缺省20。


vacuum_cost_limit(integer)
导致清理进程休眠的积累开销，缺省为200。
注意：有些操作会持有关键的锁，并且应该尽快结束。在这样的操作过程中， 基于开销的清理延迟不会发生作用。 为了避免在这种情况下的长延时，实际的延迟是 vacuum_cost_delay* accumulated_balance/ vacuum_cost_limit 与 vacuum_cost_delay* 4 两者之间的最大值。  


5、后端写进程
有一个独立的服务器进程，叫做后端写进程，它唯一的功能就是发出写"脏" 共享缓冲区的命令。这么做的目的是让持有用户查询的服务器进程应该很少或者 几乎不等待写动作的发生，因为后端写进程会做这件事情。这样的安排同样也减
少了检查点造成的性能下降。后端写进程将持续的把脏页面刷新到磁盘上，所以 在检查点到来的时候，只有几个页面需要刷新到磁盘上。但是这样还是增加了 I/O 的总净负荷，因为以前的检查点间隔里，一个重复弄脏的页面可能只会冲刷 一次，而同一个间隔里，后端写进程可能会写好几次。在大多数情况下，连续的
低负荷要比周期性的尖峰负荷好。


bgwriter_delay(integer)
声明后端写进程活跃轮回之间的延迟。在每个轮回里，写进程都会为一些脏 的缓冲区发出写操作(可以用下面的参数控制)。然后它就休眠 bgwriter_delay 毫 秒(缺省值是 200ms)，然后重复动作。请注意在许多系统上，休眠延时的有效分 辨率是 10 毫秒；因此，设置一个不是 10 的倍数的数值与把它设置为下一个 10 的倍数是一样的效果。这个选项只能在服务器启动的时候或者在 postgresql.conf 文件里设置。 


bgwriter_lru_maxpages(integer)
在每个轮回里，不超过这么多个缓冲区将做为扫描到的即将回收使用的缓冲 区写入磁盘。缺省值是 100。这个选项只能在服务器启动的时候或者 在 postgresql.conf 文件里设置。


bgwriter_lru_multiplier(floating point)
每一轮要写的脏缓冲区的数目是根据最近几轮服务器进程需要的新的缓冲 区的数目。最近的平均值*bgwriter_lru_multiplier 以估算下一轮需要的缓冲区数目。。这 个选项只能在服务器启动的时候或者在 postgresql.conf 文件里设置。 
较小的 bgwriter_lru_maxpages 和 bgwriter_lru_multiplier 可以降低由 bgwriter 进程造成的额外的 I/O 开销。但更可能的是，服务器进程自己进行问题写入，拖 延了交互式查询。 


6、异步行为
effective_io_concurrency(integer)
设置并发磁盘 I/O 操作的数量，那么一些任务可以同时执行。 调高这个值， 可以增加 I/O 操作的数目（试图发起并行连接会话的数目）。允许的范围是 1 到 100，或 0（禁用异步 I/O 请求）。 
异步 I/O 是基于一个有效的 posix_fadvise 函数（一些操作系统可能没有） 如 果没有这个函数，那么这个参数设置为 0。在一些操作系统上（如 Solaris），虽 然提供了这个函数，但它不会做任何事情。