在资源有限的情况下，应用和数据库共用服务器如何优化？

在资源受限（如低配云服务器、测试环境或初创期项目）的场景下，应用服务器与数据库共用是常见的妥协方案。虽然从架构最佳实践来看，分离部署是首选，但在现实约束下，通过精细化的调优和隔离手段，完全可以实现“小马拉大车”的稳定运行。

核心思路不是追求极致的性能，而是防止资源争抢导致的雪崩效应，并最大化硬件利用率。以下是从操作系统、数据库配置、应用层到监控运维四个维度的具体优化策略：

1. 操作系统层面的资源隔离与限制

这是最基础也最关键的一步，目的是防止数据库进程吃光所有内存导致系统死锁，或者应用进程耗尽 CPU 导致数据库响应超时。

• Cgroups 资源限制（Linux）
  使用 Linux 的 Cgroups 机制为数据库和应用设置 CPU 和内存上限。例如，给 MySQL/MariaDB 分配最多 70% 的内存，剩余 30% 留给操作系统缓存和应用进程。这样即使数据库发生慢查询或内存泄漏，也不会直接 OOM（Out of Memory）杀死整个服务器。

  # 示例：限制某个进程的内存上限
  systemctl set-property mysql.service MemoryMax=2G

• Swap 分区合理配置

  • 传统误区：很多人认为 Swap 会拖慢速度，因此关闭它。
  • 正确做法：在资源有限时，必须开启 Swap，但要调整参数。将 vm.swappiness 设置为较低值（如 10-20），让内核优先使用物理内存，仅在极端情况下才使用 Swap。这可以作为最后一道防线，避免进程被直接杀死。
  • SSD 注意：如果使用 SSD 作为 Swap 盘，其读写速度远快于 HDD，对性能影响相对可控，但需注意写入寿命。

• 文件系统 I/O 调度器优化
  对于 SSD 云盘，确保 I/O 调度器设置为 none 或 mq-deadline，减少不必要的队列延迟。对于机械硬盘，保持 cfq 即可。

2. 数据库层面的极致调优

数据库通常是资源消耗大户，重点在于减少磁盘 I/O 和内存占用。

• 选择合适的存储引擎与版本

  • MySQL：默认使用 InnoDB。如果数据量小且并发不高，考虑使用 MyISAM（仅适用于读多写少、无事务需求的场景，但不推荐生产环境）。更推荐的是，如果只需简单存储，评估是否可以用 SQLite 替代 MySQL，SQLite 是进程内数据库，无网络开销，资源占用极低。
  • PostgreSQL：调整 shared_buffers 和 effective_cache_size，确保它们不超过总内存的 50%-60%，留出空间给 OS 和其他进程。

• 连接池控制（关键！）

  • 限制最大连接数：在 my.cnf 中设置 max_connections 为一个较小的值（如 50-100）。默认值往往过大，每个连接都会占用内存。
  • 应用层连接池：在应用代码中使用 HikariCP（Java）、PgBouncer（Python/Go）等轻量级连接池。严禁每次请求都新建数据库连接。连接池能复用连接，大幅降低上下文切换开销。

• 索引优化与查询精简

  • 避免全表扫描：任何没有索引的 SELECT * 都是灾难。确保常用查询字段有索引。
  • 只查所需字段：禁止 SELECT *，明确指定需要的列，减少网络传输和内存拷贝。
  • 关闭二进制日志（Binlog）：如果是非核心业务或测试环境，且不需要主从复制和数据恢复，可以考虑关闭 Binlog 以减轻磁盘 I/O 压力。

• 临时文件与排序优化
  调整 tmpdir 指向一个 SSD 路径或使用 RAM Disk（内存盘）存放临时文件，提速复杂查询中的排序操作。

3. 应用层优化

应用层的目标是减少对数据库的请求频率和单次请求的资源消耗。

• 引入缓存层（Redis/Memcached）
  即使只有一个 Redis 实例，也能极大缓解数据库压力。

  • 热点数据缓存：将频繁读取但不常修改的数据（如配置信息、用户基本信息）放入 Redis。
  • 会话存储：将 Session 存储在 Redis 而非数据库中。
  • 注意：同样需要为 Redis 设置内存上限，并使用 LRU 淘汰策略。

• 异步处理与消息队列
  对于非实时性强的操作（如发送通知、生成报表、日志记录），不要同步写入数据库。使用轻量级消息队列（如 RabbitMQ、RocketMQ，甚至本地文件队列）进行解耦，批量写入数据库。

• 静态资源分离
  将 CSS、JS、图片等静态资源放到对象存储（如阿里云 OSS、腾讯云 COS）或 CDN，而不是由应用服务器动态输出。这不仅节省带宽，还减少了应用服务器的 I/O 负担。

4. 监控与告警

没有监控的优化是盲人摸象。你需要知道瓶颈在哪里。

• 关键指标监控

  • CPU：关注 iowait（IO 等待）和 steal（虚拟化环境中的 CPU 窃取时间）。如果 iowait 高，说明磁盘是瓶颈；如果 steal 高，说明宿主机过载，需考虑升级实例规格。
  • 内存：监控 used vs available，警惕 Swap 使用率突然飙升。
  • 磁盘 I/O：监控 await（平均等待时间）和 %util（利用率）。
  • 数据库特定：监控 QPS（每秒查询数）、TPS（每秒事务数）、慢查询数量、连接数使用率。

• 自动缩容/重启策略
  编写脚本监控异常状态。例如，当数据库进程占用内存超过阈值且持续一段时间，自动触发优雅重启（先断开新连接，等待现有连接结束，再重启服务），避免手动干预延迟。

5. 架构演进建议（长期视角）

虽然当前是共用服务器，但应规划未来拆分路径：

1. 第一阶段：应用 + DB 共用（当前阶段）。
2. 第二阶段：将数据库迁移到独立的高 IO 型云盘或小型 RDS 实例。大多数云平台提供按量付费的小规格 RDS，成本可能比你自建高性能服务器更低。
3. 第三阶段：引入读写分离、分库分表。

总结 Checklist

最后提醒：共用服务器本质上是牺牲了可用性和扩展性来换取成本。一旦流量增长或出现突发高峰，这种架构极易崩溃。因此，务必做好每日备份（包括数据库 dump 和整机镜像），并确保有快速回滚的能力。