PostgreSQL在生产环境中随着写入量增加，磁盘占用会持续上升。如果不能提前感知增长趋势，很容易在毫无准备的情况下遭遇磁盘写满、实例只读甚至崩溃。要避免这类事故，需要一套能持续预测磁盘占用并支撑容量规划的体系，而不是临时查看一次剩余空间。
一、理解PostgreSQL磁盘占用的组成部分
在做预测之前，必须先弄清楚PostgreSQL把数据写到了哪些地方。最主要的消耗来自三块：用户数据表与索引、预写日志（WAL）以及各类日志与临时文件。表与索引的体积可以通过系统视图直接查询，而WAL的增长速度和写入峰值密切相关，通常和业务的提交频率成正比。
除了上述核心部分，自动清理（autovacuum）产生的额外膨胀、未提交事务留下的死元组、以及归档失败导致的WAL堆积，也会悄悄吃掉磁盘。如果只监控数据表大小，往往会低估真实占用。因此容量规划的第一步，是建立对全量磁盘消耗来源的清晰认知，并把它们都纳入采集范围。
1.1 使用系统视图获取基础数据
PostgreSQL提供了pg_database_size、pg_tablespace_size以及pg_relation_size等函数，可以很方便地拿到库、表空间以及具体关系的字节数。下面这段SQL展示了如何按表空间汇总当前占用：
-- 查询每个表空间当前字节占用 SELECT spcname AS tablespace_name, pg_tablespace_size(oid) AS size_bytes FROM pg_tablespace ORDER BY size_bytes DESC;
把上述查询结果定期落盘，就得到了容量变化的原始序列。后续所有预测都依赖这些带有时间戳的样本，因此采集频率建议控制在每小时或每天一次，过于频繁会增加系统负担，过于稀疏又会漏掉突增点。
二、构建持续采集与存储机制
容量规划体系必须能自动、稳定地收集历史占用数据。最简单的方式是用操作系统定时任务配合一个小脚本，把查询结果写入独立的指标表或时序库中。指标表本身也应放在单独的数据库或模式里，避免和业务库竞争资源。
下面是一个轻量的采集脚本示例，它连接数据库并把当前所有表空间占用写入本地指标表。通过这种办法，我们能把分散的快照聚合成连续的时间序列，为预测提供弹药。
import psycopg2
from datetime import datetime
conn = psycopg2.connect(host='127.0.0.1', dbname='meta', user='monitor')
cur = conn.cursor()
cur.execute("""
CREATE TABLE IF NOT EXISTS ts_size_log (
log_time TIMESTAMP,
ts_name TEXT,
size_bytes BIGINT
)
""")
cur.execute("""
INSERT INTO ts_size_log
SELECT now(), spcname, pg_tablespace_size(oid)
FROM pg_tablespace
""")
conn.commit()
cur.close()
conn.close()
2.1 采集频率与保留策略
对于大多数业务，每天一次全量采样已经足够反映趋势；如果写入峰值明显，可以提到每小时。指标数据本身会不断增长，需要设置保留期，例如保留两年原始数据，更早的做按周聚合，既节省空间又不影响长期预测。
另外要注意，在采集脚本中捕获异常非常关键。当数据库负载极高或连接数耗尽时，采集可能失败，此时应有本地缓存与重试，防止指标断档导致预测模型误判为“零增长”。
三、磁盘占用的持续预测方法
持续预测的本质，是用历史序列拟合未来走向。最实用的入门方案是线性回归：把时间作为自变量，占用字节作为因变量，算出每日平均增量，再推算多少天后触及磁盘上限。虽然线性模型不能表达突发暴涨，但足以覆盖平稳业务。
当业务有明显周期或近期波动加大时，可以改用滚动均值加趋势项，或者直接使用时序库自带的预测函数。下面的Python代码演示了如何用最近三十天数据做简单线性回归，并输出预计写满天数：
import psycopg2
from datetime import datetime, timedelta
import numpy as np
conn = psycopg2.connect(host='127.0.0.1', dbname='meta', user='monitor')
cur = conn.cursor()
cur.execute("""
SELECT log_time, size_bytes FROM ts_size_log
WHERE ts_name='pg_default'
AND log_time > now() - interval '30 days'
ORDER BY log_time
""")
rows = cur.fetchall()
cur.close()
conn.close()
t = np.array([(r[0]-rows[0][0]).days for r in rows], dtype=float)
y = np.array([r[1] for r in rows], dtype=float)
slope, intercept = np.polyfit(t, y, 1)
disk_limit = 500 * 1024**3 # 假设磁盘上限500GB
days_to_full = (disk_limit - intercept) / slope
print('预计写满天数:', int(days_to_full))
3.1 预测结果如何用于告警
预测出的“剩余天数”应作为核心指标接入监控系统。例如当剩余天数低于21天时发警告，低于7天时发严重告警。相比单纯看使用率，这种基于趋势的预警能让DBA提前扩容或清理数据。
需要注意的是，预测值会随新样本更新，因此告警状态也应可自动恢复。若某天业务下调导致斜率变负，系统不应继续报“即将写满”，而要计算新的安全窗口，这才是持续预测体系的价值所在。
四、容量规划体系的落地结构
一个完整的容量规划体系包含四个环节：采集、存储、计算、告警。采集负责拿数据，存储保证历史可追溯，计算产出预测与汇总，告警把结论推给人。这四个环节解耦后，每个部分都能单独升级，比如把线性模型换成机器学习模型而不影响采集。
在中小团队中，用定时脚本加单表存储就能跑起来；当实例增多后，应引入时序数据库与统一监控面板，把多个集群的磁盘预测集中展现。下表对比了两种常见落地方式：
| 方案 | 适用规模 | 维护成本 | 扩展性 |
|---|---|---|---|
| 脚本加关系表 | 单集群或少量实例 | 低 | 弱 |
| 时序库加监控平台 | 多集群大规模 | 中 | 强 |
4.1 避免常见规划误区
一个典型误区是只用当前使用率乘以经验系数来估容量，这种方法在业务变更时完全失效。另一个误区是忽略WAL与日志，只盯表大小，结果表没满但磁盘先满。体系化预测正是为了替代这些拍脑袋做法。
当体系运转成熟后，还可以把预测结果反馈给业务方，例如提示“按当前增速，三个月后需扩容”，让资源申请提前走流程。这种从技术预测到业务流程的闭环，才是容量规划的最终目标。
postgresql磁盘占用预测容量规划修改时间：2026-08-09 00:15:36