PentAGI 多并行 flow 下如何调整 PostgreSQL 连接池参数并检查连接预算【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi当 PentAGI 同时运行多个 flow 时所有 flow 共享同一套到 PostgreSQL 的应用连接池。README 中明确说明默认池参数是按10 个并行 flow含并发 API 请求来规划的。如果你跑的 flow 数超过 10或多个 PentAGI 实例共用同一个 PostgreSQL就需要调整连接池环境变量和 PostgreSQL 的max_connections并通过pg_stat_activity等视图核对实际连接预算。本文基于仓库内的 README 连接池章节、backend/docs/database.md 和 backend/docs/config.md 给出完整操作路径适用于使用官方docker-compose.yml部署 PentAGI 的场景。先理解 PentAGI 的两个独立连接池PentAGI 对同一个 PostgreSQL 实例打开两个互不共享的池调整参数时必须同时考虑这两个池池环境变量默认值使用方共享sql.DBlib/pqDATABASE_MAX_OPEN_CONNS25全部 sqlc 查询与 GORM handler 共用这一个*sql.DB共享pgxpoolDATABASE_VECTOR_MAX_CONNS10全部 pgvector storeagent memory knowledge API第三个参数DATABASE_MAX_IDLE_CONNS默认5控制sql.DB池在两次请求之间保留的最大空闲连接数。按默认值单个 PentAGI 进程最多消耗 35 个 PostgreSQL 连接25 10。这是一个硬性的应用层预算而不是对稳态用量的预测——实际占用取决于当时有多少并发请求和向量操作。检查当前部署的连接预算在运行中的部署上用以下三条命令检查 PostgreSQL 上限、当前用量和按客户端的明细。命令直接来自 README在部署 PentAGI 的主机上执行# Postgres 上限 docker exec pgvector sh -c psql -U $POSTGRES_USER -d $POSTGRES_DB -c \ SELECT name, setting FROM pg_settings WHERE name IN (max_connections, superuser_reserved_connections); # 当前用量 vs. 可用 docker exec pgvector sh -c psql -U $POSTGRES_USER -d $POSTGRES_DB -c \ SELECT max_conn, used, max_conn - used AS available FROM (SELECT current_setting(max_connections)::int AS max_conn, count(*) AS used FROM pg_stat_activity) t; # 按客户端拆分PentAGI、pgexporter、autovacuum 等 docker exec pgvector sh -c psql -U $POSTGRES_USER -d $POSTGRES_DB -c \ SELECT application_name, client_addr, state, count(*) FROM pg_stat_activity WHERE pid pg_backend_pid() GROUP BY 1, 2, 3 ORDER BY count DESC;README 给出的默认部署vxcontrol/pgvector:latest镜像max_connections 100、superuser_reserved_connections 3下的预算示例如下仅作为量级参考不同环境的实际数值不同Available for client connections 97 pentagi sql.DB (DATABASE_MAX_OPEN_CONNS) 25 pentagi pgxpool (DATABASE_VECTOR_MAX_CONNS) 10 pgexporter 3 autovacuum workers 3 ───────────────────────────────────────── Total consumed 41 Free buffer 56 (≈ 58 %)判断依据第二条命令的available列反映实时余量第三条命令可以确认 PentAGI 两池、pgexporter、autovacuum 各自占用多少。如果你的部署里 PentAGI 连接数已接近上限且余量很小而你又准备提高并行 flow 数量就进入下一步调整。注意不要从vxcontrol/pgvector:latest镜像标签推断具体的 PostgreSQL 大版本文档建议直接在部署库上执行SHOW server_version确认。调整连接池参数与 max_connections官方 Compose 栈已经把三个池参数透传给 backend 服务docker-compose.yml 中对应行为- DATABASE_MAX_OPEN_CONNS${DATABASE_MAX_OPEN_CONNS:-} - DATABASE_MAX_IDLE_CONNS${DATABASE_MAX_IDLE_CONNS:-} - DATABASE_VECTOR_MAX_CONNS${DATABASE_VECTOR_MAX_CONNS:-}因此在宿主机.env中设置即可例如数值按你的并行 flow 数量确定README 只说明需“按比例增大”未给出固定推荐值DATABASE_MAX_OPEN_CONNS40 DATABASE_VECTOR_MAX_CONNS20 DATABASE_MAX_IDLE_CONNS10如果多个 PentAGI 实例共用同一个数据库服务器要把每个实例的两个池上限都加起来并为 PostgreSQL 预留连接、autovacuum、监控客户端如pgexporter和管理/迁移会话留出容量单个进程 35 连接的预算在 N 个实例下会线性放大。同时提高 PostgreSQL 侧的上限。修改docker-compose.yml中pgvector服务按 README 的写法加command覆盖pgvector: image: vxcontrol/pgvector:latest command: postgres -c max_connections200两个变更的生效前提各不相同池参数在main.go启动序列中通过SetMaxOpenConns/SetMaxIdleConns和pgxpool配置读取因此需要重启 PentAGI backend 服务才会生效。max_connections修改的是pgvector容器的启动命令需要重建该容器例如docker compose up -d pgvector。数据库数据持久化在pentagi-postgres-data卷中重建容器不会丢数据但 PostgreSQL 会短暂不可用其他服务backend、pgexporter会在其健康检查通过后恢复。变更后的验证方式重启完成后按以下顺序核对重跑上面“Postgres 上限”那条pg_settings查询确认max_connections已变成你设置的值如200superuser_reserved_connections保持不变。重跑“当前用量 vs. 可用”查询确认available余量重新回到健康区间。用“按客户端拆分”查询观察 PentAGI 实际占用的连接数。文档没有把某个数值定义为成功阈值这一步是用来确认新预算生效、且 PentAGI 两池没有超过你设置的环境变量上限如果 PentAGI 连接数长期贴着DATABASE_MAX_OPEN_CONNS DATABASE_VECTOR_MAX_CONNS说明并行 flow 规模确实超过了当前池配置需要再次按比例上调。应用行为层面PentAGI 在启动时若遇到租户 schema 不匹配或迁移失败会拒绝对外提供服务见 database.md 的启动序列重启后 backend 容器能正常启动本身就是池参数被接受的一个前置信号。限制与边界连接预算是应用层硬上限不等于实际使用量先通过pg_stat_activity观察真实占用再决定放大多少。如果DATABASE_URL指向 PgBouncer 或 Supabase Supavisor 而不是直连 PostgreSQL多租户部署另有约束PgBouncer 需要pool_mode session、ignore_startup_parameters search_path和按租户的connect_query详见 backend/docs/config.md 的 Multi-Instance Deployment 与 PgBouncer 章节本节的预算算法在池前置场景下仍需考虑池本身的容量。DATABASE_MAX_IDLE_CONNS只影响sql.DB池的空闲连接保留不改变pgxpool的行为。以上操作完成后验证落点就是pg_settings里的新上限、pg_stat_activity中的实时余量以及 PentAGI 连接数不超过两个池环境变量之和。相关文档backend/docs/database.md连接池、Connection budget 与排错、backend/docs/config.md环境变量全表。【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PentAGI 多并行 flow 下如何调整 PostgreSQL 连接池参数并检查连接预算？
PentAGI 多并行 flow 下如何调整 PostgreSQL 连接池参数并检查连接预算【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi当 PentAGI 同时运行多个 flow 时所有 flow 共享同一套到 PostgreSQL 的应用连接池。README 中明确说明默认池参数是按10 个并行 flow含并发 API 请求来规划的。如果你跑的 flow 数超过 10或多个 PentAGI 实例共用同一个 PostgreSQL就需要调整连接池环境变量和 PostgreSQL 的max_connections并通过pg_stat_activity等视图核对实际连接预算。本文基于仓库内的 README 连接池章节、backend/docs/database.md 和 backend/docs/config.md 给出完整操作路径适用于使用官方docker-compose.yml部署 PentAGI 的场景。先理解 PentAGI 的两个独立连接池PentAGI 对同一个 PostgreSQL 实例打开两个互不共享的池调整参数时必须同时考虑这两个池池环境变量默认值使用方共享sql.DBlib/pqDATABASE_MAX_OPEN_CONNS25全部 sqlc 查询与 GORM handler 共用这一个*sql.DB共享pgxpoolDATABASE_VECTOR_MAX_CONNS10全部 pgvector storeagent memory knowledge API第三个参数DATABASE_MAX_IDLE_CONNS默认5控制sql.DB池在两次请求之间保留的最大空闲连接数。按默认值单个 PentAGI 进程最多消耗 35 个 PostgreSQL 连接25 10。这是一个硬性的应用层预算而不是对稳态用量的预测——实际占用取决于当时有多少并发请求和向量操作。检查当前部署的连接预算在运行中的部署上用以下三条命令检查 PostgreSQL 上限、当前用量和按客户端的明细。命令直接来自 README在部署 PentAGI 的主机上执行# Postgres 上限 docker exec pgvector sh -c psql -U $POSTGRES_USER -d $POSTGRES_DB -c \ SELECT name, setting FROM pg_settings WHERE name IN (max_connections, superuser_reserved_connections); # 当前用量 vs. 可用 docker exec pgvector sh -c psql -U $POSTGRES_USER -d $POSTGRES_DB -c \ SELECT max_conn, used, max_conn - used AS available FROM (SELECT current_setting(max_connections)::int AS max_conn, count(*) AS used FROM pg_stat_activity) t; # 按客户端拆分PentAGI、pgexporter、autovacuum 等 docker exec pgvector sh -c psql -U $POSTGRES_USER -d $POSTGRES_DB -c \ SELECT application_name, client_addr, state, count(*) FROM pg_stat_activity WHERE pid pg_backend_pid() GROUP BY 1, 2, 3 ORDER BY count DESC;README 给出的默认部署vxcontrol/pgvector:latest镜像max_connections 100、superuser_reserved_connections 3下的预算示例如下仅作为量级参考不同环境的实际数值不同Available for client connections 97 pentagi sql.DB (DATABASE_MAX_OPEN_CONNS) 25 pentagi pgxpool (DATABASE_VECTOR_MAX_CONNS) 10 pgexporter 3 autovacuum workers 3 ───────────────────────────────────────── Total consumed 41 Free buffer 56 (≈ 58 %)判断依据第二条命令的available列反映实时余量第三条命令可以确认 PentAGI 两池、pgexporter、autovacuum 各自占用多少。如果你的部署里 PentAGI 连接数已接近上限且余量很小而你又准备提高并行 flow 数量就进入下一步调整。注意不要从vxcontrol/pgvector:latest镜像标签推断具体的 PostgreSQL 大版本文档建议直接在部署库上执行SHOW server_version确认。调整连接池参数与 max_connections官方 Compose 栈已经把三个池参数透传给 backend 服务docker-compose.yml 中对应行为- DATABASE_MAX_OPEN_CONNS${DATABASE_MAX_OPEN_CONNS:-} - DATABASE_MAX_IDLE_CONNS${DATABASE_MAX_IDLE_CONNS:-} - DATABASE_VECTOR_MAX_CONNS${DATABASE_VECTOR_MAX_CONNS:-}因此在宿主机.env中设置即可例如数值按你的并行 flow 数量确定README 只说明需“按比例增大”未给出固定推荐值DATABASE_MAX_OPEN_CONNS40 DATABASE_VECTOR_MAX_CONNS20 DATABASE_MAX_IDLE_CONNS10如果多个 PentAGI 实例共用同一个数据库服务器要把每个实例的两个池上限都加起来并为 PostgreSQL 预留连接、autovacuum、监控客户端如pgexporter和管理/迁移会话留出容量单个进程 35 连接的预算在 N 个实例下会线性放大。同时提高 PostgreSQL 侧的上限。修改docker-compose.yml中pgvector服务按 README 的写法加command覆盖pgvector: image: vxcontrol/pgvector:latest command: postgres -c max_connections200两个变更的生效前提各不相同池参数在main.go启动序列中通过SetMaxOpenConns/SetMaxIdleConns和pgxpool配置读取因此需要重启 PentAGI backend 服务才会生效。max_connections修改的是pgvector容器的启动命令需要重建该容器例如docker compose up -d pgvector。数据库数据持久化在pentagi-postgres-data卷中重建容器不会丢数据但 PostgreSQL 会短暂不可用其他服务backend、pgexporter会在其健康检查通过后恢复。变更后的验证方式重启完成后按以下顺序核对重跑上面“Postgres 上限”那条pg_settings查询确认max_connections已变成你设置的值如200superuser_reserved_connections保持不变。重跑“当前用量 vs. 可用”查询确认available余量重新回到健康区间。用“按客户端拆分”查询观察 PentAGI 实际占用的连接数。文档没有把某个数值定义为成功阈值这一步是用来确认新预算生效、且 PentAGI 两池没有超过你设置的环境变量上限如果 PentAGI 连接数长期贴着DATABASE_MAX_OPEN_CONNS DATABASE_VECTOR_MAX_CONNS说明并行 flow 规模确实超过了当前池配置需要再次按比例上调。应用行为层面PentAGI 在启动时若遇到租户 schema 不匹配或迁移失败会拒绝对外提供服务见 database.md 的启动序列重启后 backend 容器能正常启动本身就是池参数被接受的一个前置信号。限制与边界连接预算是应用层硬上限不等于实际使用量先通过pg_stat_activity观察真实占用再决定放大多少。如果DATABASE_URL指向 PgBouncer 或 Supabase Supavisor 而不是直连 PostgreSQL多租户部署另有约束PgBouncer 需要pool_mode session、ignore_startup_parameters search_path和按租户的connect_query详见 backend/docs/config.md 的 Multi-Instance Deployment 与 PgBouncer 章节本节的预算算法在池前置场景下仍需考虑池本身的容量。DATABASE_MAX_IDLE_CONNS只影响sql.DB池的空闲连接保留不改变pgxpool的行为。以上操作完成后验证落点就是pg_settings里的新上限、pg_stat_activity中的实时余量以及 PentAGI 连接数不超过两个池环境变量之和。相关文档backend/docs/database.md连接池、Connection budget 与排错、backend/docs/config.md环境变量全表。【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考