2G内存云服务器如何优化Tomcat和MySQL配置以避免OOM？

在 2GB 内存的云服务器上同时运行 Tomcat 和 MySQL，确实属于“极限操作”。默认配置下，Tomcat 的 JVM 堆内存往往设置过大，而 MySQL 的缓冲池也极易吃满内存，两者叠加必然导致 OOM（Out Of Memory）甚至系统 Swap 交换导致服务器假死。

要解决这个问题，核心思路不是“无限加内存”，而是精准控制资源占用 + 启用外部存储/缓存。以下是经过生产环境验证的配置优化方案：

一、 总体资源规划原则

假设服务器总内存为 2GB，建议预留 512MB – 1GB 给操作系统内核、Swap 分区以及其他后台进程。

• MySQL 可用内存上限：约 800MB – 1GB
• Tomcat (JVM) 可用内存上限：约 600MB – 800MB
• 系统保留：剩余部分

二、 MySQL 配置优化 (my.cnf / my.ini)

MySQL 是内存大户，主要关注 innodb_buffer_pool_size。对于小内存服务器，切忌使用默认值或过大的值。

1. 关键参数调整

[mysqld]
# 基础字符集
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

# 【核心】InnoDB 缓冲池大小
# 物理内存的 50%-70% 是比较安全的范围，但考虑到 Tomcat 也要用内存，这里设为 384M-512M
# 如果只跑一个库，可以设到 600M；如果有多个库，建议更低
innodb_buffer_pool_size = 512M

# 【核心】单表数据文件限制
# 防止单个大表撑爆 Buffer Pool
innodb_log_file_size = 128M

# 连接数优化
# 小内存服务器不要开太多连接，避免每个连接都占用大量内存
max_connections = 100 
thread_cache_size = 10

# 临时表处理
# 将内存中的临时表限制减小，超出部分直接落盘
tmp_table_size = 32M
max_heap_table_size = 32M

# 禁用不必要的功能以节省内存
skip-name-resolve
local-infile=0

2. 注意事项

• 监控 Buffer Pool 命中率：如果命中率低于 95%，且 CPU 负载不高，可以适当增加 innodb_buffer_pool_size（但不要超过 700M）。
• 避免大查询：确保应用层没有全表扫描或返回巨大结果集的 SQL。

三、 Tomcat/JVM 配置优化

Tomcat 的内存问题主要来自 JVM Heap（堆内存）和 Metaspace（元空间）。我们需要通过 -Xms 和 -Xmx 严格限制其最大堆内存。

1. JVM 启动参数 (setenv.sh 或 catalina.sh)

# 设置初始堆内存和最大堆内存相等，避免动态扩容带来的性能抖动
JAVA_OPTS="-Xms256m -Xmx512m"

# 元空间大小（存放类信息），根据应用复杂度调整
JAVA_OPTS="$JAVA_OPTS -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m"

# GC 日志输出（用于排查内存泄漏）
JAVA_OPTS="$JAVA_OPTS -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/logs/gc.log"

# 强制使用 G1 GC（Java 8u212+ 推荐）或 Parallel GC（老版本）
# Java 8 早期版本可用：-XX:+UseParallelGC
# Java 8 后期及 Java 11+ 推荐：-XX:+UseG1GC
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"

# 关闭不需要的模块以节省内存（可选）
JAVA_OPTS="$JAVA_OPTS --add-opens java.base/java.lang=ALL-UNNAMED"

关键点解释：

• -Xmx512m：这是硬上限。即使你有 1GB 空闲，也不要让 JVM 超过这个值，留给 MySQL 和 OS。
• -Xms 等于 -Xmx：防止 JVM 在运行时动态调整堆大小，减少 GC 压力。
• G1 GC：相比默认的 CMS 或 Parallel GC，G1 在小堆内存下通常表现更稳定，停顿时间更可预测。

2. Tomcat Connector 优化 (server.xml)

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           maxThreads="150"      # 最大线程数，小内存服务器不宜过高
           minSpareThreads="25"  # 最小空闲线程
           acceptCount="100"     # 等待队列长度
           enableLookups="false" # 关闭 DNS 查找，节省开销
           compression="on"      # 开启压缩，减少带宽占用
           compressionMinSize="2048"/>

四、 系统级辅助优化

1. 合理配置 Swap（虚拟内存）

不要禁用 Swap！ 在 2GB 内存服务器上，Swap 是最后的救命稻草。当物理内存不足时，Linux 会将不常用的页面换出到 Swap，避免直接 OOM Kill。

• 创建 Swap 文件（如果尚未创建）：

  dd if=/dev/zero of=/swapfile bs=1M count=1024
  chmod 600 /swapfile
  mkswap /swapfile
  swapon /swapfile
  echo '/swapfile none swap sw 0 0' >> /etc/fstab

• 调整 Swappiness：
  默认值为 60，建议调整为 10~20，让系统优先使用物理内存，只有在必要时才使用 Swap。

  sysctl vm.swappiness=10
  # 写入 /etc/sysctl.conf 永久生效

2. 监控与告警

• 安装 htop 或 btop 实时观察内存使用情况。
• 重点监控：
  • MySQL 的 Innodb_buffer_pool_pages_free
  • JVM 的 Heap Usage（可通过 JMX 或 Arthas 查看）
  • 系统 Load Average

五、 架构层面的终极建议

虽然上述配置能让 2GB 服务器勉强跑起来，但从稳定性和扩展性角度，强烈建议：

1. 分离部署：

   • 如果可能，将 MySQL 迁移到独立的云数据库服务（如阿里云 RDS、腾讯云 CDB 等）。这些服务底层资源隔离，你只需关注应用层，无需担心内存竞争。
   • 或者，将 Tomcat 和 MySQL 部署在不同的轻量级服务器上（例如 1GB 内存跑 MySQL，1GB 内存跑 Tomcat），通过内网通信。

2. 引入缓存层：

   • 如果应用有高频读需求，考虑引入 Redis（单机版仅需几百 MB 内存），减轻 MySQL 压力，从而允许降低 MySQL 的 Buffer Pool 大小。

3. 代码层面优化：

   • 检查是否有内存泄漏（如静态集合类无限增长）。
   • 优化 SQL 查询，避免大事务和长连接持有过多锁。

总结配置清单

按照以上配置，你的 2GB 云服务器可以在保证基本稳定性的前提下，流畅运行中小型 Web 应用。记住，小内存服务器的核心哲学是：克制、精简、监控。