postgres 20079 1 0 Jul07 ? 00:00:41 /usr/pgsql-9.2/bin/postmaster -p 60904 -D /u01/app/postgres/data/monicrm
postgres 20081 20079 0 Jul07 ? 00:00:00 postgres: logger process
postgres 20083 20079 0 Jul07 ? 00:00:02 postgres: checkpointer process
postgres 20084 20079 0 Jul07 ? 00:00:10 postgres: writer process
postgres 20085 20079 0 Jul07 ? 00:00:10 postgres: wal writer process
postgres 20086 20079 0 Jul07 ? 00:00:45 postgres: autovacuum launcher process
postgres 20087 20079 0 Jul07 ? 00:01:06 postgres: stats collector process
pg_xlog/ 子目录里维护着一套预写日志(WAL)。 这些日志记录着每一次对数据库的修改细节。 这些日志存在是为了防止崩溃： 如果系统崩溃，数据库可以通过"重放"上次检查点以来的日志记录以恢复数据库的完整性。组合文件系统备份与WAL文件的备份。如果需要恢复，我们就恢复备份， 然后重放备份了的WAL文件，把备份恢复到当前的时间。
pg_clog子目录将会占用更多空间， 因为它必须为所有autovacuum_freeze_max_age之后的事务存储提交状态。 每个事务提交状态使用2字节，因此如果autovacuum_freeze_max_age 设置为最大允许值为20亿，pg_clog将会增加到大约500M。 如果这个尺寸比起你的数据库来只是小菜一碟，我们推荐你将 autovacuum_freeze_max_age设为允许的最大值。否则， 如何设置将取决于你愿意给pg_clog多大的空间。默认值是2亿， 大约需要50MB的pg_clog存储空间。Max XID = 2亿，pg_clog=44M
pg_tblspc=108Gb
pgBadger 是一个外部项目，做复杂的日志文件分析
SHOW将显示当前运行时参数的数值。这些变量可以通过 SET语句、编辑postgresql.conf文件、 PGOPTIONS环境变量(在使用基于libpq的应用程序的时候)、 启动postgres服务器的命令行参数来设置。
SHOW ALL;
name | setting | description
-------------------------+---------+-------------------------------------------------
allow_system_table_mods | off | Allows modifications of the structure of ...
.
.
.
xmloption | content | Sets whether XML data in implicit parsing ...
zero_damaged_pages | off | Continues processing past damaged page headers.
(196 rows)
data_directory (string) 声明为数据存储使用的目录。这个选项只能在服务器启动的时候设置。 config_file (string） 声明主服务器配置文件(通常叫postgresql.conf)。这个选项只能在postgres命令行上设置。 hba_file (string)声明基于主机的认证(HBA)配置文件(通常叫pg_hba.conf)。这个选项只能在服务器启动的时候设置。 ident_file (string)声明用于第 19.2 节用户名匹配的配置文件(通常叫pg_ident.conf)。 这个选项只能在服务器启动的时候设置。 external_pid_file (string)声明可被服务器管理程序使用的额外PID文件。这个选项只能在服务器启动的时候设置。 shared_buffers (integer)
设置数据库服务器将使用的共享内存缓冲区数量。缺省通常是128兆字节(128MB)， 但是如果你的内核设置不支持这么大，那么可以少些(在initdb的时候决定)。 每个缓冲区大小的典型值是128千字节，（BLCKSZ的非缺省值改变最小值） 不过，这个数值比最小值大一些通常需要更好的性能。 这个选项只能在服务器启动的时候设置。
如果你有1GB或更多内存的专用数据库服务器， 对于shared_buffers合理的初始值是您的系统内存的25%。 有一些工作负载，甚至在那里对于shared_buffers大设置是有效的， 但因为PostgreSQL也依赖于操作系统缓存， 它是不可能的，RAM到shared_buffers的多于40%的分配比更少数量的工作的更好。 对于shared_buffers的大量设置 通常要求相应增加checkpoint_segments， 为了延长写大量新的或者需较长时间修改的数据的进程。
eg. shared_buffers = 4096M , checkpoint_segments = 32 (default 16)
声明内部排序操作和Hash表在开始使用临时磁盘文件之前使用的内存数目。 缺省数值是1兆字节(1MB)。请注意对于复杂的查询， 可能会同时并发运行好几个排序或者散列操作；每个都会被批准使用这个参数声明的这么多内存， 然后才会开始求助于临时文件。同样，好几个正在运行的会话可能会同时进行排序操作。 因此使用的总内存可能是work_mem的好几倍。 当选择这个值的时候，必须记住这个事实。 ORDER BY, DISTINCT和融合连接都要用到排序操作。 Hash表在散列连接、散列为基础的聚合、散列为基础的IN子查询处理中都要用到。eg. work_mem = 8 MB
maintenance_work_mem (integer)声明在维护性操作(比如VACUUM, CREATE INDEX和ALTER TABLE ADD FOREIGN KEY)中使用的最大的内存数。 缺省是16兆字节(16MB)。因为在一个数据库会话里， 任意时刻只有一个这样的操作可以执行，并且一个数据库安装通常不会有太多这样的工作并发执行， 把这个数值设置得比work_mem更大是安全的。 更大的设置可以改进清理和恢复数据库转储的速度。请注意，当运行自动清理， 直至autovacuum_max_workers次分配这个内存， 所以要小心，不要设置默认值太高。eg. maintenance_work_mem = 16 MB
可靠性和预写式日志
可靠性操作的一个方面是所有已提交的数据都应该存储在一个非易失的区域，这样就不会因为电力失效、 操作系统崩溃、硬件失效(除了非易失区域自身失效之外)等原因导致数据丢失。向计算机的永久存储设备 (磁盘驱动器或其他等效的设备)成功写入数据通常可以满足这个要求。实际上，即使计算机完全失效， 只要磁盘驱动器幸免于难，那么就可以将它们移动到另外一台硬件兼容的计算机上， 而所有已经提交的事务将保持原状。首先，有操作系统的缓冲区内存，它缓冲常用的磁盘块并将磁盘的写入请求进行合并。
然后，在磁盘驱动器的控制器上可能还有一个缓冲；尤其在RAID控制卡上更为常见。 这些缓冲区中，有些是透过式写入，意思是写入动作在到达的同时写入到磁盘上。 其它则是回写式写入，意思是数据将在稍后写入驱动器，这样的缓冲区会降低可靠性， 因为磁盘控制器上的内存是易失的，在发生电力失效的情况下会丢失其中的内容。 好一些的控制器卡备有电池备份单元(BBUs)， 可以在系统电力失效的情况下提供电力，在电力恢复之后，这些数据将会被写入磁盘驱动器。最后，大多数磁盘驱动器自身也有缓冲区。有些是透过式的，有些是回写式的。 和磁盘控制器一样，回写式的磁盘缓冲区也存在数据丢失的问题。 消费级别的 IDE 和 SATA 驱动器一般都有回写式缓冲，在掉电的情况下很容易丢失数据。 很多固态磁盘(SSD)也有易失的回写式缓冲。
预写式日志(WAL)是一种确保数据完整性的标准方法。 WAL的中心思想是对数据文件的修改(它们是表和索引的载体) 必须只能发生在这些修改已经记录到日志之后，也就是说， 在描述这些变化的日志记录刷写到永久存储器之后。如果我们遵循这个过程， 那么就不需要在每次事务提交的时候都把数据页刷写到磁盘， 因为在出现崩溃的情况下可以用日志来恢复数据库： 任何尚未应用于数据页的修改都可以先从日志记录中重做(这叫向前滚动恢复，也叫 REDO)。
使用WAL显著地减少了磁盘写的次数，因为只有日志文件需要刷写到磁盘以保证事务被提交， 而不是事务修改的所有数据文件都需要刷写到磁盘。日志文件是顺序写的，所以同步日志的开销要远比刷写数据页的开销小。 尤其对于有很多修改不同数据存储位置的小事务的服务而言更是如此。另外，当服务器正在处理许多小的并发事务时， 日志文件的一个fsync足以提交许多事务。
wal_level (enum) 最小的WAL不包含从基本的备份和WAL日志中重建数据的足够信息， 所以archive或者hot_standby级别必须用来启动 WAL归档(archive_mode)和流复制。
在hot_standby级别，相同的信息被记录为archive， 加上需要重建从WAL运行的事务状态信息。 为了在备用服务器上启用只读查询，主库上wal_level必须设置为hot_standby， 必须启动备库上的hot_standby。 使用hot_standby和archive级别之间的性能几乎没有可测量的差异 ，如果任何生产的影响是明显的，则是值得欢迎的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/26477398/viewspace-2122668/ ，如需转载，请注明出处，否则将追究法律责任。
