U盘物理触发嵌入式设备老化测试模式
2026/10/14 18:54:55
开头
PostgreSQL 12.0这个版本虽然已经不算最新，但我一直认为它是近年里“最值得部署的版本”之一——性能优化覆盖面广、分区表体验大幅改善、日志和监控机制也更成熟。到现在，我身边还有不少生产环境跑在12.x上，稳定得让人懒得升级。这篇博文就围绕Linux下的PostgreSQL 12.0安装部署展开，从编译安装到基础配置，再到日常启动管理和问题排查，把整个流程掰开揉碎讲清楚。
这篇文章适合谁？一是刚接触PostgreSQL、想在Linux上从零搭一套库的新手；二是被各种依赖、权限、配置坑过、想搞明白“为什么这样改”的运维同学；三是需要写部署文档、把安装过程脚本化的开发。我会把每一步的操作意图和底层逻辑都讲出来，而不是给你一段冷冰冰的命令序列——因为只复制命令而不理解原理，换一台机器、换一个环境，你照样会卡住。
先说结论：在Linux下部署PostgreSQL 12.0，核心就三件事——选对安装方式、配好初始化参数、管好启动和认证。把这三件事吃透了，剩下的都是细节问题。
1. 安装前的准备工作与方案取舍
1.1 环境清点：先看系统，再谈安装
很多人上来就敲安装命令，结果装到一半发现缺编译工具，或者系统架构对不上，折腾半天还得推翻重来。我习惯先花两分钟把环境摸清楚，省下的时间远比这两分钟多。
需要确认的信息至少有这几项：
- 操作系统发行版和版本：不同发行版的包管理器和依赖库名称差异很大，CentOS用yum、Debian/Ubuntu用apt，哪怕都叫“Linux”，后面的坑也不一样。
- 系统架构：x86_64还是ARM，这决定了下载的源码包或二进制包版本。PostgreSQL官方对主流架构支持都很好，但你提前确认一下能少走弯路。
- 当前是否已有PostgreSQL残留：用
rpm -qa | grep postgres或dpkg -l | grep postgres扫一遍，有残留的话先清理，避免端口、数据目录、服务配置冲突。 - 是否有足够磁盘空间：源码编译安装需要大约300MB临时空间，数据目录解压后空库大概几十MB，但要考虑后续业务增长。
df -h看一眼，至少留出几十GB才踏实（当然具体看业务量）。
我遇到过一次比较典型的情况：在一台存量服务器上装PostgreSQL，psql命令能执行，但版本是9.x，而且旧数据目录还占着默认端口5432。新装的12.0一直启动失败，查了半天发现是旧服务占用端口。所以检查这一步千万别省，特别是存量环境。
1.2 安装方式二选一：源码编译还是包管理器
PostgreSQL在Linux下的安装方式主要有三种，我把它们的优缺点列成了一张表，方便你做决策：
| 安装方式 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| 发行版包管理器（yum/apt） | 安装快、依赖自动处理、和系统集成好 | 版本通常滞后，不一定有12.0；配置路径跟随系统约定 | 测试环境、对版本不敏感的场景 |
| 官方二进制仓库（PGDG） | 版本新且由官方维护、与系统软件兼容性好 | 需要额外配置yum/apt源，有时源访问速度慢 | 生产环境推荐，兼顾效率和可控性 |
| 源码编译安装 | 版本完全可控、可定制编译选项、路径自定义 | 耗时长、依赖要自己解决、升级要重新编译 | 定制化需求强、需要特定版本的学习/研究环境 |
接下来的博文核心以“源码编译安装”为主线，因为这是最能看清PostgreSQL内部结构、也最容易出细节问题的方式。源码编译看着麻烦，但只要你把每个参数的含义搞懂，它反而是一种“心里最踏实”的安装方法——所有东西放在哪、用什么参数启动的，你全都知道，出了问题也最容易定位。
提示：如果你只是想快速搭一个环境跑业务，直接用包管理器安装，再配合
initdb初始化即可，不一定要编译源码。
2. 编译安装PostgreSQL 12.0全流程
2.1 依赖库先行：少了它们后面全是坑
源码编译安装的第一步不是下载源码，而是确认编译工具和依赖库。PostgreSQL 12.0编译最基础的依赖有这些：
gcc、make：编译器和构建工具，没有它们后面寸步难行。readline-devel：提供命令行历史记录和编辑功能。没有它，psql交互体验会非常差，而且configure阶段会直接报错退出。zlib-devel：压缩库，数据备份、归档等功能会用到。
在CentOS/RHEL系统上，一条命令装齐：
yum install -y gcc make readline-devel zlib-develDebian/Ubuntu系统则是：
apt-get install -y build-essential libreadline-dev zlib1g-dev如果你后续要用PostgreSQL的SSL功能，还需要openssl-devel；要用Python写PL/Python，需要python3-devel。这里我建议“按需安装”而不是“全装”——装得越多，configure阶段的检查项越多，反而更容易因为某个库缺失而失败。基础的三个库先装好，后面需要什么再补。
为什么PostgreSQL这么依赖readline？因为psql是一个交互式命令行工具，需要支持光标移动、历史命令回退等编辑功能，readline恰好提供了这套能力。没有readline，虽然也能编译成功（configure检测不到readline会自动禁用该功能），但psql用起来就像回到几十年前的终端，体验极差。
2.2 解压、配置、编译、安装的四个关键阶段
源码安装的流程可以概括为四步：解压、configure、make、make install。每一步都有它自己的作用和坑，我逐一说明。
首先，获取源码包。PostgreSQL官方下载页提供了12.0的源码包，文件名一般是postgresql-12.0.tar.gz。内网环境就把这个包提前下载好传到目标服务器。解压：
tar -zxvf postgresql-12.0.tar.gz cd postgresql-12.0接下来是configure，这是整个编译过程中最关键的一步。它负责检测系统环境、检查依赖库、并生成Makefile。我实际生产常用的配置命令是：
./configure --prefix=/opt/pgsql12 \ --with-pgport=5432 \ --with-openssl \ --enable-nls这里每个参数都有讲究：
--prefix=/opt/pgsql12：安装路径。我习惯把PostgreSQL装在独立的/opt/pgsql12目录下，而不是默认的/usr/local/pgsql。这样做的原因是：升级时整个目录可以直接替换，不会污染系统目录，卸载也方便——删掉这个目录就行。--with-pgport=5432：默认端口。虽然默认就是5432，但显式写出来能让生成的配置更明确，后人看Makefile和配置也少猜一步。--with-openssl：启用SSL支持，生产环境强烈建议打开。--enable-nls：启用国际化消息支持，即错误提示可以显示多语言。纯内网环境不开启也可以。
configure执行完毕后，看输出末尾有没有configure: error字样。如果出现错误，通常它会明确提示缺哪个库，按提示补装即可。
编译的命令是：
make -j4-j4表示并行编译，4是你的CPU核数。如果你机器是8核，-j8会更快；但不要盲目加大，曾经我的机器并发太大导致内存不足，编译进程被系统杀掉，白白浪费了时间。核数太大时，建议用-j$(nproc)动态获取核数，但也要留意内存占用。
编译完成后，用root权限执行安装：
make install安装完成后，检查/opt/pgsql12/bin目录，你会看到postgres、initdb、pg_ctl、psql等二进制文件都在这里了。到了这一步，编译安装的核心流程就算结束，真正的工作才刚刚开始。
2.3 一键脚本化：运维的偷懒艺术
如果是多台服务器都要部署，或者以后还要复盘重建环境，我强烈建议把整个编译安装过程写成一个Shell脚本。一来可以避免人手动敲命令敲错，二来在故障复盘时，拿着脚本就能追溯到当时到底装了哪些参数。
下面是一个我常用的部署脚本骨架：
#!/bin/bash # PostgreSQL 12.0 源码编译安装脚本 set -e PG_VERSION=12.0 PREFIX=/opt/pgsql12 SRC_DIR=/usr/local/src yum install -y gcc make readline-devel zlib-devel cd $SRC_DIR tar -zxvf postgresql-${PG_VERSION}.tar.gz cd postgresql-${PG_VERSION} ./configure --prefix=${PREFIX} --with-pgport=5432 --with-openssl make -j$(nproc) make install # 创建普通用户和文件权限 id postgres || useradd -m -s /bin/bash postgres mkdir -p /opt/pgsql12/data chown -R postgres:postgres /opt/pgsql12这里要特别强调set -e的作用：脚本中任意一条命令失败，整个脚本立即退出，不会带着错误继续往下执行。这能避免“编译失败但脚本继续走、最后安装一个残缺版本”的尴尬局面。
脚本里我还做了一件事——创建postgres用户。PostgreSQL官方强烈建议用非root用户运行数据库服务，这是出于安全考虑：即便数据库被攻破，攻击者也拿不到root权限。而且PostgreSQL本身也拒绝用root身份运行initdb和启动服务，所以创建一个专用用户是必须的。
3. 数据目录初始化与配置调优
3.1 initdb初始化：数据库实例的“成年礼”
编译装好二进制文件之后，数据库还不能直接使用，必须先用initdb命令在数据目录中创建一套完整的数据库实例文件。这就像你买了一台新电脑，还得装操作系统才能开机——数据目录里的base、global、pg_xact等子目录，就是PostgreSQL的“操作系统文件”。
初始化之前，先手动创建数据目录并授权。注意：一定要确保数据目录的所有者是postgres用户，否则后面启动会报权限错误。
mkdir -p /opt/pgsql12/data chown -R postgres:postgres /opt/pgsql12然后切换到postgres用户执行initdb。初始化命令是这样：
su - postgres /opt/pgsql12/bin/initdb -D /opt/pgsql12/data \ -U postgres \ --encoding=UTF8 \ --locale=en_US.UTF-8 \ --auth=scram-sha-256initdb的参数我一个个解释：
-D：指定数据目录，必须和启动时配置的目录一致，否则服务找不到数据。-U：指定超级用户的用户名，默认是postgres。这个超级用户相当于数据库的root，拥有所有权限。--encoding=UTF8：数据库默认字符集。强烈建议用UTF8，否则后面存中文、存emoji都可能出现乱码。--locale=en_US.UTF-8：区域设置，会影响排序规则、文本比较行为。这里有个易错点：如果系统本身没装en_US.UTF-8语言包，initdb会报错。可以用locale -a先检查系统支持的locale，没有就退而求其次用C或POSIX。开发测试环境用C反而省心，排序性能也高一些。--auth=scram-sha-256：设置默认的认证方式。这是PostgreSQL 10之后引入的强密码认证协议，比以前的md5安全得多。既然是新建库，直接上最安全的方案，别给自己留安全隐患。
初始化成功的标志是日志里出现“Success. You can now start the database server”这样的信息。如果看到这个，恭喜，数据库实例的基础骨架已经完成。
3.2 postgresql.conf关键参数：照着配就行
初始化完成后，数据目录下会生成三个核心配置文件：postgresql.conf（主配置）、pg_hba.conf（访问认证配置）、pg_ident.conf（用户名映射配置）。大部分情况下，你只需要动前两个。
postgresql.conf里的参数很多，但90%的场景只需要关注以下几类。先说监听与连接相关：
listen_addresses = '0.0.0.0' port = 5432 max_connections = 100listen_addresses决定数据库监听哪些网络接口。默认是localhost，只能本机访问。如果你要让其他机器连这个库，必须改为0.0.0.0（监听所有网卡）或指定具体IP。这个参数改完必须重启数据库才生效。
max_connections是最大并发连接数，默认100。这里要提醒一句：连接数不是拍脑袋定的，它受共享内存大小和每个连接的开销制约。PostgreSQL中每个连接大约占用几MB内存，如果你开1000个连接而机器只有8GB内存，数据库很可能内存不足直接崩溃。一般经验是：并发连接需求超过200时，前端加连接池（如PgBouncer），而不是无限调大max_connections。
再说内存相关参数，这是PostgreSQL性能调优的重头戏：
shared_buffers = 1GB effective_cache_size = 3GB work_mem = 4MBshared_buffers是数据库共享缓冲区大小，用于缓存数据页。官方建议设置为系统物理内存的25%左右。比如机器16GB内存，可以设4GB。注意不要超过这个比例——给共享缓冲区分配的内存会一直占用，不会自动释放，设太大反而挤占系统和其他进程的内存。
effective_cache_size不是PostgreSQL实际占用的内存，而是告诉查询规划器“系统层面有多少内存可以用来做文件缓存”。它不消耗真实内存，只是影响查询计划的优化策略。一般设置为总内存的50%~70%。
work_mem是单个查询用于排序、哈希操作的内存上限。这个参数需要小心：它虽然是“每个操作”的限制，但一个复杂查询可能有多个排序操作，并发时累加会相当可观。4MB是保守值，如果你有充足内存，可以调到8~16MB。我见过有人把work_mem设成512MB，结果十几个并发查询直接把内存打满，数据库直接OOM。改这个参数要小额多次地压测，不要一步到位。
最后说WAL和日志相关：
wal_level = replica max_wal_senders = 10 logging_collector = on log_directory = 'log' log_filename = 'postgresql-%a.log' log_statement = 'ddl'wal_level = replica是生产环境的底线配置，支持WAL归档和流复制的基本要求。max_wal_senders是流复制需要的发送进程数，单机不搞主从的话保持默认即可。
logging_collector = on表示把日志收集到文件里，不要只输出到终端。log_statement = 'ddl'表示只记录DDL语句（建表、删表等），不记录普通查询——这样既能追踪结构变更，又避免了海量查询日志把磁盘塞满。
修改配置文件前建议先备份原文件：
cp /opt/pgsql12/data/postgresql.conf /opt/pgsql12/data/postgresql.conf.bak这是个好习惯，改配置之前永远留一手，改出问题了还能快速回滚。
3.3 pg_hba.conf：数据库的“门禁系统”
pg_hba.conf（host-based authentication）是PostgreSQL的客户端访问认证配置文件，相当于数据库的“门禁系统”。初次配置时，最让人困惑的就是各种认证方式的异同。
常见的认证方式有三种：trust（完全信任）、md5（密码用MD5加密）、scram-sha-256（更安全的密码加密）。我在生产环境从不用trust，它意味着任何能连到端口的人都能免密登录，特别是面对公网环境时这等于裸奔。开发环境图方便可以用，但一定要清楚风险。
一个常用的生产配置模板长这样：
# 本地Unix套接字连接，使用scram认证 local all all scram-sha-256 # IPv4本地回环，允许本机密码登录 host all all 127.0.0.1/32 scram-sha-256 # 内网网段，允许应用服务器连接 host all all 192.168.1.0/24 scram-sha-256 # 禁止其他来源连接 host all all 0.0.0.0/0 reject注意pg_hba.conf的匹配规则是“自上而下，命中即止”。所以要放宽的规则放前面，要拒绝的放后面，顺序反了会导致策略不生效。最后一行reject相当于兜底拦截，保证除了明确允许的网段，其它来源一律拒绝。
改完pg_hba.conf后不需要重启数据库，只需要重新加载配置：
/opt/pgsql12/bin/pg_ctl reload -D /opt/pgsql12/datareload和restart的区别需要理解：reload只重新读取配置文件，不中断当前连接，适用于pg_hba.conf这类访问控制变更；restart会中断所有连接，适用于listen_addresses、shared_buffers这类只有启动时才能生效的参数变更。区分这两个操作是数据库运维的基本功，可以避免很多不必要的业务中断。
3.4 环境变量：每天都要用到的东西
安装完成后，把PostgreSQL的bin目录加入PATH，并把PGDATA环境变量配置好，能大幅提升日常操作效率。配置写在postgres用户的~/.bash_profile里：
echo 'export PATH=/opt/pgsql12/bin:$PATH' >> ~/.bash_profile echo 'export PGDATA=/opt/pgsql12/data' >> ~/.bash_profile source ~/.bash_profile设置PGDATA后，很多命令的精简写法就能用了——比如pg_ctl start后面不需要每次带-D参数，直接认环境变量里的数据目录。psql也会自动找到数据目录和后期设置的配置文件，少敲很多路径。
这里强调一个我自己踩过的坑：PATH里把/opt/pgsql12/bin放在$PATH前面，是为了确保psql、pg_ctl等命令优先使用新版本的二进制文件，而不是系统自带的旧版本。我曾经因为PATH顺序不对，敲psql用的还是老版本客户端，执行命令时和12.0服务端行为不一致，排查了半天才发现是PATH顺序问题。
4. 启动、停止与开机自启
4.1 手动起停的正确姿势：先看进程，再动手
数据库初始化完成后，第一件事就是启动服务验证。启动命令很简单：
su - postgres /opt/pgsql12/bin/pg_ctl start -D /opt/pgsql12/data -l /opt/pgsql12/data/logfile这里-l参数指定了日志输出文件，没有它启动日志会打到标准输出，一旦终端断开就看不到日志了。启动后建议立刻用一条命令验证状态：
/opt/pgsql12/bin/pg_ctl status -D /opt/pgsql12/data正常输出会包含pg_ctl: server is running (PID: xxxx)等信息。更可靠的验证方式是用psql连上去执行一条简单查询：
psql -U postgres -c "SELECT version();"能返回PostgreSQL 12.0版本信息，说明实例健康可用。如果连接时报错，优先级最高的排查点是看日志文件——PostgreSQL的日志会明确告诉你失败原因（比如端口被占用、数据目录权限不对、内存参数超出限制等），比对着错误码瞎猜有效得多。
停止数据库的优雅方式：
/opt/pgsql12/bin/pg_ctl stop -D /opt/pgsql12/data -m fast-m fast表示快速模式停止：回滚未完成的事务，断开所有连接，正常关闭。还有个-m immediate相当于强制断电，只在紧急情况下使用，因为它可能导致需要重放WAL日志恢复。我见过有人图省事直接用kill杀进程，这是最危险的——PostgreSQL进程被杀时可能来不及刷盘，重启后拖出损坏的数据页，恢复成本极高。除非数据库完全卡死，否则别用kill。
4.2 配置systemd服务：让数据库自动复活
手动启动没问题，但服务器重启后数据库不会自动恢复，每次手动起服务太被动。生产环境应该配置systemd服务，让PostgreSQL随系统自启。
在/etc/systemd/system/postgresql-12.service创建服务文件：
[Unit] Description=PostgreSQL 12.0 database server After=network.target [Service] Type=forking User=postgres Group=postgres ExecStart=/opt/pgsql12/bin/pg_ctl start -D /opt/pgsql12/data -l /opt/pgsql12/data/logfile ExecStop=/opt/pgsql12/bin/pg_ctl stop -D /opt/pgsql12/data -m fast ExecReload=/opt/pgsql12/bin/pg_ctl reload -D /opt/pgsql12/data PIDFile=/opt/pgsql12/data/postmaster.pid [Install] WantedBy=multi-user.target关键点在于Type=forking：因为pg_ctl start会fork出一个后台服务进程然后立即返回，systemd必须知道子进程的PID才能管理服务生命周期，所以PIDFile参数指向postmaster.pid文件——这个文件记录了PostgreSQL主进程的PID。
配置完成后执行：
systemctl daemon-reload systemctl enable postgresql-12 systemctl start postgresql-12 systemctl status postgresql-12enable会把服务加入到开机自启列表。status命令输出active (running)表示服务正常。以后重启服务器，PostgreSQL会自动跟随系统启动，不需要人工干预。
用systemd管理数据库还有一个额外好处：日志可以被systemd的journald统一管理，journalctl -u postgresql-12就能查看全部服务日志，排查问题方便很多。
4.3 日志管理：磁盘被日志撑爆是真实发生过的事
PostgreSQL开启logging_collector后，日志文件会持续增长。如果不做轮转清理，日志占满磁盘是早晚的事。这块如果不提前规划，等到磁盘满时数据库会进入只读模式，业务直接遭殃。
我的习惯是开启日志轮转，配置在postgresql.conf中：
log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 100MB含义是：日志每天轮转一次，或者单个文件超过100MB就轮转。log_truncate_on_rotation = on表示轮转时覆盖旧日志而不是追加，避免日志文件累积成无限大的单个文件。
同时建议在系统层面做crontab定期清理，比如保留30天的日志：
find /opt/pgsql12/data/log -name "postgresql-*.log" -mtime +30 -delete把这个命令写进crontab每日执行。日志这块看起来不起眼，但真到故障发生时，有历史日志可用和没日志可用，排查效率天差地别。保留30天是一个性价比比较高的平衡点，既不会占用太多磁盘，也保留了足够的回溯窗口。
5. 常见问题与排查技巧实录
5.1 权限与依赖问题：initdb和编译阶段的重灾区
症状一：initdb提示“cannot be run as root”。这是PostgreSQL的安全设计，不是bug。解决办法就是切换到postgres用户再执行，或者用su - postgres -c包装命令。从设计角度理解：数据库服务绝不允许以最高权限运行，这是纵深防御的一部分，切用户就对了。
症状二：configure阶段提示readline.h not found或zlib.h not found。说明缺少对应的-devel包，用包管理安装后重新configure。注意make到一半报缺头文件的情况，此时不需要全部重新make，补装依赖后重新执行configure再make即可，增量编译会自动跳过已完成的文件。
5.2 启动失败排查：日志是唯一可信的灯塔
症状三：pg_ctl start报could not bind IPv4 socket: Permission denied。这通常是端口被占用。用ss -tlnp | grep 5432查看哪个进程占用了5432端口，然后处理掉占用进程，或修改PostgreSQL端口。
症状四：启动时报FATAL: lock file "postmaster.pid" already exists。这是上次数据库异常退出留下的PID文件。解决方案是确认没有postgres进程在运行（ps aux | grep postgres确认无残留），然后删除/opt/pgsql12/data/postmaster.pid再启动。注意：先确认进程真的不在了再删PID文件，否则可能影响一个正在运行的实例。
症状五：数据库启动成功但本地连不上，报no pg_hba.conf entry。这是pg_hba.conf里没有匹配的认证规则。确认你连接时用的用户、来源IP、连接方式，然后在pg_hba.conf里添加匹配的条目，reload即可。
连接PostgreSQL时记住一个思路：问题只可能出在三个环节——网络层面（能否到达端口）、认证层面（pg_hba.conf是否允许）、权限层面（用户是否有权访问该库）。从这三层逐层排查，绝大多数连接问题都能定位。
5.3 常见问题速查表
我整理了一份高频问题速查表，方便遇到问题时快速对照：
| 现象 | 可能原因 | 排查命令/方法 | 解决思路 |
|---|---|---|---|
| initdb报cannot be run as root | 用了root身份 | 切换postgres用户 | su - postgres后执行 |
| configure缺readline.h | 缺readline-devel | 安装依赖 | yum install readline-devel |
| 启动报Port被占用 | 端口有进程监听 | ss -tlnp | grep 5432 | 处理占用进程或改端口 |
| 启动报postmaster.pid exists | 上次异常退出残留 | ps确认无postgres进程 | 删除pid文件后启动 |
| 本地连接报pg_hba.conf无条目 | 认证规则未覆盖 | 查看pg_hba.conf | 添加匹配的规则并reload |
| 远程连接超时 | 防火墙拦截 | firewall-cmd --list-all | 放行5432端口或调整防火墙 |
| 密码登录报认证失败 | 客户端认证方式不匹配 | 检查pg_hba.conf | 将auth改为scram-sha-256 |
| 查询变慢且CPU高 | work_mem太小导致磁盘排序 | EXPLAIN ANALYZE | 适当调大work_mem |
| 日志快速占满磁盘 | 未配置日志轮转 | du -sh /opt/pgsql12/data/log | 开启log_rotation并定期清理 |
5.4 内存相关参数调优：一次OOM事故的复盘
最后聊一个让我印象深刻的调优案例。有一次同事反馈业务系统响应极慢，数据库完全不干活的样子。检查系统内存发现几乎耗尽，dmesg里有明显的OOM记录，进程被系统杀掉了。
复盘时发现罪魁祸首是shared_buffers被设置成了主机内存的80%，远超合理值。同时max_connections被调到1000，每个连接预分配的缓存加起来又吃掉了大量内存。两个参数叠加，机器直接被榨干。
PostgreSQL参数调优的一个基本心法：先算后配。拿到一台服务器，先看总内存，然后按比例分配：shared_buffers占25%、effective_cache_size占50%~70%、work_mem按并发数估算。比如16GB内存的机器：
shared_buffers = 4GB # 16GB * 25% effective_cache_size = 10GB # 约16GB * 60% work_mem = 8MB max_connections = 200这样配置的总额是4GB + 8MB*200 ≈ 5.6GB，加上系统本身和PostgreSQL后台进程的开销，16GB内存仍然健康。调参后业务恢复平稳，此后再没有出现过OOM。
提示：任何内存参数的调整，改完都先
pg_ctl restart，再用top或free -h观察内存占用趋势。数据库刚启动时的内存占用会随着后续的查询缓存逐步增长，不要只看启动瞬间的数值就下结论。
写在最后
经过这么多次部署，我自己最大的体会是：PostgreSQL的安装部署从来不是“把命令敲一遍”那么简单，它的每一步都藏着权限模型、进程管理、内存分配这些计算机系统的基础原理。你愿意多想一层“为什么”，后面排查问题的速度就会快一分。
最后再分享一个小技巧：配置完一套环境后，用pg_ctl status配合psql -c "show shared_buffers;"和psql -c "show max_connections;"这类命令，把当前生效的关键配置导出来存档。下次调优或者重建环境，拿这份存档对照着来，比翻聊天记录找当初改了啥靠谱得多。这一套流程走下来，你对Linux服务和数据库之间的关系，会有比读十本书都更直接的认识。