PostgreSQL手册之资源消耗

内存

　　shared_buffers (integer)

设置数据库服务器将使用的共享内存缓冲区数量。缺省通常是 1000，如果你的内核设置不支持这么大，那么可以少些（在 initdb 的时候决定）。每个缓冲区大小的典型值是 8192 字节，除非你在编译的时候修改了 BLCKSZ 的值。这个数值必须大于 16，并且至少是 max_connections 数值的两倍；不过，这个数值大一些通常可以改进性能。对于生产安装，我们通常建议是几千。这个选项只能在服务器启动的时候设置。

增大这个参数可能导致 PostgreSQL 要求更多 System V 的共享内存，超出你的操作系统配置许可的范围.
work_mem (integer)

声明内部排序操作和散列表在开始使用临时磁盘文件之前使用的内存数目。数值是以千字节为单位的，缺省是 1024 千字节（1 MB）。请注意对于复杂的查询，可能会同时并发运行好几个排序或者散列操作；每个都会被批准使用这个参数声明的这么多内存，然后才会开始求助于临时文件。同样，好几个正在运行的会话可能会同时进行排序操作。因此使用的总内存可能是 work_mem 的好几倍。在 ORDER BY，融合连接，以及 CREATE INDEX 里都要用到排序操作。散列表在散列连接，散列为基础的聚集，以及散列为基础的 IN 子查询处理中都要用到。

maintenance_work_mem (integer)

声明在维护性操作中使用的最大的内存数，比如 VACUUM， CREATE INDEX，和 ALTER TABLE ADD FOREIGN KEY 等。数值是用千字节计的，缺省是 16384 千字节（16 MB）。因为在一个数据库会话里，任意时刻只有一个这样的操作可以执行，并且一个数据库安装通常不会有太多这样的工作并发执行，把这个数值设置得比 work_mem 更大是安全的。更大的设置可以改进清理和恢复数据库转储的速度。

max_stack_depth (integer)

声明服务器的执行堆栈的最大安全深度。为此设置一个参数的原因是内核强制的实际堆栈尺寸（就是 ulimit -s 或者局部等效物的设置），小于一个安全的一兆字节左右的范围。需要这么一个安全的界限是因为在服务器里，并非所有过程都检查了堆栈深度，儿只是在可能递规的过程，比如表达式计算这样的过程里面进行检查。把这个参数设置得大于实际的内核限制讲意味着一个正在跑的递归函数可能会导致一个独立服务器进程的崩溃。缺省设置是 2048 KB （两兆），这个值相对比较小，不容易导致崩溃。但是，这个值可能太小了，以至于无法执行复杂的函数。

自由空间映射

max_fsm_pages (integer)

设置在共享的自由空间映射表里自由空间会跟踪的最大数目的磁盘页面数。每个页面槽位需要消耗六个字节的共享内存。这个设置必须大于 16 * max_fsm_relations。缺省是 20000。这个选项只能在服务器启动的时候设置。

max_fsm_relations (integer)

设置自由空间将在共享地自由空间映射里跟踪的最大数目的关系（表和索引）。每个槽位大概要使用五十字节左右。缺省是 1000。这个选项只能在服务器启动的时候设置。

内核资源使用

max_files_per_process (integer)

设置每个服务器进程允许同时打开的最大的文件数目。缺省是 1000。如果内核强制一个合理的每进程限制，那么你不用操心这个设置。但是在一些平台上（特别指出的是，大多数 BSD 系统）， sysconf 返回一个系统真正可以支持的数目大的多的数值。如果你发现有 "Too many open files" 这样的失败现象，那么就尝试缩小这个设置。这个选项只能在服务器启动时设置。

preload_libraries (string)

这个变量声明一个或者多个在服务器启动的时候预先装载的共享库。可以选择在装载每个库的时候调用一个无参数的初始化函数。要声明这个函数，可以在库名字后面加一个冒号，然后增加一个初始化函数名字。比如 '$libdir/mylib:mylib_init' 会预先装载 mylib 并且执行 mylib_init。如果装载了多过一个库，用逗号分隔它们。

如果没有找到声明的库或者没有找到初始化函数，那么服务器将启动失败。

可以用这个方法预先装载 PostgreSQL 的过程语言库，通常是使用 '$libdir/plXXX:plXXX_init' 语法，这里的 XXX 是 pgsql，perl，tcl，或者 python。

通过预先装载一个共享库（以及在需要的时候初始化它），我们就可以避免第一次使用这个库的那些启动时间。不过，启动每个服务器进程的时间可能会增加，即使进程从来没有使用过这些库也这样。因此我们只是建议对那些将被大多数会话使用的库才使用这个选项。

基于开销的清理延迟

在 VACUUM 和 ANALYZE 命令执行过程中，系统维护一个内部的指针，这个指针跟踪所执行的各种 I/O 操作的近似开销。如果积累的开销达到了一个限制（通过 vacuum_cost_limit 声明），那么执行这个操作的进程将睡眠一会儿（用 vacuum_cost_delay 声明）。然后它会重置指针然后继续执行。

