人工智能AI AgentAgent 沙箱云原生容器運(yùn)行時(shí)零信任【免費(fèi)下載鏈接】substrateAgent Substrate: the core system項(xiàng)目地址https://gitcode.com/GitHub_Trending/substrate7/substrate點(diǎn)擊查看免費(fèi)下載本指南聚焦 Agent Substrate 項(xiàng)目中 ateapi 的 PostgreSQL 存儲(chǔ)后端Cloud SQL for PostgreSQL在大規(guī)模 actor 數(shù)量與高請(qǐng)求速率下的容量規(guī)劃與擴(kuò)縮容策略覆蓋實(shí)例規(guī)格與本地 SSD 數(shù)據(jù)緩存、磁盤(pán) IOPS 規(guī)劃、連接池?cái)?shù)學(xué)、代理 sidecar 資源預(yù)算與托管連接池Managed Connection Pooling并給出可直接套用的計(jì)算公式與部署命令。讀完本文你將能根據(jù)目標(biāo) QPS 與數(shù)據(jù)集規(guī)模量化地為 Cloud SQL 存儲(chǔ)層選擇 tier、磁盤(pán)、連接數(shù)與 sidecar 配額避免 I/O 瓶頸與連接耗盡。前置閱讀本文是 tools/setup-gcp/cloud-sql.md 中“Scaling the database”一節(jié)的縱深展開(kāi)。該文檔講解了 Cloud SQL 實(shí)例的供給、IAM 數(shù)據(jù)庫(kù)認(rèn)證、代理 sidecar 注入與驗(yàn)證流程是理解本指南配置項(xiàng)來(lái)源的前提。本指南對(duì)應(yīng)的完整文檔為 docs/dev/cloud-sql-scaling-guide.md。什么時(shí)候需要開(kāi)始擴(kuò)容從“夠用”到“I/O 受限”setup-gcp create cloudsql的供給默認(rèn)值是db-custom-2-81922 vCPU / 8 GB 內(nèi)存加 10 GB 磁盤(pán)適合開(kāi)發(fā)環(huán)境與中等規(guī)模的 fleets見(jiàn) tools/setup-gcp/cloud-sql.md 與 tools/setup-gcp/cmd/cloudsql.go 中的 flag 默認(rèn)值。當(dāng) actor 數(shù)量上升后存儲(chǔ)層會(huì)首先變成I/O-bound其物理機(jī)制是只要表與索引的**工作集working set**仍然小于實(shí)例內(nèi)存所有點(diǎn)查詢都由 shared buffers 緩存命中讀延遲是微秒級(jí)一旦表 索引超過(guò) RAM均勻隨機(jī)讀就開(kāi)始大量落出緩存命中持久化磁盤(pán)的點(diǎn)查詢point lookup要付出數(shù)毫秒的持久盤(pán)延遲p50 延遲隨之劣化到磁盤(pán)延遲水平。因此本文所有旋鈕都按性價(jià)比從高到低排序先加內(nèi)存再上數(shù)據(jù)緩存然后規(guī)劃磁盤(pán)最后精確計(jì)算連接數(shù)。實(shí)例規(guī)格內(nèi)存是第一杠桿Enterprise Plus 解鎖本地 SSD 數(shù)據(jù)緩存內(nèi)存緩存工作集的主要手段配置方式創(chuàng)建時(shí)用--tier/--edition設(shè)置或在創(chuàng)建后用gcloud sql instances patch修改——注意edition/tier 變更會(huì)重啟實(shí)例應(yīng)在維護(hù)窗口執(zhí)行。擴(kuò)容判據(jù)讀請(qǐng)求由緩存服務(wù)直到工作集表 索引超出 RAM一旦超出的數(shù)據(jù)量可觀p50 延遲就會(huì)退化到磁盤(pán)延遲水平。所以第一步永遠(yuǎn)是觀察“數(shù)據(jù)集大小 vs 內(nèi)存大小”而不是盲目加 vCPU。Enterprise Plus 與本地 SSD 數(shù)據(jù)緩存當(dāng)數(shù)據(jù)集在任何 tier 的 RAM 都無(wú)法容納時(shí)切換到 Enterprise Plusgcloud sql instances patch instance --editionenterprise-plus --tierdb-perf-optimized-N-vCPUEnterprise Plus 只能搭配db-perf-optimized-N-vCPU系列 tierN為 vCPU 數(shù)該版本提供本地 SSD 數(shù)據(jù)緩存local-SSD data cache把有效緩存擴(kuò)展到內(nèi)存的若干倍那些本會(huì)穿透到持久盤(pán)的讀請(qǐng)求改由本地 SSD 服務(wù)延遲遠(yuǎn)低于持久盤(pán)。從倉(cāng)庫(kù)源碼可以印證這一設(shè)計(jì)意圖。在 tools/setup-gcp/cmd/cloudsql.go 中cloudSQLInstanceSpec對(duì) edition 做映射并開(kāi)啟數(shù)據(jù)緩存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}也就是說(shuō)setup-gcp create cloudsql --editionenterprise-plus會(huì)在創(chuàng)建請(qǐng)求里同時(shí)設(shè)置ENTERPRISE_PLUS與DataCacheEnabled而對(duì)已存在實(shí)例則需手動(dòng)gcloud sql instances patch工具不會(huì) reconcile 已存在實(shí)例的形狀見(jiàn) tools/setup-gcp/cloud-sql.md 的說(shuō)明。磁盤(pán)IOPS 隨容量線性放大磁盤(pán)本身才是 I/O 旋鈕配置方式創(chuàng)建時(shí)--storage-sizeGB指定之后磁盤(pán)只能增長(zhǎng)不能縮小。關(guān)鍵事實(shí)持久化磁盤(pán)的 IOPS 與吞吐隨預(yù)置容量provisioned size縮放——所以預(yù)置磁盤(pán)大小本質(zhì)上是 I/O 能力的預(yù)算而不只是容量。最佳實(shí)踐按預(yù)期數(shù)據(jù)集的約 2 倍預(yù)置記錄 索引 WAL bloat不要依賴自動(dòng)擴(kuò)容auto-resize 按小步長(zhǎng)增長(zhǎng)批量加載時(shí)會(huì)造成停滯。源碼同樣印證了“預(yù)置而非自動(dòng)擴(kuò)容”的立場(chǎng)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 }連接池按目標(biāo)吞吐反推連接數(shù)連接池在 ateapi 側(cè)通過(guò)環(huán)境變量ATE_API_POSTGRES_POOL_MAX_CONNS配置部署期設(shè)置見(jiàn) tools/setup-gcp/cloud-sql.md 的可選環(huán)境變量一節(jié)。它的默認(rèn)值是max(4, NumCPU)——即取 4 與 vCPU 數(shù)二者較大者該值會(huì)被以pool_max_conns的形式追加到當(dāng)前生效的 DSN 上合成的、集群內(nèi)默認(rèn)的或顯式提供的 DSN 均可顯式 DSN 中已有的pool_max_conns優(yōu)先。相關(guān)邏輯位于 hack/install-ate.sh它會(huì)檢查 DSN 是否已含pool_max_conns再?zèng)Q定追加還是替換。目標(biāo)連接數(shù)公式目標(biāo)連接數(shù) 吞吐量QPS× 平均查詢延遲秒connections ≈ QPS × mean latency in seconds ≈ 10,000 req/s × 0.006 s ≈ 60 active connections預(yù)留約2 倍余量應(yīng)對(duì)突發(fā)例如 4 個(gè)副本 ×ATE_API_POSTGRES_POOL_MAX_CONNS32。連接池過(guò)小不會(huì)報(bào)數(shù)據(jù)庫(kù)錯(cuò)誤而是在客戶端側(cè)pgx 內(nèi)部排隊(duì)等待連接——表現(xiàn)為請(qǐng)求延遲上升而非連接錯(cuò)誤排障時(shí)容易被誤判。必須保證所有副本的連接總數(shù)落在 Cloud SQL 的實(shí)例連接上限之內(nèi)replicas × pool_max_conns ≤ max_connections ? slacksuperuser、maintenance 等保留連接超過(guò) max_connections 與“連接越多越好”的誤區(qū)超過(guò) Cloud SQL 的max_connections會(huì)直接報(bào)錯(cuò)FATAL: sorry, too many clients already。調(diào)整上限gcloud sql instances patch --database-flags…但該參數(shù)列表會(huì)整體替換所有 flags因此每次都必須重新帶上cloudsql.iam_authenticationon否則會(huì)意外關(guān)閉 IAM 認(rèn)證導(dǎo)致代理登錄失敗。超過(guò)“約 2 倍 vCPU 數(shù)”的活躍連接不會(huì)帶來(lái)任何吞吐收益PostgreSQL 后端是 OS 進(jìn)程多余的活躍連接只會(huì)互相上下文切換context-switch浪費(fèi) CPU。結(jié)論圍繞公式算出的數(shù)字小幅掃掠sweep即可不要盲目最大化。源碼側(cè)佐證atepg 的池化實(shí)現(xiàn)與專用的 watch 池ateapi 的 PostgreSQL 存儲(chǔ)實(shí)現(xiàn)在 cmd/ateapi/internal/store/atepg/atepg.go它基于pgxpool建立了兩個(gè)獨(dú)立的池主寫(xiě)池承載所有業(yè)務(wù)寫(xiě)入worker 狀態(tài)、leases 等watch 池watch pool專用于 outbox 側(cè)WatchWorkers 輪詢與分區(qū)維護(hù)容量固定為 3watchPoolMaxConns 3最小 1見(jiàn) 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會(huì)復(fù)制主池配置并覆寫(xiě)MaxConns/MinConns來(lái)構(gòu)造 watch 池atepg.go。測(cè)試 cmd/ateapi/internal/store/atepg/outbox_test.go 也斷言了watchPool.Config().MaxConns watchPoolMaxConns。這意味著即使你通過(guò)ATE_API_POSTGRES_POOL_MAX_CONNS把主池調(diào)得很大outbox 輪詢也只占用每副本最多 3 條連接watchPoolMaxConns在計(jì)算replicas × pool_max_conns時(shí)應(yīng)為每條副本額外預(yù)留這 3 條。此外atepg 的連接配置在每次新建連接時(shí)會(huì)重新解析 DSN 以讀取最新 TLS 材料poolConfig的BeforeConnect見(jiàn) atepg.go處理 kubelet 每日輪換 pod 證書(shū)的場(chǎng)景。代理 sidecar 資源CPU 隨吞吐線性增長(zhǎng)連接 churn 有獨(dú)立上限Cloud SQL Auth Proxy 作為 native sidecarinitContainer restartPolicy: Always要求 Kubernetes 1.29注入ate-api-server部署其清單為 manifests/ate-install/cloudsql/proxy-sidecar-patch.yaml僅當(dāng)設(shè)置ATE_API_POSTGRES_CLOUDSQL_INSTANCE時(shí)由 hack/install-ate.sh 應(yīng)用。代理不施加連接數(shù)上限并只增加亞毫秒級(jí)延遲但它加密全部數(shù)據(jù)庫(kù)流量TLS 1.3 隧道因此CPU 用量隨吞吐線性增長(zhǎng)補(bǔ)丁默認(rèn)的資源請(qǐng)求為cpu: 100m、memory: 128Mi見(jiàn) proxy-sidecar-patch.yaml這個(gè)配額是針對(duì)控制面流量規(guī)模設(shè)計(jì)的在持續(xù)每秒數(shù)千 ops的負(fù)載下需要調(diào)高 sidecar 的 CPU request避免節(jié)點(diǎn)壓力把代理限流使它成為新的瓶頸。連接churn有獨(dú)立的配額上限IAM 數(shù)據(jù)庫(kù)登錄按實(shí)例配額為12,000/min。對(duì)穩(wěn)態(tài)的連接池來(lái)說(shuō)無(wú)影響但如果大量副本同時(shí)重連reconnect storm可能觸及該配額。Managed Connection Pooling用服務(wù)端池化解“副本太多”問(wèn)題當(dāng) ateapi 副本非常多需要的真實(shí)后端連接達(dá)到數(shù)千條時(shí)使用 Cloud SQL 的托管連接池Managed Connection Pooling僅 Enterprise Plus 支持gcloud sql instances patch instance --enable-connection-pooling原理與參數(shù)服務(wù)端把最多max_client_connections默認(rèn) 5,000條客戶端連接復(fù)用multiplex到每個(gè) databaseuser 對(duì)最多max_pool_size默認(rèn) 50條后端連接上這是“很多 ateapi 副本本需要數(shù)千真實(shí)后端”場(chǎng)景的正解。當(dāng)前倉(cāng)庫(kù)的一個(gè)重要限制該池化模式不能與 atepg 高效的transaction模式共存——worker-watch 路徑使用LISTEN而 transaction pooling 不支持LISTENsession模式可以工作但會(huì)放棄大部分復(fù)用收益。這并非臆測(cè)atepg 的 WatchWorkers 確實(shí)通過(guò)輪詢 事件流機(jī)制與數(shù)據(jù)庫(kù)交互outbox 方案在 cmd/ateapi/internal/store/atepg/outbox.go 中有完整描述它依賴專用 watch 池對(duì)worker_outbox表做 xid 游標(biāo)輪詢并靠pg_postmaster_start_time與 trim 高水位檢測(cè)重啟與落后outbox.go。盡管當(dāng)前實(shí)現(xiàn)走的是輪詢而非LISTEN但連接復(fù)用/會(huì)話固定語(yǔ)義上的不兼容仍然成立——在使用托管連接池前務(wù)必評(píng)估 worker-watch 路徑的會(huì)話要求。若啟用托管連接池max_pool_size按前文公式的數(shù)字設(shè)置在max_connections中為 pooler預(yù)留約每 vCPU 15 條服務(wù)端連接。超出配置范疇分區(qū)是 schema 工程當(dāng)單表行數(shù)達(dá)到數(shù)十億行時(shí)運(yùn)維極限不再是連接或 IOPS而是VACUUM 時(shí)長(zhǎng)與單塊大表上的索引維護(hù)成為操作瓶頸解決辦法是把大表分區(qū)——這是 schema 層面的改造不是配置變更。倉(cāng)庫(kù)內(nèi)部已經(jīng)有一個(gè)可借鑒的實(shí)現(xiàn)范例atepg 的 worker outbox 表本身就是按created_at范圍分區(qū)的15 分鐘一個(gè)分區(qū)PARTITION BY RANGE (created_at)見(jiàn)遷移腳本 cmd/ateapi/internal/store/atepg/migrations/000001_initial.sql并配套后臺(tái)維護(hù)循環(huán)outbox.go負(fù)責(zé)預(yù)創(chuàng)建分區(qū)、清理 stray DEFAULT 分區(qū)與按保留期 drop 過(guò)期分區(qū)drop 操作通過(guò) advisory lock 在副本間選舉單一執(zhí)行者避免 AB/BA 死鎖。對(duì)需要長(zhǎng)期橫向擴(kuò)展的 ateapi 主表如 worker 狀態(tài)歷史可以參考這套模式設(shè)計(jì)你自己的分區(qū)與保留策略。擴(kuò)容決策速查表關(guān)注點(diǎn)旋鈕 / 命令關(guān)鍵數(shù)字內(nèi)存第一杠桿--tier、--editiongcloud sql instances patch會(huì)重啟工作集 ≤ RAM 時(shí)讀延遲為微秒級(jí)數(shù)據(jù)集超出任何 tier 的 RAM--editionenterprise-plusdb-perf-optimized-N-vCPU本地 SSD 數(shù)據(jù)緩存把有效緩存擴(kuò)展到內(nèi)存數(shù)倍磁盤(pán) IOPS/吞吐--storage-size只能增預(yù)置 ≈ 2× 數(shù)據(jù)集記錄索引WALbloat連接池大小ATE_API_POSTGRES_POOL_MAX_CONNS默認(rèn)max(4, NumCPU)connections ≈ QPS × mean latency再 ×2 余量實(shí)例連接上限gcloud sql instances patch --database-flags…整表替換需重帶cloudsql.iam_authenticationonreplicas × pool_max_conns ≤ max_connections ? slack活躍連接上限無(wú)配置項(xiàng)超過(guò)約 2× vCPUs 的活躍連接無(wú)吞吐收益代理 sidecar CPUproxy-sidecar-patch.yaml默認(rèn) 100m數(shù)千 ops/s 需上調(diào)IAM 登錄配額無(wú)配置項(xiàng)12,000/min/實(shí)例重連風(fēng)暴需注意服務(wù)端池化--enable-connection-poolingEnterprise Plusmax_client_connections默認(rèn) 5000max_pool_size默認(rèn) 50預(yù)留 ~15 conn/vCPU數(shù)十億行schema 分區(qū)工程參考 outbox 的 15 分鐘分區(qū) 維護(hù)循環(huán)模式整體思路可以概括為一句話先讓緩存接住讀再用磁盤(pán)預(yù)置買(mǎi) IOPS用公式而不是直覺(jué)定連接數(shù)最后在 schema 層解決單表極限——按這個(gè)順序逐級(jí)推進(jìn)即可讓 ateapi 的 PostgreSQL 存儲(chǔ)層隨 actor 規(guī)模平滑擴(kuò)展。贊分享人工智能AI AgentAgent 沙箱云原生容器運(yùn)行時(shí)零信任【免費(fèi)下載鏈接】substrateAgent Substrate: the core system項(xiàng)目地址https://gitcode.com/GitHub_Trending/substrate7/substrate點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Agent Substrate 接入 Cloud SQL for PostgreSQL基于 Cloud SQL Auth Proxy 與 IAM 數(shù)據(jù)庫(kù)認(rèn)證的無(wú)密碼存儲(chǔ)后端實(shí)戰(zhàn)指南Agent Substrate 接入 Cloud SQL for PostgreSQL基于 Cloud SQL Auth Proxy 與 IAM 數(shù)據(jù)庫(kù)認(rèn)證的人工智能AI AgentAgent 沙箱云原生容器運(yùn)行時(shí)零信任Substrate Benchmarking 實(shí)戰(zhàn)指南用 Locust 與 OTel 對(duì) Agent Substrate 做規(guī)?；瘔簻y(cè)Substrate Benchmarking 實(shí)戰(zhàn)指南用 Locust 與 OTel 對(duì) Agent Substrate 做規(guī)模化壓測(cè) 本篇技術(shù)指南圍繞 Ag人工智能AI AgentAgent 沙箱云原生容器運(yùn)行時(shí)零信任SMERF 實(shí)戰(zhàn)指南基于可流式內(nèi)存高效輻射場(chǎng)的實(shí)時(shí)大規(guī)模場(chǎng)景重建SMERF 實(shí)戰(zhàn)指南基于可流式內(nèi)存高效輻射場(chǎng)的實(shí)時(shí)大規(guī)模場(chǎng)景重建 SMERFStreamable Memory Efficient Radiance Fie人工智能深度學(xué)習(xí)NLP計(jì)算機(jī)視覺(jué)強(qiáng)化學(xué)習(xí)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考