使用2核2G的云服务器部署若依系统需要优化哪些配置？-CLOUD云枢

若依（RuoYi）系统基于 Spring Boot + Vue 架构，默认配置下对内存和 CPU 有一定要求。2 核 2G 的云服务器属于入门级配置，运行生产环境会非常吃紧，必须针对 JVM、数据库、中间件及前端构建进行深度裁剪和优化。

以下是针对该规格的具体优化方案：

2G 内存中，操作系统和数据库需要占用约 400MB-600MB，留给 Java 进程的空间非常有限。若按默认堆大小启动，极易触发 OOM（Out Of Memory）导致服务频繁重启。

限制堆内存：强制将最大堆内存控制在 512MB – 768MB 之间。
- 推荐参数：-Xms512m -Xmx512m
- 原因：设置初始值和最大值一致，避免 JVM 在运行时动态扩容带来的性能抖动和内存碎片。
GC 策略选择：
- 优先使用 G1 垃圾回收器（JDK 8u191+），它对堆空间划分更灵活，停顿时间更可控。
- 参数补充：-XX:+UseG1GC -XX:MaxGCPauseMillis=200
元空间（Metaspace）：
- 若依依赖大量反射和动态X_X，元空间容易溢出。建议显式设置 -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m。

完整示例：

java -Xms512m -Xmx512m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar ruoyi-admin.jar

若依默认集成 MySQL 和 Redis。在 2G 环境下，这两者是最消耗资源的组件。

MySQL 优化：
- 连接数限制：修改 my.cnf，将 max_connections 调低至 50-100，防止连接池耗尽。
- 缓冲池调整：这是最关键的。默认可能占用过多内存。建议设置为物理内存的 30%-40%。
  - innodb_buffer_pool_size = 300M (2G 机器不要设太大)
- 关闭非必要功能：如 log_bin（开发环境可关，生产需权衡）、sync_bin_log 等日志同步机制，根据数据一致性要求适当降级。
- 索引检查：确保常用查询字段有索引，避免全表扫描消耗 CPU。
Redis 优化：
- 内存限制：设置 maxmemory 为 256M 或 300M，并配合淘汰策略。
- 淘汰策略：推荐 allkeys-lru（所有键值都适用 LRU 算法）或 volatile-lru（仅过期键适用）。这能保证在内存满时自动清理旧数据，防止服务崩溃。
- 持久化：若对实时性要求极高且允许少量数据丢失，可暂时关闭 RDB/AOF，或仅开启 AOF 的每秒同步（appendfsync everysec）以减少 I/O 压力。

移除冗余模块：
- 若依包含代码生成、在线文档、定时任务监控等模块。如果业务不需要，直接在 application.yml 中注释掉相关模块的配置，或者在 Maven/Gradle 打包时排除这些模块，减少启动加载时间和内存占用。
前端构建优化：
- Nginx 静态资源：Vue 项目必须执行 npm run build 打包成静态文件，由 Nginx 托管，严禁直接通过 Node.js 服务启动前端（Node 本身也吃内存）。
- Gzip 压缩：在 Nginx 中开启 gzip on;，减小传输体积，降低带宽压力。
- 浏览器缓存：配置静态资源强缓存（Cache-Control），减少重复请求。

Swap 分区（虚拟内存）：
- 必须创建。虽然 Swap 会降低性能，但在 2G 内存下，它是防止 OOM Killer 直接杀掉进程的最后一道防线。
- 建议创建 2GB-4GB 的 Swap 文件，作为内存的缓冲池。
内核参数调优：
- 增加 TCP 连接数限制：net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog。
- 调整文件描述符限制：ulimit -n 65535，防止高并发下出现 "Too many open files" 错误。

容器化部署（Docker）：
- 使用 Docker Compose 编排，可以精确控制每个容器的内存上限（Cgroups）。
- 例如：给 MySQL 容器限制 mem_limit: 300m，给 Java 容器限制 mem_limit: 600m，防止单个组件吃光所有内存。
前后端分离：
- 务必保持后端 API 和前端页面分离。如果前端也跑在同一个 Java 进程里（如传统 SSR 模式），2G 内存几乎无法支撑。

在 2 核 2G 的服务器上部署若依，核心矛盾是内存不足。

如果业务量稍大，或者遇到响应超时，说明硬件资源已达瓶颈。此时最优解不是继续压榨配置，而是考虑升级至 4 核 4G，或者将数据库、Redis 迁移到云厂商提供的独立云数据库实例（RDS/云缓存），让服务器只专注于计算逻辑，这样成本更低且稳定性更高。