人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载本指南聚焦 Agent Substrate 项目中 ateapi 的 PostgreSQL 存储后端Cloud SQL for PostgreSQL在大规模 actor 数量与高请求速率下的容量规划与扩缩容策略覆盖实例规格与本地 SSD 数据缓存、磁盘 IOPS 规划、连接池数学、代理 sidecar 资源预算与托管连接池Managed Connection Pooling并给出可直接套用的计算公式与部署命令。读完本文你将能根据目标 QPS 与数据集规模量化地为 Cloud SQL 存储层选择 tier、磁盘、连接数与 sidecar 配额避免 I/O 瓶颈与连接耗尽。前置阅读本文是 tools/setup-gcp/cloud-sql.md 中“Scaling the database”一节的纵深展开。该文档讲解了 Cloud SQL 实例的供给、IAM 数据库认证、代理 sidecar 注入与验证流程是理解本指南配置项来源的前提。本指南对应的完整文档为 docs/dev/cloud-sql-scaling-guide.md。什么时候需要开始扩容从“够用”到“I/O 受限”setup-gcp create cloudsql的供给默认值是db-custom-2-81922 vCPU / 8 GB 内存加 10 GB 磁盘适合开发环境与中等规模的 fleets见 tools/setup-gcp/cloud-sql.md 与 tools/setup-gcp/cmd/cloudsql.go 中的 flag 默认值。当 actor 数量上升后存储层会首先变成I/O-bound其物理机制是只要表与索引的**工作集working set**仍然小于实例内存所有点查询都由 shared buffers 缓存命中读延迟是微秒级一旦表 索引超过 RAM均匀随机读就开始大量落出缓存命中持久化磁盘的点查询point lookup要付出数毫秒的持久盘延迟p50 延迟随之劣化到磁盘延迟水平。因此本文所有旋钮都按性价比从高到低排序先加内存再上数据缓存然后规划磁盘最后精确计算连接数。实例规格内存是第一杠杆Enterprise Plus 解锁本地 SSD 数据缓存内存缓存工作集的主要手段配置方式创建时用--tier/--edition设置或在创建后用gcloud sql instances patch修改——注意edition/tier 变更会重启实例应在维护窗口执行。扩容判据读请求由缓存服务直到工作集表 索引超出 RAM一旦超出的数据量可观p50 延迟就会退化到磁盘延迟水平。所以第一步永远是观察“数据集大小 vs 内存大小”而不是盲目加 vCPU。Enterprise Plus 与本地 SSD 数据缓存当数据集在任何 tier 的 RAM 都无法容纳时切换到 Enterprise Plusgcloud sql instances patch instance --editionenterprise-plus --tierdb-perf-optimized-N-vCPUEnterprise Plus 只能搭配db-perf-optimized-N-vCPU系列 tierN为 vCPU 数该版本提供本地 SSD 数据缓存local-SSD data cache把有效缓存扩展到内存的若干倍那些本会穿透到持久盘的读请求改由本地 SSD 服务延迟远低于持久盘。从仓库源码可以印证这一设计意图。在 tools/setup-gcp/cmd/cloudsql.go 中cloudSQLInstanceSpec对 edition 做映射并开启数据缓存case , enterprise: // Enterprise edition accepts db-custom-vCPU-MB tiers. settings.Edition ENTERPRISE case enterprise-plus: // Enterprise Plus only accepts db-perf-optimized-N-vCPU tiers. Its // local-SSD data cache is the reason to pick it for this store: it // extends the effective cache beyond RAM once the dataset outgrows // memory (see cloud-sql.md, Scaling the database). settings.Edition ENTERPRISE_PLUS settings.DataCacheConfig sqladmin.DataCacheConfig{DataCacheEnabled: true}也就是说setup-gcp create cloudsql --editionenterprise-plus会在创建请求里同时设置ENTERPRISE_PLUS与DataCacheEnabled而对已存在实例则需手动gcloud sql instances patch工具不会 reconcile 已存在实例的形状见 tools/setup-gcp/cloud-sql.md 的说明。磁盘IOPS 随容量线性放大磁盘本身才是 I/O 旋钮配置方式创建时--storage-sizeGB指定之后磁盘只能增长不能缩小。关键事实持久化磁盘的 IOPS 与吞吐随预置容量provisioned size缩放——所以预置磁盘大小本质上是 I/O 能力的预算而不只是容量。最佳实践按预期数据集的约 2 倍预置记录 索引 WAL bloat不要依赖自动扩容auto-resize 按小步长增长批量加载时会造成停滞。源码同样印证了“预置而非自动扩容”的立场tools/setup-gcp/cmd/cloudsql.go// 0 leaves the Cloud SQL default (10 GB, auto-resizing). PD IOPS and // throughput scale with provisioned size, so benchmarks and production // should pre-size rather than rely on auto-resize. if cfg.CloudSQLStorageGB 0 { settings.DataDiskSizeGb cfg.CloudSQLStorageGB }连接池按目标吞吐反推连接数连接池在 ateapi 侧通过环境变量ATE_API_POSTGRES_POOL_MAX_CONNS配置部署期设置见 tools/setup-gcp/cloud-sql.md 的可选环境变量一节。它的默认值是max(4, NumCPU)——即取 4 与 vCPU 数二者较大者该值会被以pool_max_conns的形式追加到当前生效的 DSN 上合成的、集群内默认的或显式提供的 DSN 均可显式 DSN 中已有的pool_max_conns优先。相关逻辑位于 hack/install-ate.sh它会检查 DSN 是否已含pool_max_conns再决定追加还是替换。目标连接数公式目标连接数 吞吐量QPS× 平均查询延迟秒connections ≈ QPS × mean latency in seconds ≈ 10,000 req/s × 0.006 s ≈ 60 active connections预留约2 倍余量应对突发例如 4 个副本 ×ATE_API_POSTGRES_POOL_MAX_CONNS32。连接池过小不会报数据库错误而是在客户端侧pgx 内部排队等待连接——表现为请求延迟上升而非连接错误排障时容易被误判。必须保证所有副本的连接总数落在 Cloud SQL 的实例连接上限之内replicas × pool_max_conns ≤ max_connections − slacksuperuser、maintenance 等保留连接超过 max_connections 与“连接越多越好”的误区超过 Cloud SQL 的max_connections会直接报错FATAL: sorry, too many clients already。调整上限gcloud sql instances patch --database-flags…但该参数列表会整体替换所有 flags因此每次都必须重新带上cloudsql.iam_authenticationon否则会意外关闭 IAM 认证导致代理登录失败。超过“约 2 倍 vCPU 数”的活跃连接不会带来任何吞吐收益PostgreSQL 后端是 OS 进程多余的活跃连接只会互相上下文切换context-switch浪费 CPU。结论围绕公式算出的数字小幅扫掠sweep即可不要盲目最大化。源码侧佐证atepg 的池化实现与专用的 watch 池ateapi 的 PostgreSQL 存储实现在 cmd/ateapi/internal/store/atepg/atepg.go它基于pgxpool建立了两个独立的池主写池承载所有业务写入worker 状态、leases 等watch 池watch pool专用于 outbox 侧WatchWorkers 轮询与分区维护容量固定为 3watchPoolMaxConns 3最小 1见 atepg.go// watchPoolMaxConns sizes the dedicated outbox watch pool: one connection // for the WatchWorkers poller, one for the maintenance loop, and one of headroom // so a transiently slow poll can never gate a maintenance pass. const ( watchPoolMaxConns 3 watchPoolMinConns 1 )Connect会复制主池配置并覆写MaxConns/MinConns来构造 watch 池atepg.go。测试 cmd/ateapi/internal/store/atepg/outbox_test.go 也断言了watchPool.Config().MaxConns watchPoolMaxConns。这意味着即使你通过ATE_API_POSTGRES_POOL_MAX_CONNS把主池调得很大outbox 轮询也只占用每副本最多 3 条连接watchPoolMaxConns在计算replicas × pool_max_conns时应为每条副本额外预留这 3 条。此外atepg 的连接配置在每次新建连接时会重新解析 DSN 以读取最新 TLS 材料poolConfig的BeforeConnect见 atepg.go处理 kubelet 每日轮换 pod 证书的场景。代理 sidecar 资源CPU 随吞吐线性增长连接 churn 有独立上限Cloud SQL Auth Proxy 作为 native sidecarinitContainer restartPolicy: Always要求 Kubernetes 1.29注入ate-api-server部署其清单为 manifests/ate-install/cloudsql/proxy-sidecar-patch.yaml仅当设置ATE_API_POSTGRES_CLOUDSQL_INSTANCE时由 hack/install-ate.sh 应用。代理不施加连接数上限并只增加亚毫秒级延迟但它加密全部数据库流量TLS 1.3 隧道因此CPU 用量随吞吐线性增长补丁默认的资源请求为cpu: 100m、memory: 128Mi见 proxy-sidecar-patch.yaml这个配额是针对控制面流量规模设计的在持续每秒数千 ops的负载下需要调高 sidecar 的 CPU request避免节点压力把代理限流使它成为新的瓶颈。连接churn有独立的配额上限IAM 数据库登录按实例配额为12,000/min。对稳态的连接池来说无影响但如果大量副本同时重连reconnect storm可能触及该配额。Managed Connection Pooling用服务端池化解“副本太多”问题当 ateapi 副本非常多需要的真实后端连接达到数千条时使用 Cloud SQL 的托管连接池Managed Connection Pooling仅 Enterprise Plus 支持gcloud sql instances patch instance --enable-connection-pooling原理与参数服务端把最多max_client_connections默认 5,000条客户端连接复用multiplex到每个 databaseuser 对最多max_pool_size默认 50条后端连接上这是“很多 ateapi 副本本需要数千真实后端”场景的正解。当前仓库的一个重要限制该池化模式不能与 atepg 高效的transaction模式共存——worker-watch 路径使用LISTEN而 transaction pooling 不支持LISTENsession模式可以工作但会放弃大部分复用收益。这并非臆测atepg 的 WatchWorkers 确实通过轮询 事件流机制与数据库交互outbox 方案在 cmd/ateapi/internal/store/atepg/outbox.go 中有完整描述它依赖专用 watch 池对worker_outbox表做 xid 游标轮询并靠pg_postmaster_start_time与 trim 高水位检测重启与落后outbox.go。尽管当前实现走的是轮询而非LISTEN但连接复用/会话固定语义上的不兼容仍然成立——在使用托管连接池前务必评估 worker-watch 路径的会话要求。若启用托管连接池max_pool_size按前文公式的数字设置在max_connections中为 pooler预留约每 vCPU 15 条服务端连接。超出配置范畴分区是 schema 工程当单表行数达到数十亿行时运维极限不再是连接或 IOPS而是VACUUM 时长与单块大表上的索引维护成为操作瓶颈解决办法是把大表分区——这是 schema 层面的改造不是配置变更。仓库内部已经有一个可借鉴的实现范例atepg 的 worker outbox 表本身就是按created_at范围分区的15 分钟一个分区PARTITION BY RANGE (created_at)见迁移脚本 cmd/ateapi/internal/store/atepg/migrations/000001_initial.sql并配套后台维护循环outbox.go负责预创建分区、清理 stray DEFAULT 分区与按保留期 drop 过期分区drop 操作通过 advisory lock 在副本间选举单一执行者避免 AB/BA 死锁。对需要长期横向扩展的 ateapi 主表如 worker 状态历史可以参考这套模式设计你自己的分区与保留策略。扩容决策速查表关注点旋钮 / 命令关键数字内存第一杠杆--tier、--editiongcloud sql instances patch会重启工作集 ≤ RAM 时读延迟为微秒级数据集超出任何 tier 的 RAM--editionenterprise-plusdb-perf-optimized-N-vCPU本地 SSD 数据缓存把有效缓存扩展到内存数倍磁盘 IOPS/吞吐--storage-size只能增预置 ≈ 2× 数据集记录索引WALbloat连接池大小ATE_API_POSTGRES_POOL_MAX_CONNS默认max(4, NumCPU)connections ≈ QPS × mean latency再 ×2 余量实例连接上限gcloud sql instances patch --database-flags…整表替换需重带cloudsql.iam_authenticationonreplicas × pool_max_conns ≤ max_connections − slack活跃连接上限无配置项超过约 2× vCPUs 的活跃连接无吞吐收益代理 sidecar CPUproxy-sidecar-patch.yaml默认 100m数千 ops/s 需上调IAM 登录配额无配置项12,000/min/实例重连风暴需注意服务端池化--enable-connection-poolingEnterprise Plusmax_client_connections默认 5000max_pool_size默认 50预留 ~15 conn/vCPU数十亿行schema 分区工程参考 outbox 的 15 分钟分区 维护循环模式整体思路可以概括为一句话先让缓存接住读再用磁盘预置买 IOPS用公式而不是直觉定连接数最后在 schema 层解决单表极限——按这个顺序逐级推进即可让 ateapi 的 PostgreSQL 存储层随 actor 规模平滑扩展。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Agent Substrate 接入 Cloud SQL for PostgreSQL基于 Cloud SQL Auth Proxy 与 IAM 数据库认证的无密码存储后端实战指南Agent Substrate 接入 Cloud SQL for PostgreSQL基于 Cloud SQL Auth Proxy 与 IAM 数据库认证的人工智能AI AgentAgent 沙箱云原生容器运行时零信任Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测 本篇技术指南围绕 Ag人工智能AI AgentAgent 沙箱云原生容器运行时零信任SMERF 实战指南基于可流式内存高效辐射场的实时大规模场景重建SMERF 实战指南基于可流式内存高效辐射场的实时大规模场景重建 SMERFStreamable Memory Efficient Radiance Fie人工智能深度学习NLP计算机视觉强化学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent Substrate 大规模场景下的 Cloud SQL 存储扩容实战指南
人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载本指南聚焦 Agent Substrate 项目中 ateapi 的 PostgreSQL 存储后端Cloud SQL for PostgreSQL在大规模 actor 数量与高请求速率下的容量规划与扩缩容策略覆盖实例规格与本地 SSD 数据缓存、磁盘 IOPS 规划、连接池数学、代理 sidecar 资源预算与托管连接池Managed Connection Pooling并给出可直接套用的计算公式与部署命令。读完本文你将能根据目标 QPS 与数据集规模量化地为 Cloud SQL 存储层选择 tier、磁盘、连接数与 sidecar 配额避免 I/O 瓶颈与连接耗尽。前置阅读本文是 tools/setup-gcp/cloud-sql.md 中“Scaling the database”一节的纵深展开。该文档讲解了 Cloud SQL 实例的供给、IAM 数据库认证、代理 sidecar 注入与验证流程是理解本指南配置项来源的前提。本指南对应的完整文档为 docs/dev/cloud-sql-scaling-guide.md。什么时候需要开始扩容从“够用”到“I/O 受限”setup-gcp create cloudsql的供给默认值是db-custom-2-81922 vCPU / 8 GB 内存加 10 GB 磁盘适合开发环境与中等规模的 fleets见 tools/setup-gcp/cloud-sql.md 与 tools/setup-gcp/cmd/cloudsql.go 中的 flag 默认值。当 actor 数量上升后存储层会首先变成I/O-bound其物理机制是只要表与索引的**工作集working set**仍然小于实例内存所有点查询都由 shared buffers 缓存命中读延迟是微秒级一旦表 索引超过 RAM均匀随机读就开始大量落出缓存命中持久化磁盘的点查询point lookup要付出数毫秒的持久盘延迟p50 延迟随之劣化到磁盘延迟水平。因此本文所有旋钮都按性价比从高到低排序先加内存再上数据缓存然后规划磁盘最后精确计算连接数。实例规格内存是第一杠杆Enterprise Plus 解锁本地 SSD 数据缓存内存缓存工作集的主要手段配置方式创建时用--tier/--edition设置或在创建后用gcloud sql instances patch修改——注意edition/tier 变更会重启实例应在维护窗口执行。扩容判据读请求由缓存服务直到工作集表 索引超出 RAM一旦超出的数据量可观p50 延迟就会退化到磁盘延迟水平。所以第一步永远是观察“数据集大小 vs 内存大小”而不是盲目加 vCPU。Enterprise Plus 与本地 SSD 数据缓存当数据集在任何 tier 的 RAM 都无法容纳时切换到 Enterprise Plusgcloud sql instances patch instance --editionenterprise-plus --tierdb-perf-optimized-N-vCPUEnterprise Plus 只能搭配db-perf-optimized-N-vCPU系列 tierN为 vCPU 数该版本提供本地 SSD 数据缓存local-SSD data cache把有效缓存扩展到内存的若干倍那些本会穿透到持久盘的读请求改由本地 SSD 服务延迟远低于持久盘。从仓库源码可以印证这一设计意图。在 tools/setup-gcp/cmd/cloudsql.go 中cloudSQLInstanceSpec对 edition 做映射并开启数据缓存case , enterprise: // Enterprise edition accepts db-custom-vCPU-MB tiers. settings.Edition ENTERPRISE case enterprise-plus: // Enterprise Plus only accepts db-perf-optimized-N-vCPU tiers. Its // local-SSD data cache is the reason to pick it for this store: it // extends the effective cache beyond RAM once the dataset outgrows // memory (see cloud-sql.md, Scaling the database). settings.Edition ENTERPRISE_PLUS settings.DataCacheConfig sqladmin.DataCacheConfig{DataCacheEnabled: true}也就是说setup-gcp create cloudsql --editionenterprise-plus会在创建请求里同时设置ENTERPRISE_PLUS与DataCacheEnabled而对已存在实例则需手动gcloud sql instances patch工具不会 reconcile 已存在实例的形状见 tools/setup-gcp/cloud-sql.md 的说明。磁盘IOPS 随容量线性放大磁盘本身才是 I/O 旋钮配置方式创建时--storage-sizeGB指定之后磁盘只能增长不能缩小。关键事实持久化磁盘的 IOPS 与吞吐随预置容量provisioned size缩放——所以预置磁盘大小本质上是 I/O 能力的预算而不只是容量。最佳实践按预期数据集的约 2 倍预置记录 索引 WAL bloat不要依赖自动扩容auto-resize 按小步长增长批量加载时会造成停滞。源码同样印证了“预置而非自动扩容”的立场tools/setup-gcp/cmd/cloudsql.go// 0 leaves the Cloud SQL default (10 GB, auto-resizing). PD IOPS and // throughput scale with provisioned size, so benchmarks and production // should pre-size rather than rely on auto-resize. if cfg.CloudSQLStorageGB 0 { settings.DataDiskSizeGb cfg.CloudSQLStorageGB }连接池按目标吞吐反推连接数连接池在 ateapi 侧通过环境变量ATE_API_POSTGRES_POOL_MAX_CONNS配置部署期设置见 tools/setup-gcp/cloud-sql.md 的可选环境变量一节。它的默认值是max(4, NumCPU)——即取 4 与 vCPU 数二者较大者该值会被以pool_max_conns的形式追加到当前生效的 DSN 上合成的、集群内默认的或显式提供的 DSN 均可显式 DSN 中已有的pool_max_conns优先。相关逻辑位于 hack/install-ate.sh它会检查 DSN 是否已含pool_max_conns再决定追加还是替换。目标连接数公式目标连接数 吞吐量QPS× 平均查询延迟秒connections ≈ QPS × mean latency in seconds ≈ 10,000 req/s × 0.006 s ≈ 60 active connections预留约2 倍余量应对突发例如 4 个副本 ×ATE_API_POSTGRES_POOL_MAX_CONNS32。连接池过小不会报数据库错误而是在客户端侧pgx 内部排队等待连接——表现为请求延迟上升而非连接错误排障时容易被误判。必须保证所有副本的连接总数落在 Cloud SQL 的实例连接上限之内replicas × pool_max_conns ≤ max_connections − slacksuperuser、maintenance 等保留连接超过 max_connections 与“连接越多越好”的误区超过 Cloud SQL 的max_connections会直接报错FATAL: sorry, too many clients already。调整上限gcloud sql instances patch --database-flags…但该参数列表会整体替换所有 flags因此每次都必须重新带上cloudsql.iam_authenticationon否则会意外关闭 IAM 认证导致代理登录失败。超过“约 2 倍 vCPU 数”的活跃连接不会带来任何吞吐收益PostgreSQL 后端是 OS 进程多余的活跃连接只会互相上下文切换context-switch浪费 CPU。结论围绕公式算出的数字小幅扫掠sweep即可不要盲目最大化。源码侧佐证atepg 的池化实现与专用的 watch 池ateapi 的 PostgreSQL 存储实现在 cmd/ateapi/internal/store/atepg/atepg.go它基于pgxpool建立了两个独立的池主写池承载所有业务写入worker 状态、leases 等watch 池watch pool专用于 outbox 侧WatchWorkers 轮询与分区维护容量固定为 3watchPoolMaxConns 3最小 1见 atepg.go// watchPoolMaxConns sizes the dedicated outbox watch pool: one connection // for the WatchWorkers poller, one for the maintenance loop, and one of headroom // so a transiently slow poll can never gate a maintenance pass. const ( watchPoolMaxConns 3 watchPoolMinConns 1 )Connect会复制主池配置并覆写MaxConns/MinConns来构造 watch 池atepg.go。测试 cmd/ateapi/internal/store/atepg/outbox_test.go 也断言了watchPool.Config().MaxConns watchPoolMaxConns。这意味着即使你通过ATE_API_POSTGRES_POOL_MAX_CONNS把主池调得很大outbox 轮询也只占用每副本最多 3 条连接watchPoolMaxConns在计算replicas × pool_max_conns时应为每条副本额外预留这 3 条。此外atepg 的连接配置在每次新建连接时会重新解析 DSN 以读取最新 TLS 材料poolConfig的BeforeConnect见 atepg.go处理 kubelet 每日轮换 pod 证书的场景。代理 sidecar 资源CPU 随吞吐线性增长连接 churn 有独立上限Cloud SQL Auth Proxy 作为 native sidecarinitContainer restartPolicy: Always要求 Kubernetes 1.29注入ate-api-server部署其清单为 manifests/ate-install/cloudsql/proxy-sidecar-patch.yaml仅当设置ATE_API_POSTGRES_CLOUDSQL_INSTANCE时由 hack/install-ate.sh 应用。代理不施加连接数上限并只增加亚毫秒级延迟但它加密全部数据库流量TLS 1.3 隧道因此CPU 用量随吞吐线性增长补丁默认的资源请求为cpu: 100m、memory: 128Mi见 proxy-sidecar-patch.yaml这个配额是针对控制面流量规模设计的在持续每秒数千 ops的负载下需要调高 sidecar 的 CPU request避免节点压力把代理限流使它成为新的瓶颈。连接churn有独立的配额上限IAM 数据库登录按实例配额为12,000/min。对稳态的连接池来说无影响但如果大量副本同时重连reconnect storm可能触及该配额。Managed Connection Pooling用服务端池化解“副本太多”问题当 ateapi 副本非常多需要的真实后端连接达到数千条时使用 Cloud SQL 的托管连接池Managed Connection Pooling仅 Enterprise Plus 支持gcloud sql instances patch instance --enable-connection-pooling原理与参数服务端把最多max_client_connections默认 5,000条客户端连接复用multiplex到每个 databaseuser 对最多max_pool_size默认 50条后端连接上这是“很多 ateapi 副本本需要数千真实后端”场景的正解。当前仓库的一个重要限制该池化模式不能与 atepg 高效的transaction模式共存——worker-watch 路径使用LISTEN而 transaction pooling 不支持LISTENsession模式可以工作但会放弃大部分复用收益。这并非臆测atepg 的 WatchWorkers 确实通过轮询 事件流机制与数据库交互outbox 方案在 cmd/ateapi/internal/store/atepg/outbox.go 中有完整描述它依赖专用 watch 池对worker_outbox表做 xid 游标轮询并靠pg_postmaster_start_time与 trim 高水位检测重启与落后outbox.go。尽管当前实现走的是轮询而非LISTEN但连接复用/会话固定语义上的不兼容仍然成立——在使用托管连接池前务必评估 worker-watch 路径的会话要求。若启用托管连接池max_pool_size按前文公式的数字设置在max_connections中为 pooler预留约每 vCPU 15 条服务端连接。超出配置范畴分区是 schema 工程当单表行数达到数十亿行时运维极限不再是连接或 IOPS而是VACUUM 时长与单块大表上的索引维护成为操作瓶颈解决办法是把大表分区——这是 schema 层面的改造不是配置变更。仓库内部已经有一个可借鉴的实现范例atepg 的 worker outbox 表本身就是按created_at范围分区的15 分钟一个分区PARTITION BY RANGE (created_at)见迁移脚本 cmd/ateapi/internal/store/atepg/migrations/000001_initial.sql并配套后台维护循环outbox.go负责预创建分区、清理 stray DEFAULT 分区与按保留期 drop 过期分区drop 操作通过 advisory lock 在副本间选举单一执行者避免 AB/BA 死锁。对需要长期横向扩展的 ateapi 主表如 worker 状态历史可以参考这套模式设计你自己的分区与保留策略。扩容决策速查表关注点旋钮 / 命令关键数字内存第一杠杆--tier、--editiongcloud sql instances patch会重启工作集 ≤ RAM 时读延迟为微秒级数据集超出任何 tier 的 RAM--editionenterprise-plusdb-perf-optimized-N-vCPU本地 SSD 数据缓存把有效缓存扩展到内存数倍磁盘 IOPS/吞吐--storage-size只能增预置 ≈ 2× 数据集记录索引WALbloat连接池大小ATE_API_POSTGRES_POOL_MAX_CONNS默认max(4, NumCPU)connections ≈ QPS × mean latency再 ×2 余量实例连接上限gcloud sql instances patch --database-flags…整表替换需重带cloudsql.iam_authenticationonreplicas × pool_max_conns ≤ max_connections − slack活跃连接上限无配置项超过约 2× vCPUs 的活跃连接无吞吐收益代理 sidecar CPUproxy-sidecar-patch.yaml默认 100m数千 ops/s 需上调IAM 登录配额无配置项12,000/min/实例重连风暴需注意服务端池化--enable-connection-poolingEnterprise Plusmax_client_connections默认 5000max_pool_size默认 50预留 ~15 conn/vCPU数十亿行schema 分区工程参考 outbox 的 15 分钟分区 维护循环模式整体思路可以概括为一句话先让缓存接住读再用磁盘预置买 IOPS用公式而不是直觉定连接数最后在 schema 层解决单表极限——按这个顺序逐级推进即可让 ateapi 的 PostgreSQL 存储层随 actor 规模平滑扩展。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Agent Substrate 接入 Cloud SQL for PostgreSQL基于 Cloud SQL Auth Proxy 与 IAM 数据库认证的无密码存储后端实战指南Agent Substrate 接入 Cloud SQL for PostgreSQL基于 Cloud SQL Auth Proxy 与 IAM 数据库认证的人工智能AI AgentAgent 沙箱云原生容器运行时零信任Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测Substrate Benchmarking 实战指南用 Locust 与 OTel 对 Agent Substrate 做规模化压测 本篇技术指南围绕 Ag人工智能AI AgentAgent 沙箱云原生容器运行时零信任SMERF 实战指南基于可流式内存高效辐射场的实时大规模场景重建SMERF 实战指南基于可流式内存高效辐射场的实时大规模场景重建 SMERFStreamable Memory Efficient Radiance Fie人工智能深度学习NLP计算机视觉强化学习创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考