为何pg_largeobject持续增长？WSO2SP系统PostgreSQL问题排查咨询
针对你遇到的WSO2 SP系统中pg_largeobject表不断膨胀的问题，我整理了几个从数据库到应用层的排查方向，帮你定位根因：
1. 从PostgreSQL端追踪大对象的全生命周期
首先从数据库本身入手，搞清楚这些大对象是谁创建的、什么时候创建的，以及是否被正确引用：
- 统计现有大对象的基本信息：运行以下SQL查看所有大对象的大小、创建时间、所属用户等，快速定位哪些对象占空间最多：
SELECT lo.loid, lm.relname, lm.relnamespace::regnamespace AS schema, pg_size_pretty(pg_total_relation_size(loid::regclass)) AS total_size, pg_get_userbyid(lm.relowner) AS owner, lm.relcreationtime AS create_time FROM pg_largeobject_metadata lm JOIN pg_largeobject lo ON lm.loid = lo.loid GROUP BY lo.loid, lm.relname, lm.relnamespace, lm.relowner, lm.relcreationtime ORDER BY pg_total_relation_size(loid::regclass) DESC;
- 实时追踪创建大对象的会话：如果表正在持续增长，用这个SQL抓当前正在操作大对象的进程，看是哪个应用/用户在创建：
SELECT pid, query, usename, client_addr, state, query_start FROM pg_stat_activity WHERE query LIKE '%lo_create%' OR query LIKE '%lo_import%' OR query LIKE '%pg_largeobject%' OR query LIKE '%bytea%';
- 检查孤立的大对象（泄漏排查）：如果WSO2 SP的业务表中有字段关联大对象ID（比如
blob_ref之类的字段），可以对比找出没有被业务表引用的孤立大对象——这些就是没被正确清理的泄漏对象：
-- 替换your_business_table和blob_reference_column为实际的业务表和关联字段 SELECT lm.loid FROM pg_largeobject_metadata lm WHERE NOT EXISTS ( SELECT 1 FROM your_business_table bt WHERE bt.blob_reference_column = lm.loid );
2. 深入分析WSO2 SP的日志与配置
既然你无法直接控制WSO2对pg_largeobject的调用，那就从应用层的行为入手：
开启DEBUG级日志追踪：修改WSO2 SP的
log4j2.xml，开启数据库存储相关组件的DEBUG日志，比如org.wso2.extension.siddhi.store.rdbms、org.wso2.carbon.database.utils。这样能看到系统什么时候创建大对象、有没有尝试删除，以及对应的业务操作上下文。检查Siddhi应用的存储逻辑：查看你部署的Siddhi查询，有没有定义存储BLOB类型的表？比如是否用了
(data blob)这样的字段？同时检查是否配置了数据过期策略（比如@expire注解），如果窗口或聚合操作持久化了BLOB，但没设置自动清理，就会不断累积。排查系统级任务：WSO2 SP有没有定时运行的备份、导出或数据同步任务？这些操作可能会批量创建大对象，但执行完后没有清理临时对象。
3. 验证PostgreSQL的自动清理机制
有时候不是创建太多，而是PostgreSQL没及时回收空间：
检查autovacuum状态：运行
SELECT * FROM pg_stat_user_tables WHERE relname IN ('pg_largeobject', 'pg_largeobject_metadata');，看last_autovacuum和last_autoanalyze的时间是否正常，确认autovacuum有没有处理这两张表。手动触发清理验证：如果autovacuum没及时运行，手动执行
VACUUM ANALYZE pg_largeobject;和VACUUM ANALYZE pg_largeobject_metadata;，之后观察表空间的变化。如果空间能回收，说明是autovacuum配置不合理（比如阈值太高），需要调整autovacuum_vacuum_threshold等参数。
4. 追踪业务数据流的特征
最后回到业务本身，确认是否是正常的业务增长还是异常流量：
分析流入数据的大小：检查WSO2 SP接收的数据流，是否有大量包含大尺寸二进制内容的消息（比如图片、日志文件、二进制传感器数据）？如果业务量确实在增长，那pg_largeobject的增长是正常的，需要调整清理策略的频率；如果是异常流量（比如爬虫、测试数据），则需要拦截。
检查数据处理链路：确认Siddhi应用中是否有未优化的逻辑，比如把所有BLOB数据都持久化到数据库，而不是只保留必要的部分？或者是否有重复处理同一份数据导致重复创建大对象？
通过以上步骤，你应该能精准定位到pg_largeobject增长的原因——是业务正常需求、应用未正确释放对象，还是数据库配置问题。之后再针对性调整，比如优化WSO2的清理策略、修复Siddhi逻辑，或者调整PostgreSQL的vacuum参数。
内容的提问来源于stack exchange，提问作者Alexander Goida
