生产资源规格建议
- docker/docker-compose.yaml
- helm/octo/values.yaml
- docker/README.md
- 03-deployment-ops/基础设施依赖映射.md
- 02-architecture/OCTO全组件服务清单.md
- 基于行业通用经验推算（标注推算）
OCTO 生产资源规格建议 v1.0
⚠️ 重要声明：本文档资源规格中，凡标注"来源：xxx"的为官方配置文件硬提取值；凡标注"经验推算，待实际部署验证"的为基于官方默认值和行业通用经验推算，未经实际压测验证。官方未给出明确资源推荐值的部分已明确标注。实际部署前请根据业务场景压测调整。
§1 资源规划原则
1.1 资源消耗与用户规模的关系
| 因素 | 影响的组件 | 增长特征 |
|---|---|---|
| 在线并发用户数 | WuKongIM(长连接)、octo-server(API)、nginx | 近似线性增长 |
| 日消息量 | MySQL(写)、Redis(缓存)、WuKongIM(存储) | 线性增长，影响磁盘IO |
| 消息附件（图片/文件/语音） | MinIO(存储)、nginx(带宽) | 非线性，取决于附件使用率和平均大小 |
| 搜索索引（开启search时） | OpenSearch(内存/磁盘)、Kafka(磁盘) | 与消息总量正相关 |
| 文档/网盘文件（开启docs/drive时） | MinIO(存储)、docs-backend(CPU/内存)、Tika(CPU) | 非线性，取决于文档/文件数量和体积 |
| AI摘要/语音（开启summary/speech时） | summary-api/worker、octo-speech | CPU密集，受LLM API并发影响 |
来源：组件功能分析（OCTO全组件服务清单.md）+ 行业IM系统通用经验推算。
1.2 存储增长关键因素
- 消息文本：MySQL消息分表，单条消息约1-3KB（不含附件），增长缓慢。
- 消息附件：占存储增长的主要部分。图片/文件/语音消息存入MinIO，需预估人均日上传量。
- OpenSearch索引：消息全文索引，约为原始消息文本的1.5-3倍（含分词索引 overhead），经验推算待验证。
- 日志：nginx访问日志 + octo-server应用日志，建议配置日志轮转。
1.3 部署形态选择
- Docker Compose单机：适合 <200人规模或PoC评估，所有服务在一台主机。
- Kubernetes (Helm)：适合 ≥200人或需要高可用的场景，支持多副本和水平扩缩。
§2 用户规模档位定义
🔴 P1 Round3 PS-06纠偏（2026-09-22产品管家源码确认）：官方源码/部署文档中查无并发用户数、连接数上限、WuKongIM容量的任何数字。下表S/M/L/XL人数档位是本知识库自拟的经验推算，无官方证据支撑，不得对客户作为承诺口径报出。官方仅提供资源基线：Docker核心栈最小≥4GiB RAM+≥10GiB磁盘；开搜索再加OpenSearch~1GiB+Kafka~0.5-1GiB。售前报规模必须先做压测。
| 档位 | 注册用户(经验估算) | 日活(估) | 并发在线(估) | 日均消息量(估) | 典型场景 |
|---|---|---|---|---|---|
| S PoC/小团队 | <50人 | <30 | <20 | <5,000条 | 团队试用/评估 |
| M 中小团队 | 50-200人 | 30-120 | 20-80 | 5K-30K条 | 部门级协作 |
| L 中型企业 | 200-500人 | 120-300 | 80-200 | 30K-100K条 | 全公司部署 |
| XL 大型企业 | 500+人 | 300+ | 200+ | 100K+条 | 规模化/多Space |
注：🔴全部为经验推算，无官方证据，待实际部署压测验证。并发在线数按日活的60-70%估算，日均消息量按人均50-200条/天估算。实际值因使用强度差异很大。官方唯一确认的资源基线：docker/README.md最小4GiB RAM+10GiB磁盘（docker核心栈）；helm values.yaml server默认单副本requests 100m/256Mi limits 2C/2Gi。
§3 各档位资源规格表
3.1 总资源汇总
3.1.1 核心服务（必选，所有档位）
| 档位 | 总CPU核数 | 总内存 | 总磁盘(初始) | 部署形态建议 |
|---|---|---|---|---|
| S (经验档<50人) | 4核 | 8 GiB | 100 GiB SSD | Docker Compose单机 |
| M (经验档50-200人) | 8核 | 16 GiB | 200 GiB SSD | Docker Compose单机 或 K8s单节点 |
| L (经验档200-500人) | 16核 | 32 GiB | 500 GiB SSD | K8s 3节点起步 |
| XL (经验档500+人) | 32+核 | 64+ GiB | 1+ TiB SSD | K8s 5+节点，基础设施独立部署 |
总资源含OS开销，为经验推算，待实际部署验证。官方README给出的最低要求是≥4 GiB RAM、≥10 GiB空闲磁盘（来源：docker/README.md L169），但那是最低启动门槛，非生产规格。
3.1.2 可选Profile模块增量
| 模块 | S档增量 | M档增量 | L档增量 | XL档增量 | 说明 |
|---|---|---|---|---|---|
| summary (智能摘要) | +0.5核/+1GiB | +1核/+2GiB | +2核/+4GiB | +4核/+8GiB | LLM API调用为主，CPU开销在LLM响应处理 |
| speech (语音转写) | +0.5核/+1GiB | +1核/+2GiB | +2核/+4GiB | +4核/+8GiB | 音频处理；调云端ASR时本地CPU开销低 |
| docs (文档协同) | +0.5核/+1GiB | +1核/+2GiB | +2核/+4GiB | +4核/+8GiB | Hocuspocus WS长连接 + Yjs CRDT |
| drive (网盘) | +0.5核/+1GiB | +1核/+2GiB | +2核/+4GiB | +4核/+8GiB | 文件管理API，存储开销在MinIO |
| fleet (回路) | +0.5核/+1GiB/+10GiB磁盘(PG) | +1核/+2GiB/+20GiB | +2核/+4GiB/+50GiB | +4核/+8GiB/+100GiB | 独立PostgreSQL，Daemon管理 |
| search (搜索-OS+Kafka+indexer) | +2核/+3GiB/+40GiB磁盘 | +4核/+6GiB/+80GiB | +8核/+12GiB/+200GiB | +16核/+24GiB/+500GiB | OpenSearch内存消耗大 |
| doc-index (文档索引) | +0.3核/+0.5GiB | +0.5核/+1GiB | +1核/+2GiB | +2核/+4GiB | 轻量Kafka消费者 |
| drive-index (网盘索引+Tika) | +1核/+2GiB | +2核/+4GiB | +4核/+8GiB | +8核/+16GiB | Tika文本提取CPU密集 |
增量为经验推算，待实际部署验证。叠加多个模块时注意不是简单相加——部分基础设施（如Kafka）被多个indexer共享。
3.2 各服务CPU/内存明细
3.2.1 核心基础设施
| 服务 | S档 CPU/Mem | M档 CPU/Mem | L档 CPU/Mem | XL档 CPU/Mem | 来源/依据 |
|---|---|---|---|---|---|
| mysql | 0.5核 / 1GiB | 2核 / 4GiB | 4核 / 8GiB | 8核 / 16GiB | Helm默认resources未设置(resources: {})；S档值基于典型MySQL 8.0小部署推算，M/L/XL为经验推算待验证 |
| redis | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm默认resources未设置；S档值基于redis:7-alpine典型占用推算，经验推算待验证 |
| minio | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | 4核 / 8GiB | Helm默认resources未设置；MinIO内存主要受并发上传下载影响，经验推算待验证 |
| wukongim | 0.5核 / 512MiB | 1核 / 1GiB | 2核 / 2GiB | 4核 / 4GiB | Helm默认resources未设置；长连接数是主要因素，每万连接约耗1-2核(经验推算待验证) |
3.2.2 核心应用服务
| 服务 | S档 CPU/Mem | M档 CPU/Mem | L档 CPU/Mem | XL档 CPU/Mem | 来源/依据 |
|---|---|---|---|---|---|
| octo-server | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | 4核 / 8GiB | Helm默认: requests 100m/256Mi, limits 2/2Gi（来源：values.yaml server.resources）；S/M档符合默认limits，L/XL需调高limits为经验推算 |
| nginx | 0.2核 / 256MiB | 0.5核 / 512MiB | 1核 / 1GiB | 2核 / 2GiB | Helm默认resources未设置；nginx资源消耗低，主要受带宽和并发连接影响，经验推算待验证 |
| octo-web | 0.2核 / 256MiB | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | Helm默认resources未设置；SPA静态资源服务+厚路由nginx，消耗低，经验推算待验证 |
| octo-admin | 0.1核 / 128MiB | 0.2核 / 256MiB | 0.5核 / 512MiB | 1核 / 1GiB | Helm默认resources未设置；管理后台使用频率低，经验推算待验证 |
| octo-matter | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm默认: requests 100m/256Mi, limits 2/2Gi（来源：values.yaml matter.resources）；含LLM API调用 |
| marketplace | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 1核 / 2GiB | Helm默认: requests 100m/256Mi, limits 1/1Gi（来源：values.yaml marketplace.resources） |
3.2.3 可选Profile应用服务
| 服务 | S档 CPU/Mem | M档 CPU/Mem | L档 CPU/Mem | XL档 CPU/Mem | 来源/依据 |
|---|---|---|---|---|---|
| summary-api | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm默认resources未设置（resources: {}）；经验推算待验证 |
| summary-worker | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm默认resources未设置；异步LLM调用，经验推算待验证 |
| octo-speech | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm默认: requests 100m/256Mi, limits 2/2Gi（来源：values.yaml speech.resources） |
| speech-admin | 0.1核 / 256MiB | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | Helm默认: requests 50m/128Mi, limits 1/512Mi（来源：values.yaml speech.admin.resources） |
| octo-docs-backend | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm默认: requests 100m/256Mi, limits 1/1Gi（来源：values.yaml docs.resources）；Hocuspocus WS+Yjs CRDT |
| octo-drive | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm values.yaml中未包含drive配置（官方未提供推荐值）；经验推算待验证 |
| octo-fleet | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | Helm values.yaml中未包含fleet配置（官方未提供推荐值）；经验推算待验证 |
| fleet-postgres | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | 镜像postgres:16-alpine，经验推算待验证 |
3.2.4 搜索管线服务（search profile）
| 服务 | S档 CPU/Mem | M档 CPU/Mem | L档 CPU/Mem | XL档 CPU/Mem | 来源/依据 |
|---|---|---|---|---|---|
| search-opensearch | 1核 / 2GiB | 2核 / 4GiB | 4核 / 8GiB | 8核 / 16GiB | Helm默认: requests 500m/1Gi, limits 2/2Gi, JVM -Xms512m -Xmx512m（来源：values.yaml search.opensearch）；S/M档符合默认limits，L/XL需调高JVM堆（经验推算）。docker-compose JVM默认-Xms512m -Xmx512m（来源：docker-compose.yaml L1539） |
| search-kafka | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | 4核 / 8GiB | Helm默认: requests 250m/512Mi, limits 1/1Gi（来源：values.yaml search.kafka.resources） |
| es-indexer | 0.2核 / 256MiB | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | Helm默认: requests 100m/128Mi, limits 500m/512Mi（来源：values.yaml search.indexer.resources） |
| search-producer | 0.2核 / 256MiB | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | Helm默认: requests 100m/128Mi, limits 500m/512Mi（来源：values.yaml search.producer.resources）；注意K8s路径用独立producer，Docker Compose默认用octo-server内置producer |
| doc-indexer | 0.1核 / 256MiB | 0.2核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | Helm values.yaml中未包含docIndexer resources（官方未提供推荐值）；轻量消费者，经验推算待验证 |
| drive-indexer | 0.2核 / 256MiB | 0.3核 / 512MiB | 0.5核 / 1GiB | 1核 / 2GiB | Helm values.yaml中未包含driveIndexer resources（官方未提供推荐值）；经验推算待验证 |
| tika | 0.5核 / 1GiB | 1核 / 2GiB | 2核 / 4GiB | 4核 / 8GiB | Apache Tika文本提取，CPU密集型，官方未提供推荐值，经验推算待验证 |
3.3 K8s副本数建议
| 服务 | S档 | M档 | L档 | XL档 | 依据 |
|---|---|---|---|---|---|
| octo-server | 1 | 2 | 2-3 | 3+ | Helm默认replicas: 1（来源：values.yaml server.replicas）；多副本可提升可用性，octo-server无状态 |
| octo-web | 1 | 1-2 | 2 | 2+ | Helm默认: 1；SPA静态服务，可多副本 |
| octo-admin | 1 | 1 | 1 | 2 | Helm默认: 1；低频使用，单副本足够 |
| octo-matter | 1 | 1-2 | 2 | 2+ | Helm默认: 1 |
| marketplace | 1 | 1 | 1-2 | 2 | Helm默认: 1（且默认enabled: false） |
| nginx | 1 | 2 | 2 | 3+ | Helm无显式replicaCount配置；作为入口建议至少2副本 |
| mysql | 1 | 1 | 1(主从) | 1(主从/MGR) | 有状态服务，S/M档单实例；L档起建议主从，经验推算 |
| redis | 1 | 1 | 1(Sentinel) | 3(Cluster) | 有状态服务，经验推算 |
| minio | 1 | 1 | 1(分布式) | 4+(分布式) | Helm默认单实例；L档起建议分布式模式，经验推算 |
| wukongim | 1 | 1 | 2(集群) | 3+(集群) | 有状态长连接服务，集群需WuKongIM集群支持，经验推算待验证 |
| summary-api | 1 | 1 | 2 | 2+ | Helm默认: 1 |
| summary-worker | 1 | 1 | 2 | 2+ | Helm默认: 1 |
| octo-speech | 1 | 1 | 2 | 2+ | Helm默认: 1 |
| octo-docs-backend | 1 | 1 | 2 | 2+ | Helm默认: 1；Hocuspocus多副本需注意WS粘性 |
| octo-drive | 1 | 1 | 2 | 2+ | 官方未提供推荐值，经验推算 |
| octo-fleet | 1 | 1 | 2 | 2+ | 官方未提供推荐值，经验推算 |
| search-opensearch | 1 | 1 | 3 | 3+ | Helm默认单节点；L档起建议3节点集群(含副本分片)，经验推算 |
| search-kafka | 1 | 1 | 3 | 3+ | Helm默认单KRaft节点；L档起建议3节点KRaft集群，经验推算 |
| es-indexer | 1 | 1 | 2 | 3+ | Helm无显式replicaCount；消费组可水平扩展 |
副本数≥2的建议均为经验推算，待实际部署验证。数据库/消息队列/搜索引擎的集群化需要额外配置，不是简单增加replica数。
3.4 JVM堆大小建议（OpenSearch）
| 档位 | JVM堆(-Xms/-Xmx) | 配置方式 | 依据 |
|---|---|---|---|
| S | -Xms512m -Xmx512m | docker: OCTO_SEARCH_OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512mhelm: search.opensearch.javaOpts: "-Xms512m -Xmx512m" |
来源：docker-compose.yaml L1539 + values.yaml默认值 |
| M | -Xms1g -Xmx1g | docker: OCTO_SEARCH_OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1ghelm: search.opensearch.javaOpts: "-Xms1g -Xmx1g" |
经验推算：消息量增大需更大堆，建议堆内存不超过容器内存的50% |
| L | -Xms2g -Xmx2g | 同上，调整值 | 经验推算，待验证 |
| XL | -Xms4g -Xmx4g 或更高 | 同上 | 经验推算，待验证。OpenSearch官方建议堆不超过32GB（压缩指针阈值） |
OpenSearch官方最佳实践：JVM堆内存设置为可用内存的50%（预留另一半给文件系统缓存），且不超过32GB。
Kafka运行在JVM上但helm values.yaml未显式配置KAFKA_HEAP_OPTS，Kafka 3.8默认堆为1GB（Kafka默认启动脚本）。M/L/XL档建议设置`KAFKA_HEAP_OPTS="-Xms1g -Xmx1g"`或更高，经验推算待验证。
§4 磁盘容量规划
4.1 Docker Compose命名卷与Helm PVC对照
| 卷/PVC | Helm默认Storage Size | S档建议 | M档建议 | L档建议 | XL档建议 | 增长因素 |
|---|---|---|---|---|---|---|
| 系统盘(OS+Docker镜像) | — | 50 GiB | 100 GiB | 100 GiB/节点 | 100 GiB/节点 | Docker镜像约5-10GB(全模块)，系统+日志 |
| mysql-data | 20 GiB（来源：values.yaml mysql.storage.size） | 30 GiB | 50 GiB | 100 GiB | 200+ GiB | 消息数据增长：约1-3KB/条文本消息；附件元数据+索引。建议预留至少3个月数据量 |
| redis-data | 10 GiB（来源：values.yaml redis.storage.size） | 10 GiB | 10 GiB | 20 GiB | 50 GiB | Redis主要是缓存和会话队列，增长有限；bot_task队列和搜索cursor占少量空间 |
| minio-data | 50 GiB（来源：values.yaml minio.storage.size） | 50 GiB | 100 GiB | 300 GiB | 1+ TiB | 最大增长项：消息附件(图片/文件/语音)、头像、贴纸、文档附件、网盘文件、市场资源。取决于用户附件使用强度 |
| wukongim-data | 10 GiB（来源：values.yaml wukongim.storage.size） | 10 GiB | 20 GiB | 50 GiB | 100+ GiB | WuKongIM消息/通道/离线消息存储；增长与消息量正相关 |
| opensearch-data | 20 GiB（来源：values.yaml search.opensearch.storage.size） | 20 GiB | 50 GiB | 100 GiB | 300+ GiB | 搜索索引：约为原始文本的1.5-3倍；文档/网盘索引额外增大；经验推算待验证 |
| kafka-data | 10 GiB（来源：values.yaml search.kafka.storage.size） | 10 GiB | 20 GiB | 50 GiB | 100 GiB | Kafka日志保留（默认7天？需确认）；消费后可清理，但需保留峰值余量 |
| server-logs/nginx-logs | — | 10 GiB | 20 GiB | 50 GiB | 100 GiB | 日志增长，建议配置logrotate轮转保留7-30天；经验推算 |
| speech storage | 10 GiB（来源：values.yaml speech.storage.size） | 10 GiB | 20 GiB | 50 GiB | 100 GiB | 语音消息音频文件（如开启语音存储）；如语音消息通过MinIO存储则可能重复计算 |
| fleet-postgres-data | —（helm未含fleet） | 10 GiB | 20 GiB | 50 GiB | 100 GiB | Fleet回路业务数据；经验推算待验证 |
| search-dlq-spill | 1 GiB（来源：values.yaml search.indexer.dlqSpill.size） | 1 GiB | 2 GiB | 5 GiB | 10 GiB | DLQ spill持久化，增长有限 |
| search-backfill-state | — | 1 GiB | 1 GiB | 2 GiB | 5 GiB | search-tools profile回填状态持久化；经验推算待验证 |
Helm默认PVC大小为官方初始配置值，仅适用于PoC/S档。M/L/XL档磁盘建议为经验推算，待实际部署验证。
4.2 MinIO存储增长估算
| 数据类型 | 单条估算大小 | 月增长估算（100人活跃） | 说明 |
|---|---|---|---|
| 聊天图片 | 100KB-2MB | 5-20 GiB/月 | 取决于截图/照片频率 |
| 文件附件 | 100KB-50MB | 10-100 GiB/月 | 波动最大，取决于文件传输频率 |
| 语音消息 | 30KB-500KB(60s) | 1-5 GiB/月 | 3MB/60s上限（来源：VOICE_MAX_FILE_SIZE=3MB） |
| 头像/贴纸/聊天背景 | <100KB/个 | <1 GiB/月 | 可设上限，增长极慢 |
| 文档附件(octo-docs-attachments) | 取决于文档 | 5-50 GiB/月 | 启用docs后才有 |
| 网盘文件(octo-drive) | 无上限 | 10-500+ GiB/月 | 启用drive后，增长不可预测，建议设置配额 |
| 市场资源(marketplace) | 技能ZIP≤20MiB | <1 GiB/月 | MAX_UPLOAD_MB=20（来源：marketplace配置） |
⚠️ 以上增长估算为经验推算，待实际部署验证。文件附件类数据波动极大，强烈建议：
1. 部署前预估用户附件使用习惯
2. 设置MinIO存储告警（使用率>70%告警）
3. 网盘模块建议配置用户/Space存储配额
4. 定期清理过期临时文件
4.3 MySQL数据增长估算
| 数据类型 | 单条大小 | 月增长（100人，日均1万消息） |
|---|---|---|
| 文本消息 | 1-3KB | 1-3 GiB/月 |
| 系统消息/通知 | <1KB | <500 MiB/月 |
| 用户/群组/Bot元数据 | — | <100 MiB/月（几乎不增长） |
| Matter任务数据 | — | <500 MiB/月 |
经验推算待验证。消息分表（message, message1-4），每张表建议不超过1000万行。
4.4 OpenSearch索引增长估算
| 索引 | 估算方式 | 月增长（100人，日均1万消息） |
|---|---|---|
| octo-message | 原始文本×2-3倍 | 2-9 GiB/月 |
| octo-doc（启用doc-index） | 取决于文档数量和大小 | 5-50 GiB/月 |
| octo-drive（启用drive-index） | Tika提取文本+元数据 | 10-100+ GiB/月 |
经验推算待验证。OpenSearch索引可设置ILM(Index Lifecycle Management)策略自动过期旧数据。
§5 网络带宽建议
| 档位 | 上行带宽建议 | 下行带宽建议 | 说明 |
|---|---|---|---|
| S (<50人) | 10 Mbps | 50 Mbps | 可共享普通办公带宽 |
| M (50-200人) | 50 Mbps | 100 Mbps | 建议独立带宽或QoS保障 |
| L (200-500人) | 100 Mbps | 500 Mbps | 需独立带宽，文件上传下载是带宽消耗主力 |
| XL (500+人) | 500+ Mbps | 1+ Gbps | 建议CDN加速静态资源和文件下载 |
经验推算，待实际部署验证。带宽主要消耗在：
- 消息附件上传/下载（走MinIO，经nginx代理）
- 语音消息上传/下载
- WebSocket长连接（文本消息流量小，可忽略）
- 文档/网盘文件传输（启用docs/drive时增加）
如使用外部对象存储（COS/OSS/S3）而非内置MinIO，则文件流量不经OCTO服务器，带宽需求大幅降低。
网络要求（来源：docker/README.md L170）：需出站网络访问docker.io（或配置镜像mirror）拉取镜像。
§6 Docker Compose单机各档位配置建议
6.1 S档（<50人，4核8GB）
6.2 M档（50-200人，8核16GB）
# 示例：在关键服务下添加deploy.resources（经验推算，待验证）
services:
mysql:
deploy:
resources:
limits:
cpus: '2.0'
memory: 4G
reservations:
cpus: '0.5'
memory: 1G
octo-server:
deploy:
resources:
limits:
cpus: '2.0'
memory: 2G
# OpenSearch堆调大
search-opensearch:
environment:
OPENSEARCH_JAVA_OPTS: "-Xms1g -Xmx1g" # 从默认512m调大到1g⚠️ Docker Compose的`deploy.resources`仅在Docker Swarm模式下生效；非Swarm模式需使用`mem_limit`/`cpus`等旧版参数或通过宿主机cgroup手动限制。经验推算待验证。
6.3 L档（200-500人，16核32GB）
- MySQL/Redis/MinIO考虑使用外部托管服务（云RDS/云Redis/对象存储）
- OpenSearch JVM堆设为
-Xms2g -Xmx2g - 宿主机ulimit调大：
vm.max_map_count=262144（OpenSearch要求）
6.4 系统调优（所有档位）
# OpenSearch要求（来源：docker-compose.yaml ulimits注释）
sudo sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
# 文件描述符（OpenSearch nofile已设65536）
sudo sysctl -w fs.file-max=65536
ulimit -n 65536
# Docker日志限制（防止磁盘写满）
# 在/etc/docker/daemon.json中配置：
{
"log-driver": "json-file",
"log-opts": {"max-size": "100m", "max-file": "3"}
}来源：docker-compose.yaml search-opensearch ulimits配置(nofile soft:65536) + OpenSearch官方vm.max_map_count要求。
§7 K8s Helm各档位values.yaml修改参考
7.1 S档（默认值即可，PoC/小团队）
- server: requests 100m/256Mi, limits 2/2Gi
- matter: requests 100m/256Mi, limits 2/2Gi
- speech: requests 100m/256Mi, limits 2/2Gi
- speech-admin: requests 50m/128Mi, limits 1/512Mi
- docs: requests 100m/256Mi, limits 1/1Gi
- marketplace: requests 100m/256Mi, limits 1/1Gi
- search.opensearch: requests 500m/1Gi, limits 2/2Gi
- search.kafka: requests 250m/512Mi, limits 1/1Gi
- search.indexer: requests 100m/128Mi, limits 500m/512Mi
- search.producer: requests 100m/128Mi, limits 500m/512Mi
- mysql: 20Gi, redis: 10Gi, minio: 50Gi, wukongim: 10Gi, speech: 10Gi
- search.opensearch: 20Gi, search.kafka: 10Gi, search.dlqSpill: 1Gi
7.2 M档（50-200人）修改示例
# values-m.yaml 经验推算，待验证
server:
replicas: 2
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: "2"
memory: 2Gi
matter:
replicas: 1
mysql:
storage:
size: 50Gi
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: "2"
memory: 4Gi
redis:
storage:
size: 10Gi
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: "1"
memory: 2Gi
minio:
storage:
size: 100Gi
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: "2"
memory: 2Gi
wukongim:
storage:
size: 20Gi
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: "2"
memory: 2Gi
search:
opensearch:
javaOpts: "-Xms1g -Xmx1g"
storage: { size: 50Gi }
resources:
requests: { cpu: 1, memory: 2Gi }
limits: { cpu: "2", memory: 4Gi }
kafka:
storage: { size: 20Gi }
resources:
requests: { cpu: 500m, memory: 1Gi }
limits: { cpu: "1", memory: 2Gi }
nginx:
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: "1"
memory: 512Mi以上修改为经验推算，待实际部署验证。未列出的服务保持默认值即可。
7.3 L档（200-500人）修改要点
- octo-server replicas: 2-3，limits提高到4核/4Gi
- OpenSearch JVM堆调至
-Xms2g -Xmx2g，PVC: 100Gi - Kafka PVC: 50Gi
- MinIO PVC: 300Gi
- MySQL PVC: 100Gi，考虑主从架构
- 基础设施（mysql/redis/minio）强烈建议迁移到云托管服务
- 配置HPA(HorizontalPodAutoscaler)基于CPU/内存自动扩缩
以上为经验推算，待实际部署验证。L档建议进行专项压测后确定最终规格。
7.4 XL档（500+人）修改要点
- 所有应用服务replicas≥2，关键服务≥3
- OpenSearch 3节点集群，JVM堆4-8GB
- Kafka 3节点KRaft集群
- MySQL主从或MGR集群
- MinIO分布式模式（4节点起步）
- 基础设施独立部署（不与应用混部）
- 考虑读写分离、分库分表
- 全链路压测后确定规格
经验推算，待实际部署验证。XL档必须经过专项压测，本文数字仅作初始参考。
§8 扩容触发指标
以下指标和阈值均为经验推算，待实际部署验证，建议结合监控系统实际数据调整。
8.1 扩容触发条件
| 指标 | 关注组件 | 扩容阈值 | 扩什么 |
|---|---|---|---|
| CPU使用率持续 >70% | octo-server/matter/summary | 5分钟以上 | 增加应用副本数或提高limits |
| 内存使用率持续 >80% | octo-server/OpenSearch | 5分钟以上 | 提高内存limits；OpenSearch调JVM堆 |
| MySQL连接数接近上限 | mysql | >80% max_connections | 优化连接池/读副本/分库 |
| MySQL慢查询增多 | mysql | 慢查询>10/min | 加索引/读副本/分库分表 |
| Redis内存使用率 >80% | redis | 持续 | 扩容内存/配置淘汰策略 |
| MinIO磁盘使用率 >70% | minio | — | 扩容磁盘/加节点/清理过期数据 |
| WuKongIM连接数接近上限 | wukongim | 单节点>5000连接 | WuKongIM集群化 |
| OpenSearch查询延迟 >500ms | search-opensearch | P95>500ms | 扩容OS节点/调JVM堆/优化索引 |
| Kafka消费延迟(lag)持续增长 | search-kafka/es-indexer | lag>10000条持续增长 | 增加indexer副本/扩容Kafka |
| 磁盘使用率 >80% | 所有PVC | — | 扩容磁盘（MySQL/MinIO/OS优先） |
| WebSocket连接异常/消息延迟 | wukongim/nginx | 用户反馈消息延迟 | 检查资源瓶颈，扩容wukongim/nginx |
| HTTP 5xx错误率 >1% | nginx/octo-server | 持续1分钟 | 检查后端服务状态，可能需要扩容 |
8.2 必配监控项
| 组件 | 核心监控指标 |
|---|---|
| 主机 | CPU/内存/磁盘使用率/磁盘IO/网络IO |
| 容器 | 各容器CPU/内存/重启次数 |
| MySQL | QPS/TPS/连接数/慢查询/复制延迟/InnoDB缓冲命中率 |
| Redis | 内存使用率/连接数/命中率/key数量 |
| MinIO | 磁盘使用率/请求延迟/流量 |
| WuKongIM | 在线连接数/消息投递延迟 |
| octo-server | 请求QPS/P95延迟/错误率/goroutine数量 |
| OpenSearch | 查询延迟/索引速率/JVM堆使用率/磁盘使用率 |
| Kafka | 消息生产/消费速率/consumer lag/磁盘使用率 |
| nginx | 请求QPS/活跃连接数/5xx率/流量 |
官方未提供具体监控方案和Grafana模板，以上为通用监控最佳实践推算。
§9 已知约束和待验证项清单
9.1 官方未提供推荐值的项
| 项 | 说明 |
|---|---|
| Docker Compose无资源限制 | docker-compose.yaml中没有任何deploy.resources.limits/reservations配置，所有服务无资源约束（来源：docker-compose.yaml全文grep） |
| MySQL/Redis/MinIO/WuKongIM/Web/Admin/Nginx Helm resources为空 | resources: {}，官方未设默认CPU/内存请求和限制（来源：values.yaml） |
| Summary-api/worker Helm resources为空 | resources: {}（来源：values.yaml summary） |
| 官方最低配置仅含RAM和磁盘 | docker/README.md仅给出"≥4 GiB RAM, ≥10 GiB free disk"最低启动要求（来源：docker/README.md L169），未给生产推荐 |
| fleet/drive Helm配置缺失 | values.yaml中未包含fleet和drive的resources/storage配置（官方未提供推荐值） |
| doc-indexer/drive-indexer/tika资源配置 | helm values中未包含这些服务的resources配置（官方未提供推荐值） |
| Kafka JVM堆配置 | docker-compose.yaml和values.yaml均未显式设置KAFKA_HEAP_OPTS |
9.2 待验证项
| 项 | 风险 | 验证方式 |
|---|---|---|
| S/M/L/XL档位的CPU/内存具体数值 | 配置不足导致OOM或性能问题；配置过高浪费资源 | 按档位搭建环境压测（建议用消息发送脚本模拟并发） |
| 磁盘增长速率 | MinIO磁盘写满导致服务不可用 | 上线后首月密切监控磁盘增长曲线 |
| OpenSearch JVM堆与数据量的关系 | 堆过小导致OOM或查询慢；堆过大浪费资源 | 按数据量逐步调整，监控GC和查询延迟 |
| WuKongIM单节点连接数上限 | 连接数过多导致wukongim不稳定 | 逐步增加并发连接数压测 |
| octo-server单实例最大并发 | 不知道单实例能承载多少QPS | API压测（消息发送/文件上传/WS连接） |
| Kafka单节点吞吐上限 | 消息量大时Kafka成为瓶颈 | 消息生产/消费压测 |
| MySQL单表承载上限 | 消息分表(5张)在大数据量下性能 | 插入千万级行测试查询性能 |
| 多副本下WebSocket粘性会话 | octo-docs-backend Hocuspocus多副本WS是否需要粘性 | 多副本部署测试协同编辑 |
| K8s环境下docker-compose已有profile但helm未覆盖 | fleet/drive/docs-html/doc-index/drive-index在helm中未完整配置 | 确认helm chart版本是否包含这些服务 |
| 语音/摘要模块LLM API并发限制 | 第三方LLM API可能有QPS/RPM限制 | 根据LLM提供商配额调整副本数 |
9.3 部署前检查清单
- [ ] 根据用户规模档位选定服务器配置（参考§3）
- [ ] 预留足够磁盘空间，尤其是MinIO存储（参考§4）
- [ ] 配置Docker/K8s日志轮转，防止日志写满磁盘
- [ ] 设置OpenSearch所需的
vm.max_map_count=262144 - [ ] 如需HTTPS，准备TLS证书和反向代理配置
- [ ] 配置监控告警（CPU/内存/磁盘/服务健康状态）
- [ ] 规划备份策略（MySQL/MinIO/OpenSearch数据备份）
- [ ] 修改所有默认密码和Token（preflight服务会拦截CHANGE_ME占位符）
- [ ] 如启用search profile，按runbook完成backfill和alias绑定
- [ ] 生产环境务必设置MinIO/MySQL/WuKongIM端口绑定为非0.0.0.0（默认已loopback，来源：docker-compose.yaml端口配置）
附录A：数据来源索引
| 数据项 | 来源文件 | 具体位置 | |
|---|---|---|---|
| 最低配置要求(4GiB/10GB) | docker/README.md | L169 | |
| Search profile资源基线 | docker/README.md | L1664-1679 (OpenSearch~1GiB, Kafka~0.5-1GiB, indexer~50-100MiB) | |
| OpenSearch JVM默认值 | docker/docker-compose.yaml | L1539 (OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m) | |
| OpenSearch ulimits | docker/docker-compose.yaml | L1546-1551 (memlock:-1, nofile:65536) | |
| Helm server resources | helm/octo/values.yaml | L313-319 (100m/256Mi → 2/2Gi) | |
| Helm matter resources | helm/octo/values.yaml | L408-414 (100m/256Mi → 2/2Gi) | |
| Helm speech resources | helm/octo/values.yaml | L468-474 (100m/256Mi → 2/2Gi) | |
| Helm speech-admin resources | helm/octo/values.yaml | L486-492 (50m/128Mi → 1/512Mi) | |
| Helm docs resources | helm/octo/values.yaml | L523-529 (100m/256Mi → 1/1Gi) | |
| Helm marketplace resources | helm/octo/values.yaml | L552-558 (100m/256Mi → 1/1Gi) | |
| Helm OpenSearch resources | helm/octo/values.yaml | L584-586 (500m/1Gi → 2/2Gi, JVM 512m) | |
| Helm Kafka resources | helm/octo/values.yaml | L594-596 (250m/512Mi → 1/1Gi) | |
| Helm indexer resources | helm/octo/values.yaml | L601-603 (100m/128Mi → 500m/512Mi) | |
| Helm producer resources | helm/octo/values.yaml | L632-634 (100m/128Mi → 500m/512Mi) | |
| Helm PVC默认大小 | helm/octo/values.yaml | mysql:20Gi, redis:10Gi, minio:50Gi, wukongim:10Gi, opensearch:20Gi, kafka:10Gi | |
| Docker Compose无deploy.resources | docker/docker-compose.yaml | 全文grep无`deploy:\ | resources:`段（搜索服务段除外，OS仅有ulimits） |
| MinIO bucket清单 | 基础设施依赖映射.md | §三（13个bucket） | |
| MySQL数据库清单 | 基础设施依赖映射.md | §一（octo/octo_matter/octo_summary/octo_speech/octo_docs/octo_marketplace/octo_drive） | |
| Named volumes清单 | 基础设施依赖映射.md | §六（10个核心卷 + fleet-postgres-data + drive-config） | |
| 服务清单与端口 | OCTO全组件服务清单.md | 全文 |