max_connections (integer)
决定和数据库连接的并发连接数目的最大值。 缺省通常是 100,但是如果你的内核设置不支持这么大(在 initdb 的时候判断), 可能会比这个数少。这个参数只能在服务器启动的时候设置。
增大这个参数可能导致 Postgresql 要求更多的 System V 共享内存或者信号灯, 可能超过你的操作系统缺省配置的许可值。必要的话,参阅 Section 16.4.1 获取有关如何调节这个参数的信息。
max_prepared_transactions (integer)
设置可以同时处于"准备好"状态的事务的最大数目(参阅 PREPARE TRANSACTION)。 把这个参数设置为零则关闭准备好的事务的特性。缺省是 5。 这个选项只能在服务器启动的时候设置。
如果你不使用准备好事务,这个参数也可以设置为零。 如果你使用它们,你可能会需要把 max_prepared_transactions 设置成至少和 max_connections 一样大, 以避免在准备步骤的失败。
增加这个参数可能会导致 Postgresql 要求比缺省的操作系统配置的更多的 System V 共享内存。必要时请参阅 Section 16.4.1 获取有关如何调节这个参数的信息。
shared_buffers (integer)
设置数据库服务器将使用的共享内存缓冲区数量。缺省通常是 1000, 如果你的内核设置不支持这么大,那么可以少些(在 initdb 的时候决定)。 每个缓冲区大小的典型值是 8192 字节,除非你在编译的时候修改了 BLCKSZ 的值。这个数值必须大于 16, 并且至少是 max_connections 数值的两倍;不过,这个数值大一些通常可以改进性能。 对于生产安装,我们通常建议是几千。 这个选项只能在服务器启动的时候设置。
增大这个参数可能导致 Postgresql 要求更多 System V 的共享内存, 超出你的操作系统配置许可的范围。必要时请参阅 Section 16.4.1 获取如何调整这些参数的信息。
wal_buffers (integer)
放在共享内存里用于 WAL 数据的磁盘页面缓冲区的数目。 这个设置只需要大到能保存下一次事务生成的 WAL 数据即可, 因为这些数据在每次事务提交都会写入磁盘。 这个选项只能在服务器启动的时候设置。
增大这个参数可能导致 Postgresql 要求更多的 System V 共享内存,可能超过你的操作系统的缺省配置。必要时,参阅 Section 16.4.1 获取如何调节这些参数的信息。
max_fsm_relations (integer)
设置自由空间将在共享地自由空间映射里跟踪的最大数目的关系(表和索引)。 每个槽位大概要使用五十字节左右。缺省是 1000。 这个选项只能在服务器启动的时候设置。
max_fsm_pages (integer)
设置在共享的自由空间映射表里自由空间会跟踪的最大数目的磁盘页面数。 每个页面槽位需要消耗六个字节的共享内存。这个设置必须大于 16 * max_fsm_relations。 缺省是 20000。 这个选项只能在服务器启动的时候设置。
我来做一点补充
一、Postgresql基本参数优化:
Postgresql的配置文件是数据库目录(/opt/PostgresPlus/8.3/data)下的 postgresql.conf文件, 8.0以后的版本可支持K,M,G这样的参数,只要修改相应 参数后重新启动Postgresql服务就OK了。
shared_buffers:这是最重要的参数,postgresql通过shared_buffers和内核 和磁盘打交道,因此应该尽量大,让更多的数据缓存在shared_buffers中。通常设 置为实际RAM的10%是合理的,比如50000(400M)
work_mem: EnterpriseDB在执行排序操作时,会根据work_mem的大小决定是 否将一个大的结果集拆分为几个小的和 work_mem查不多大小的临时文件。显然拆 分的结果是降低了排序的速度。因此增加work_mem有助于提高排序的速度。通常设 置为实际RAM的2% -4%,根据需要排序结果集的大小而定,比如81920(80M)
effective_cache_size:是Postgresql能够使用的最大缓存,这个数字对 于独立的Postgresql服务器而言应该足够大,比如4G的内存,可以设置为3.5G (437500)
maintence_work_mem:这里定义的内存只是在CREATE INDEX,VACUUM等时用 到,因此用到的频率不高,但是往往这些指令消耗比较多的资源,因此应该尽快让 这些指令快速执行完毕:给 maintence_work_mem大的内存,比如512M(52428 max_connections: 通常,max_connections的目的是防止max_connections * work_mem超出了实际内存大小。比如,如果将work_mem设置为实际内存的2%大小, 则在极端情况下,如果有50个查询都有排序要求,而且都使用2%的内存,则会导 致swap的产生,系统性能就会大大降低。当然,如果有4G的内存,同时出现50个如 此大的查询的几率应该是很小的。不过,要清楚 max_connections和work_mem的关系。 二、EnterpriseDB Postgres Plus Advanced Server优化 在EnterpriseDB上有DynaTune的功能可以实现系统自动的优化,EDB提供了系统优化的最简易步骤: 修改/opt/PostgresPlus/8.3/data/postgresql.conf 将edb_dynatune设为100:让系统自动设置,本服务器为数据库专用服务器,尽可能使用系统资源,并对当前数据库的常用操作进行分析优化 将edb_dynatune_profile设为oltp:让系统自动设置,本服务器用于处理OLTP高并发事务处理,以此标准进行优化 设置这两项后重启edb_8.3服务 三、数据库系统启动后可以通过以下方式查询当前系统参数的设置情况: edb# select * from pg_settings; 特别是在EnterpriseDB使用了DynaTune功能后,可以通过以上查询查看系统自动进行调整后的参数值 四、增加最大连接数到2000以上 Linux操作系统中默认的SEMMNI一般只能支持2000个左右的连接,这个值应该设为 max_connections*16,但实际上各不同的系统中有似乎有一点偏差,如: SEMMNI=128时,公式算出的最大连接数(max_connections)为2048,在RHEL5中最大 只能用到2030 RHEL5中修改SEMMNI方法: 在文件/etc/sysctl.conf中加入一行 kernel.sem=250 32000 32 128 当中最后一个“128”为当前的SEMMNI 执行 sysctl -p使操作系统当前的sysctl设置生效