2G 内存的服务器别碰 Gauzy？资源门槛实测与调优方案

2G 内存的服务器别碰 Gauzy资源门槛实测与调优方案【免费下载链接】ever-gauzyEver® Gauzy™ - Open Business Management Platform (ERP/CRM/HRM/ATS/PM) - https://gauzy.co项目地址: https://gitcode.com/GitHub_Trending/ev/ever-gauzy2G 内存的 VPS 能跑 Gauzy 吗——这个问题几乎出现在每一篇 Ever Gauzy 部署教程的评论区。一边是官方 README 里那份看起来无比豪华的依赖清单PostgreSQL、Redis、OpenSearch、MinIO、Jitsu、Cube、Zipkin……一边是中小企业手里最常见的 2G/4G 入门云服务器。结论很分裂有人说docker compose up 直接 OOM也有人用 2G 机器把整套 ERP 跑了起来。真实情况是Gauzy 的资源门槛不是一道单选题而是一套由部署形态决定的组合题。本文不打算空谈而是直接回到仓库源码从 docker-compose.yml、docker-compose.infra.yml、官方 K8s 资源清单和核心模块的缓存/队列实现出发拆解 PostgreSQL、Redis、API 各自的真实内存画像最后给出 2G/4G/8G 三档可行的降配方案。一、资源门槛的真相全家桶 vs 最小集先看官方对部署形态的定位。在 README.md 中写得很直白while demodocker-compose.demo.ymlruns a minimum amount of containers (API, Web UI, and DB), other Docker Compose files run multiple infrastructure dependencies也就是说Gauzy 官方同时提供了两种截然不同的 Compose 栈。绝大多数人踩的坑是把生产版 docker-compose.yml它通过include引入了 docker-compose.infra.yml直接当成默认安装跑起来。我们来数一下这套全家桶到底拉起多少个容器组件镜像内存画像源码可见apigauzy-apiNode.js/NestJS主力占用官方 K8s 请求 896Miwebappgauzy-webappnginx 静态极低官方 K8s 清单仅 64Midbpostgres:17-alpine数百 MB 起步随数据增长redisredis:alpine数十 MB缓存命中后上升jitsu_redis_users_recognitionredis:alpine另一个独立 Redis 实例jitsujitsucom/jitsuRAM 大户见下方注释opensearchopensearchproject/opensearchJVM 默认-Xms512m -Xmx512mopensearch-dashboardsopensearch-dashboards又一个 Node 进程cubecubejs/cubeNode 进程 语义层缓存zipkinzipkin-slimJVM-Xms128m -Xmx128mminio / minio_create_bucketsminio mc数百 MB对象存储进程pgweb、dejavu数据库/搜索管理 UI小工具但都是常驻进程这还不算完。docker-compose.infra.yml 里 Jitsu 的配置直接写了一行警告注释# Retroactive users recognition can affect RAM significant. - USER_RECOGNITION_ENABLEDtrue回溯性用户识别会显著影响内存——这是官方自己承认的。而 OpenSearch 则被强制锁定了 JVM 堆和内存锁- bootstrap.memory_locktrue - ES_JAVA_OPTS-Xms512m -Xmx512m再加上 api 的 Node 进程、PostgreSQL 的 shared buffers 和连接池这一整套在 2G 机器上跑起来OOM 是数学上的必然不是运气问题。这也是社区里Gauzy 很吃内存印象的主要来源——大家默认跑的其实是这个全家桶。而最小集 docker-compose.demo.yml 只有三个服务db、api、webapp连 Redis 都不需要。这个差异正是后面所有调优的出发点。二、官方给出的数字基准K8s 清单与 seed 的 14GB 堆要谈实测与门槛最硬的证据是官方自己的生产清单。仓库里 .deploy/k8s/k8s-manifest.civo.prod.yaml 是 Ever 团队用于生产云部署的清单其中 API 的资源配置写得很清楚resources: requests: cpu: 300m memory: 896Mi这是一个官方生产环境的 API 请求值896Mi。注意这只是 Kubernetes 的 requests调度保证值实际进程运行中的 RSS 会明显高于它。也就是说光 API 一个 Node 进程官方就预留了接近 1G 的内存demo 版清单.deploy/k8s/k8s-manifest.civo.demo.yaml把 API 降到672Mi、webapp 降到64Mi——注意demo 版连 Redis/OpenSearch 等组件都不部署正好印证了去掉重型依赖后资源需求断崖式下降静态站点 webappapps/gauzy/app.js 就是一个 connect serve-static 的极简静态服务器在整个体系里最省64Mi 就能跑。另一个容易被忽略的数字藏在 apps/api/package.json 里——所有 seed 命令都带着同一个参数seed: cross-env NODE_ENVdevelopment NODE_OPTIONS--max-old-space-size14000 yarn ts-node ...--max-old-space-size14000即 seed 假数据时给 Node 开14GB 的堆上限。这从侧面说明了两件事一是 Gauzy 的数据模型和关联关系足够庞大大量实体、外键、级联全量 seed 是真实的内存吞噬者二是初始化灌数据阶段的内存压力远高于日常运行2G 机器上跑yarn seed:allREADME 明示需约 10 分钟几乎注定失败。正确做法是在内存充足的机器上完成 seed再迁移数据目录或只用最小 seedyarn seed初始化基础数据。把这几组官方数字放在一起我们可以得到一张可信的内存推算表档位可承载的组合说明2GAPI(~700M) webapp(~64M) PostgreSQL(~300M) 系统余量去掉 Redis/OpenSearch/Worker勉强可用4G2G 档 Redis(~100M) 独立 Worker 进程缓存与队列能力回归8G4G 档 OpenSearch(512M JVM) Cube MinIO逼近官方全家桶三、API 的缓存与队列两个隐形内存开关Gauzy 架构里有两个组件对内存的影响被严重低估缓存和任务队列。好消息是这两者在源码层面都做成了可优雅降级的设计这正是降配方案的核心支点。缓存Redis 可以关内存缓存是设计内的一等公民在 packages/core/src/lib/app/app.module.ts 中缓存模块的注册是条件编译的...(process.env.REDIS_ENABLED true ? [ NestCacheModule.registerAsync({ ... }) ] : [NestCacheModule.register({ isGlobal: true })]),当REDIS_ENABLED不为true时直接退化为 NestJS 默认的进程内内存缓存。即使REDIS_ENABLEDtrue代码里也内置了层层保护Redis 地址缺失时打印警告并回落内存缓存连接失败时 catch 后回落。配置项还设计了双层缓存——内存 L1CacheableMemorylruSize 10000 Redis L2且 Redis 是nonBlocking的读先走内存写异步进 Redis。这套设计意味着Redis 挂了 Gauzy 不会挂只是缓存从分布式降级为单机内存。对应到 .env.compose 里就是两行开关REDIS_ENABLEDtrue REDIS_URLredis://redis:63792G 机器上把它们改成REDIS_ENABLEDfalse省下的不止是一个 redis 容器还有 API 进程中维护 Redis 连接、序列化的开销。README 也确认了这一点平台可以在没有 Redis 的情况下使用内存缓存策略运行。队列BullMQ 的可信开关一个常量关掉一整套 WorkerGauzy 的异步任务插件文档流水线、定时任务等走 BullMQ而 BullMQ 依赖 Redis 做 broker。队列根的启用逻辑收敛在一个谓词函数里见 packages/scheduler/src/lib/utils/is-queue-root-enabled.tsif (process.env[ENV_SCHEDULER_QUEUE_ENABLED] false) { return false; } ... if (process.env[ENV_WORKER_QUEUE_ENABLED] false) { return false; } return process.env[REDIS_ENABLED] true;翻译过来REDIS_ENABLEDfalse时BullMQ 根连接根本不会注册所有插件队列自动退化为 inline进程内同步执行而 apps/worker/src/app/worker.constants.ts 里的WORKER_QUEUE_ENABLED/WORKER_SCHEDULER_ENABLED又给了 worker 进程独立的一层开关。文档类插件如 packages/plugins/docs/README.md明确写着队列关闭后流水线runs inline。这意味着在 2G 部署里你可以完全不启动独立的 worker 进程docker-compose 默认栈本就不含它并关掉 API 内的队列注册让任务在 API 进程内联执行。代价是重型异步任务文档 OCR、向量化会阻塞请求——所以这个开关要配合业务取舍不需要文档流水线的小团队直接关掉是明智的。Redis 连接的兜底默认即便不关 Redispackages/scheduler/src/lib/utils/resolve-bull-connection.ts 也展示了连接解析的优先级REDIS_URL→REDIS_HOST/PORT/USER/PASSWORD/TLS→ 默认127.0.0.1:6379。这提醒我们一个常见坑如果只设置REDIS_ENABLEDtrue却忘了配置地址BullMQ 会默认连本机 6379在 Docker 网络里会反复重试连接白白消耗资源。降配部署时务必成对配置或干脆关闭。四、PostgreSQL 与连接池数据库才是隐藏的内存大头很多部署教程把内存注意力放在 Node 和 JVM 上却忽略了 PostgreSQL。Gauzy 的 .env.compose 里有一组默认值值得细看DB_POOL_SIZE40 DB_POOL_SIZE_KNEX10 DB_CONNECTION_TIMEOUT5000 DB_IDLE_TIMEOUT10000TypeORM 连接池默认40 个连接。每个 PostgreSQL 后端进程都要占一块内存shared buffers 每连接 work_mem 上下文40 个空闲连接就是几十 MB加上 Postgres 默认的shared_buffers通常取物理内存的 1/42G 机器上这套默认值直接把数据库推向 OOM 边缘。社区情报里反复出现的数据库连接失败API 502/504类故障很大比例就是连接池与内存不匹配导致的连锁反应。降配时这组参数是第一优先级DB_POOL_SIZE10 DB_POOL_SIZE_KNEX5同时在 PostgreSQL 容器侧调低shared_buffers与work_mem可在 compose 的 db 服务中追加command: postgres -c shared_buffers128MB -c work_mem4MB。2G 机器上数据库稳定在 250–350MB 是完全可实现的。另外注意 README 的一句话默认数据库其实是 SQLiterecommended for testing/demo purposes only生产推荐 PostgreSQL 16。对 2G 机器的极端场景SQLite 单文件零守护进程是最极端的省内存选项省掉整个数据库常驻进程适合个人试用多人并发的生产场景仍应回到 PostgreSQL。五、按档位给出可落地的调优清单综合以上源码证据三档部署方案可以这样落地。2G最小可用集个人/小团队试用用 docker-compose.demo.yml 起步db api webapp 三个容器.env.compose设REDIS_ENABLEDfalse缓存回落进程内内存见app.module.tsWORKER_QUEUE_ENABLEDfalse、WORKER_SCHEDULER_ENABLEDfalse关闭 BullMQ见is-queue-root-enabled.ts不启动独立 workerDB_POOL_SIZE10、DB_POOL_SIZE_KNEX5PostgreSQL 追加shared_buffers128MB若业务量极小可换 SQLiteREADME 认可的方式进一步省掉 DB 常驻内存关闭观测类组件.env.compose中SENTRY_*、POSTHOG_ENABLED、OTEL_ENABLED全部置空/关闭这些开关默认可关不跑seed:all14GB 堆不是开玩笑用最小seed初始化后迁移数据。4G标准自托管推荐 10–50 人团队在 2G 方案基础上打开REDIS_ENABLEDtrueRedis 容器本身不过百 MB换来分布式缓存和队列能力恢复独立 worker 进程跑异步任务API 与 worker 各自持有内存缓存互不挤占DB_POOL_SIZE20PostgreSQLshared_buffers256MB内存观测建议用docker stats持续跟踪重点盯 API 的 RSS必要时通过NODE_OPTIONS--max-old-space-size2048收紧 Node 堆。8G接近全家桶含搜索与分析在 4G 方案基础上渐进加入 OpenSearchJVM 保持-Xms512m -Xmx512m或视数据量降到 256m、Cube、MinIO若不用 Jitsu 做数据采集直接从 infra 里去掉它省下最大的隐藏 RAM 消耗源docker-compose.infra.yml 中USER_RECOGNITION_ENABLEDtrue那行注释就是警告关闭 Zipkin默认OTEL_ENABLEDfalse即可若不使用分布式追踪不要开启。结论2G 能跑但你要先回答跑给谁看回到标题的问题2G 内存的服务器能不能碰 Gauzy答案取决于你跑的是哪个 Gauzy。把 docker-compose.yml 全家桶无脑拉起来的2G 必然 OOM而按 docker-compose.demo.yml 的最小集 关闭 Redis/队列 收紧连接池2G 机器跑一个 10 人以内团队的自托管 ERP 是完全可行的——社区里那些2G 跑起来的案例无一例外走的是这条路。Gauzy 的资源门槛本质上来自它的架构选择NestJS 全量模块加载的 Node 进程、TypeORM 的 40 连接默认池、依赖 Redis 的 BullMQ 队列、以及一套为全家桶设计的 Compose 编排。但源码层面这些环节几乎都做了降级开关——内存缓存兜底、队列内联执行、无 Redis 可运行。真正决定门槛的不是代码而是你愿意为内存牺牲多少能力搜索能力OpenSearch、数据采集Jitsu、分布式缓存Redis这些在中小团队的早期阶段往往是最不值得优先支付的内存税。最后提醒一句无论哪一档请永远在 seed/迁移完成后再换内存紧张的环境并给系统留出 swap 作为最后的缓冲。Gauzy 不是不能瘦身只是瘦身之前你得先看清它每块肌肉的消耗在哪里。【免费下载链接】ever-gauzyEver® Gauzy™ - Open Business Management Platform (ERP/CRM/HRM/ATS/PM) - https://gauzy.co项目地址: https://gitcode.com/GitHub_Trending/ev/ever-gauzy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考