2 运行架构
以为编译安装为模板讲解各个文件功能作用，切换为postgres用户
| 目录 | 位置 |
|---|---|
| 数据库数据目录 | /pgdata/10/data |
| 安装包目录 | /opt/pg10/ |
2.1 安装包目录详解
-bash-4.2$ pwd
/opt/pg10
-bash-4.2$ tree -L 1 .
.
├── bin #应用程序
├── include #c/c++的头文件
├── lib #编译链接
└── share #文档示例和拓展4 directories, 0 files
| 应用名称 | 应用功能 |
|---|---|
| clusterdb | 更多操作应用功能应用功能对一个PostgreSQL数据库中的表进行重新聚簇 |
| createdb | 创建数据库命令 |
| createuser | 创建一个postgresql的用户 |
| dropdb | 删除数据库 |
| dropuser | 删除用户 |
| ecpg | 嵌入式 SQL C 预处理器，将把命令行中给出的每一个输入文件转换为相应的 C 输出文件 |
| initdb | 创建一个新的数据库集群 |
| pg_archivecleanup | 清理过期的 archive log 使用的命令 |
| pg_basebackup | 对集群进行备份的基础命令 |
| pgbench | 压测工具 |
| pg_config | 打印当前安装版本的PostgreSQL的配置参数，便于想与PostgreSQL交互的软件包能够找到所需的头文件和库。 |
| pg_controldata | 显示一个PostgreSQL数据库集簇的控制信息 |
| pg_ctl | 初始化、启动、停止或控制一个PostgreSQL服务器 |
| pg_dump | 备份数据库数据 |
| pg_dumpall | 备份数据库，还有角色表空间 |
| pg_isready | 检查一个PostgreSQL数据库服务器的连接状态的工具 |
| pg_receivewal | 被用来从一个运行着的PostgreSQL集簇以流的方式得到预写日志 |
| pg_recvlogical | 逻辑解码的插件，可用于脑裂时找回数据 |
| pg_resetwal | 用于清理不需要的WAL文件，还可以用于篡改当前事务ID，可以恢复未被vacuum回收的元组 |
| pg_restore | 用于恢复由 pg_dump 创建的任何非纯文本输出格式中的 PostgreSQL 数据库的应用 |
| pg_rewind | pg_rewind可以做实例间的同步 |
| pg_test_fsync | 测试 wal_sync_method设置哪个值最快，还可以在发生认定的 I/O 问题时提供诊断信息。 |
| pg_test_timing | 测量系统计时开销的工具，并确认系统时间永不倒退。 |
| pg_upgrade | 用作大版本升级 |
| pg_waldump | WAL日志解析工具 |
| postgres | 可以启动数据库命令 |
| postmaster | 守护进程 |
| psql | 执行命令 |
| reindexdb | 用于重建一个PostgreSQL数据库中索引的工具。 |
| vacuumdb | 对一个PostgreSQL数据库进行垃圾收集和分析 |
2.2数据库数据目录详解
-bash-4.2$ pwd
/pgdata/10/data
-bash-4.2$ tree -L 1 .
.
├── base
├── global
├── pg_commit_ts
├── pg_dynshmem
├── pg_hba.conf
├── pg_ident.conf
├── pg_logical
├── pg_multixact
├── pg_notify
├── pg_replslot
├── pg_serial
├── pg_snapshots
├── pg_stat
├── pg_stat_tmp
├── pg_subtrans
├── pg_tblspc
├── pg_twophase
├── PG_VERSION
├── pg_wal
├── pg_xact
├── postgresql.auto.conf
├── postgresql.conf
├── postmaster.opts
└── postmaster.pid17 directories, 7 files
| 数据库数据目录 | 对应功能 |
|---|---|
| base | 每个数据库对应的子目录的存储 |
| global | 包含pg_database及pg_control等公共文件视图 |
| pg_commit_ts | 事物提交时间戳数据 |
| pg_dynshmem | 动态共享内存子系统中使用的文件 |
| pg_hba.conf | 客户端认证 |
| pg_ident.conf | 用户名映射 |
| pg_logical | 用户名映射 |
| pg_multixact | 多事物状态数据 |
| pg_notify | LISTEN/NOTIFY状态数据 |
| pg_replslot | 复制槽数据 |
| pg_serial | 已提交的可串行化事物相关信息 |
| pg_snapshots | pg_export_snapshot在此子目录中创建的快照信息文件 |
| pg_stat | 统计子系统的永久文件 |
| pg_stat_tmp | 统计子系统的临时文件 |
| pg_subtrans | 子事物状态数据 |
| pg_tblspc | 表空间的软连接 |
| pg_twophase | 两阶段事物的状态文件 |
| PG_VERSION | 版本信息 |
| pg_wal | 事务日志文件预写日志 |
| pg_xact | 事物提交状态数据 |
| postgresql.auto.conf | alter system修改的配置参数 |
| postgresql.conf | 参数配置文件 |
| postmaster.opts | 上次启动的命令行选项 |
| postmaster.pid | 守护进程 |
2.2 进程与内存架构
逻辑结构和物理存储结构
内存结构
本地内存：pg后台进程使用的内存
共享内存：由pg服务器所有进程使用
pg后端进程：由pg服务器启动，通过单个TCP和数据库连接，多个客户端连接时，设置max_connections可以控制客户端连接数量。
如果业务存在频繁的和数据库连接断开操作，会对性能有影响,最好接入连接池如pgbouncer或pgpllo-II
进程和相关参数
max_connections 活跃的并发连接数,最大连接数。
superuser_reserved_connections 为管理员保留的连接数。
checkpointer process
检查点进程，主要是缩短数据库实例恢复的时间。重要：在重启数据库之前,可以执行这个命令，加快后续数据库的恢复
检查点进程的职责：
数据刷新：检查点进程负责将数据库缓存中的数据块刷新到磁盘上。这是通过创建检查点来完成的，检查点是数据库状态的一个快照，包括了所有修改的数据块。
写前日志（WAL）管理：PostgreSQL使用WAL来记录所有修改，以便在系统崩溃后恢复数据。检查点进程会定期刷新WAL，减少恢复时间。
减少恢复时间：通过定期进行检查点，可以减少数据库启动时的恢复时间，因为需要恢复的数据量会减少。
释放WAL文件：随着WAL的刷新，旧的WAL文件可以被释放，避免无限制地占用磁盘空间。
配置检查点：检查点进程的行为可以通过参数进行配置，如checkpoint_timeout（检查点间隔时间）和max_wal_size（WAL文件的最大大小）。检查点的类型：
定期检查点：根据checkpoint_timeout参数设置的时间间隔自动触发。
请求检查点：由数据库管理员手动触发，或者在达到max_wal_size限制时自动触发。
检查点的执行过程：
检查点开始：检查点进程被触发，开始将内存中的数据刷新到磁盘。
刷新共享缓冲区：共享缓冲区中的数据块被写入到磁盘。
更新控制文件：更新控制文件以记录检查点的完成，包括WAL的位置和时间戳。
清理WAL：不再需要的WAL文件被清理，释放磁盘空间。
数据库默认配置
[root@localhost data]# cat postgresql.conf |grep checkpoint_timeout
#checkpoint_timeout = 5min # range 30s-1d
[root@localhost data]# cat postgresql.conf |grep max_wal_size
#max_wal_size = 1GB
优化该参数建议
调整checkpoint_timeout参数：这个参数决定了触发检查点的时间间隔。对于大多数生产系统，可以使用30分钟到1小时之间的值，例如设置为checkpoint_timeout = 30min。
设置max_wal_size参数：这个参数定义了WAL日志文件的最大大小。它应该设置得足够高，以便检查点主要由checkpoint_timeout参数触发，而不是因为WAL日志量达到上限。例如，可以设置为max_wal_size = 4GB。
调整min_wal_size参数：这个参数定义了WAL日志文件的最小大小，通常可以设置为max_wal_size的一半，例如min_wal_size = 1GB。
设置checkpoint_completion_target参数：这个参数用于控制检查点的完成目标，其值在0到1之间。较高的值（例如0.9）意味着数据库会在更短的时间内完成检查点的写操作，留给操作系统更多的时间来刷新脏页到磁盘。
监控和评估：建议设置log_checkpoints=on，这样可以在服务器日志中记录检查点的统计信息，帮助评估和修正上述参数。
操作系统层面的调整：在Linux系统上，还需要考虑内核参数的设置，以避免因为大量脏页同时刷新到磁盘导致的IO风暴问题。例如，可以调整vm.dirty_ratio和vm.dirty_background_ratio等参数来控制脏页的刷新行为。
根据磁盘性能调整参数：如果评估发现磁盘的写能力无法满足检查点期间的IO需求，可能需要增加checkpoint_timeout的值，或者减少shared_buffers和max_wal_size的大小，以降低检查点的频率和每次检查点的IO压力。
考虑业务特点：不同的业务特点可能对检查点参数的设置有不同的要求。例如，写入密集型的业务可能需要更频繁的检查点，而读取密集型的业务则可能更注重减少检查点对性能的影响。
wal writer process
WAL记录了数据库的所有更改，使得在系统崩溃后可以从日志中恢复数据。WAL Writer进程（通常称为bgwriter，即后台写入器）是负责将这些事务日志写入磁盘的后台进程。
先写日志后写库，如果崩溃了，可以通过该日志恢复数据，减小了磁盘读写次数，为啥？因为日志提交的时候只需要文件刷新磁盘，不是修改所涉及到的数据文件。将就随机IO，变为顺序IO
相关参数配置
bgwriter_delay：控制WAL Writer进程写入WAL日志的时间间隔，单位为毫秒。较小的值可以减少WAL日志的延迟，但可能会增加CPU的使用率。
bgwriter_lru_maxpages：每次WAL Writer运行时，从最近最少使用的（LRU）列表中刷新到磁盘的最大页面数。
bgwriter_lru_multiplier：这个参数决定了WAL Writer进程刷新脏页的速率，相对于检查点进程的刷新速率。
checkpoint_completion_target：这个参数影响WAL Writer在检查点期间的行为，决定了检查点完成前应该完成多少写操作的比例。
优化参数建议
调整bgwriter_delay参数：这个参数控制WAL Writer进程休眠的时间，减少这个值可以使WAL Writer更频繁地运行，更快地将脏页刷新到磁盘，从而减少数据库缓冲区的负担。但是，设置得过小可能会增加CPU的使用率。根据测试，调整bgwriter_delay和其他相关参数后，性能测试的分数并没有提高，反而有所降低，说明需要根据实际情况进行细致调整 。
优化bgwriter_lru_maxpages和bgwriter_lru_multiplier参数：这两个参数影响WAL Writer进程每次运行时刷新的脏页数量。bgwriter_lru_maxpages设置每次WAL Writer运行可以刷新的最大页面数，而bgwriter_lru_multiplier则是根据系统新申请的缓冲页数来计算需要刷新的页面数的一个乘数。应该将maxpages和multiplier调整到允许的最大值，并减小delay到最小，以提高WAL Writer的效率 。
合理配置checkpoint_timeout和checkpoint_completion_target参数：checkpoint_timeout参数决定了触发检查点的时间间隔，而checkpoint_completion_target参数则用于平滑调度检查点的完成。根据磁盘性能和业务需求，适当增加checkpoint_timeout的值，并调整checkpoint_completion_target以优化检查点的频率和性能 。
监控和使用pg_stat_bgwriter视图：通过pg_stat_bgwriter视图可以了解WAL Writer的工作状态，如buffers_clean、buffers_backend和maxwritten_clean等字段，这些统计信息有助于评估WAL Writer的效率并进行相应的调整 。使用effective_cache_size参数：此参数提供给优化器一个内存大小的估计值，影响其选择扫描方式的决策。适当增加此值可以减少顺序扫描，提高索引扫描的可能性 。
调整shared_buffers参数：增加此参数的值可以增加数据库缓存的数据量，减少对物理存储的访问次数，从而提高性能 。
异步提交：通过设置synchronous_commit参数为off，可以使事务提交变得更快，但需要注意这可能会以牺牲数据一致性为代价 。
压缩WAL日志：使用wal_compression参数可以在存储WAL日志时节省空间，并减少I/O操作 。
autovacuum launcher process /workers
有时候数据库统计信息不准确，就可能和该参数有关。
Autovacuum Launcher Process
启动和监督：autovacuum launcher负责启动autovacuum worker进程，并监督它们的运行状态。调度任务：根据数据库的负载和配置参数，launcher会决定何时启动workers来执行维护任务，如自动清理（vacuuming）和重构索引（index rebuilding）。资源管理：launcher还负责管理autovacuum使用的系统资源，确保不会消耗过多的CPU或内存。配置参数：autovacuum的行为可以通过多个参数配置，如autovacuum_max_workers（最大工作进程数）、autovacuum_vacuum_threshold（触发清理的行数阈值）等。
Autovacuum Workers
执行任务：每个autovacuum worker进程都会执行具体的清理任务，如对表执行VACUUM或对索引执行REINDEX。
并发操作：多个workers可以并发运行，以提高维护效率。
智能调度：workers会根据当前数据库的负载情况智能地安排任务，避免在高负载时段执行影响性能的维护操作。
日志记录：workers在执行任务时会记录详细的日志信息，便于数据库管理员进行监控和故障排查
优化Autovacuum
监控pg_stat_activity：通过这个系统视图，可以查看当前运行的autovacuum进程和它们的状态。
调整配置参数：根据数据库的工作负载和性能需求，适当调整autovacuum相关的配置参数
分析日志文件：定期检查PostgreSQL的日志文件，了解autovacuum的工作情况和可能的瓶颈。
使用pg_autovacuum视图：这个视图提供了关于autovacuum触发和运行的统计信息，有助于分析和调整autovacuum的配置。
避免在高峰时段运行：如果可能，配置autovacuum避免在业务高峰时段执行，以减少对性能的影响。
定期手动执行维护任务：在某些情况下，根据业务特点，可能需要手动执行VACUUM或REINDEX，以补充自动维护。