这个特性的目的时允许管理员减少这些命令在并发活动的数据库上的 I/O 影响。有些情况下，像 VACUUM 和 ANALYZE 这样的维护命令并不需要迅速完成；但是，通常都不希望这些命令会严重干扰系统执行其它数据库操作的响应能力。基于开销的清理延迟为管理员提供了一个实现这个目的的手段。

缺省的时候，这个特性是关闭的。要想打开它，把 vacuum_cost_delay 变量设置为一个非零值。

vacuum_cost_delay (integer)

以毫秒计的时间长度，如果超过了开销限制，那么进程将睡眠一会儿。缺省值是 0，它关闭基于开销的清理延迟特性。正数值打开基于开销的清理。不过，要注意在许多系统上，sleep 延迟的有效分辨率是 10 毫秒；把 vacuum_cost_delay 设置为一个不是 10 的整数倍的数值与将它设置为下一个 10 的整数倍作用相同。

vacuum_cost_page_hit (integer)

清理一个在共享缓存里找到的缓冲区的开销。它代表锁住缓冲池，查找共享的散列表以及扫描页面的内容的开销。缺省值是 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 之间的最大值。

后端写进程

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

bgwriter_delay (integer)

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

bgwriter_percent (integer)

在每个回合里，当前的脏缓冲区中不超过这个百分比的量将被写到磁盘上（把小数圆整为下一个整数缓冲区的数值）。这个选项只能在服务器启动的时候或者 postgresql.conf 文件里设置。

bgwriter_maxpages (integer)

在每个回合里，不超过这个数值的脏缓冲区写入。缺省值是 100。这个选项只能在服务器启动的时候或者 postgresql.conf 文件里设置。

小的 bgwriter_percent 和 bgwriter_maxpages 减少后端写进程导致的额外 I/O 负荷，但是会导致在检查点的时候的更多工作。要降低检查点时的峰值负荷，增加这些值。要想完全关闭后台写进程，可以把 bgwriter_percent 和/或 bgwriter_maxpages 设置为零。

PostgreSQL手册之资源消耗相关推荐

oracle高资源消耗sql,oracle 中如何定位重要(消耗资源多)的SQL
在分析SQL性能的时候,经常需要确定资源消耗多的SQL,总结如下: 1查看值得怀疑的SQL selectsubstr(to_char(s.pct,'99.00'),2)||'%'load, s.exe ...
oracle高资源消耗sql,Oracle中定位重要(消耗资源多)的SQL
在分析SQL性能的时候,经常需要确定资源消耗多的SQL,总结如下: 1 查看值得怀疑的SQLselect substr(to_char(s.pct, 在分析SQL性能的时候,经常需要确定资源消耗多的S ...
oracle高资源消耗sql,Oracle高资源消耗SQL语句定位
Oracle SQL语句资源消耗监控最常用的系统视图有v$sql.v$sqlarea.v$sqltext和v$session.本文我们先了解这些视图的作用与区别,然后了解如何定位高资源消耗SQL语句, ...
案例分析：倾斜值传入导致 SQL 资源消耗升高
作者 | 邓秋爽:云和恩墨技术工程师,有超过七年超大型数据库专业服务经验,擅长 Oracle 数据库优化.SQL 优化和 Troubleshooting. 局方监控系统反馈 2014-12-31 19 ...
datagrid嵌套和资源消耗
datagrid嵌套的文章很多了. 我这里参考的是以下两篇 http://www.cnblogs.com/lovecherry/archive/2005/04/26/145633.html http: ...
oracle view使用次數,oracle sql资源消耗相关视图
一.常用视图说明 Oracle sql语句资源消耗监控,最常用的系统视图有: v$sql v$sqlarea v$sqltext v$session v$sql和v$sqlarea基本相同,记录了共享 ...
使用JavaCV实现海康rtsp转rtmp实现无插件web端直播（无需转码，低资源消耗）
使用JavaCV实现海康rtsp转rtmp实现无插件web端直播(无需转码,低资源消耗) 目录结构添加依赖,编写配置文件创建Bean 创建缓存Cache 修改启动类拉流.推流.转封装定时任务T ...
Oracle一条资源消耗较高但是Executions=0的问题排查...
日常巡检某客户生产环境数据库时,发现AWR报告中有资源消耗较高但是Executions=0的现象: 这个现象可以解释为在这一个小时的快照周期内SQL一次都没执行完成. (一) 对第一条 SQLID=1 ...
GPU 资源消耗原因和解决方案：
GPU 资源消耗原因和解决方案: GPU能干的事情比较单一:接收提交的纹理Texture

PostgreSQL手册之资源消耗

PostgreSQL手册之资源消耗相关推荐

最新文章

热门文章