使用2核2G的云服务器运行Java Web项目（Tomcat+MySQL），系统负载高怎么办？-云小栈

2 核 2G 的云服务器运行 Java Web（Tomcat + MySQL）属于典型的“小马拉大车”场景，Java 和 MySQL 都是内存消耗大户。当系统负载高时，通常表现为 CPU 100%、内存溢出（OOM）、磁盘 I/O 飙升或连接超时。

解决思路应遵循 “先优化配置，再代码调优，最后考虑架构升级” 的原则。以下是针对该配置的具体优化方案：

1. 核心瓶颈：内存与 JVM 调优（最关键）

2G 内存中，操作系统需要约 300-400MB，MySQL 默认配置极其吃内存，JVM 如果分配过大直接导致 OOM。

限制 JVM 堆内存：
- Tomcat 默认的 -Xms 和 -Xmx 往往设置得过大（如 512M+），在 2G 总内存下会导致系统频繁 Swap（交换分区），造成卡顿。
- 建议配置：将最大堆内存限制在 300M – 400M。
- 修改 setenv.sh (Linux) 或 catalina.sh 中的 JAVA_OPTS：
```
export JAVA_OPTS="-Xms256m -Xmx384m -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
```
- 注意：如果应用启动时报 OutOfMemoryError，需进一步降低到 256M。

严格限制 MySQL 内存：

MySQL 默认会尝试占用大量内存作为 Buffer Pool。在 2G 机器上必须强制限制。

修改 /etc/my.cnf (CentOS/Ubuntu) 或 /etc/mysql/my.cnf：

[mysqld]
# 限制最大连接数，防止并发过高撑爆内存
max_connections = 100

# 关键：调整 Buffer Pool 大小，设置为物理内存的 25%-30% (约 512M-600M)
innodb_buffer_pool_size = 512M

# 关闭不必要的日志和特性以节省内存
log_bin = off 
# 或者根据业务需求保留，但不要太大

重启 MySQL 服务生效：systemctl restart mysqld。

2. 数据库层面优化

MySQL 是常见的性能瓶颈点，尤其是慢查询。

开启慢查询日志：定位执行时间超过 1 秒的 SQL 语句。
```
slow_query_log = 1
long_query_time = 1
```
索引优化：检查所有高频查询表是否缺少索引。没有索引的全表扫描在低配服务器上会瞬间耗尽 CPU。
读写分离（可选）：如果主要是读多写少，可以考虑引入 Redis 缓存热点数据，减少 MySQL 压力。
清理无用数据：定期归档或删除历史日志、临时表数据。

3. 应用层与中间件优化

启用 Gzip 压缩：
- 在 Tomcat server.xml 中开启 <Connector compression="on" compressionMinSize="2048" />。这能显著减少网络传输量，降低带宽压力。
连接池调优：
- 检查数据库连接池（如 HikariCP, Druid）的配置。避免连接数设置过大（如 > 50），在 2G 机器上，保持 10-20 个活跃连接通常足够。
静态资源分离：
- 将图片、CSS、JS 等静态资源托管到对象存储（如阿里云 OSS、腾讯云 COS）或 CDN，不要让 Tomcat 处理这些请求。
使用轻量级容器或框架：
- 如果是新项目，考虑从 Spring Boot + Tomcat 切换到 Spring Cloud Alibaba + Nacos (如果微服务架构允许) 或直接使用 Undertow (比 Tomcat 更轻量)。
- 如果是单体应用，确保没有加载不必要的模块（如 Spring Security 的复杂规则、过多的 AOP）。

4. 系统级优化

增加 Swap 分区（虚拟内存）：
- 虽然 Swap 会降低速度，但在物理内存不足时，它是防止进程被系统杀掉（OOM Killer）的最后防线。
- 创建 2G-4G 的 Swap 文件：
```
dd if=/dev/zero of=/swapfile bs=1M count=2048
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
```
- 调整内核参数，减少 Swap 使用倾向：
```
vm.swappiness = 10
```
监控与报警：
- 安装 htop, iftop, iostat 等工具实时监控。
- 配置云厂商自带的监控告警（CPU>80%, 内存>90% 即通知）。

5. 架构与成本权衡（终极方案）

如果经过上述优化，负载依然无法接受，说明当前的硬件规格确实无法满足业务量。此时有以下选择：

垂直扩容（推荐短期方案）：
- 将服务器升级到 4 核 8G。这是最直接的解决方案，成本可控，无需改代码。对于 Java 应用，内存翻倍带来的提升通常是巨大的。
水平拆分（长期方案）：
- 动静分离：前端静态资源上 CDN。
- 数据库独立：将 MySQL 迁移到云厂商提供的 RDS 实例（按量付费），释放本地服务器的 IO 和内存压力。
- 应用集群：部署两个 2 核 4G 的应用节点，前面加一个负载均衡（SLB/Nginx），通过水平扩展来分担流量。

总结行动清单

立即执行：修改 JVM 参数（-Xmx384m）和 MySQL 配置（innodb_buffer_pool_size=512M）。
排查：开启 MySQL 慢查询日志，修复 Top 5 慢 SQL。
加固：增加 Swap 分区防止崩溃，开启 Gzip 压缩。
决策：如果一周后负载仍高，直接升级配置至 4 核 8G 或拆分数据库。