1核1G1M的云服务器如何优化才能支持两个WordPress程序稳定运行？

在 1 核 CPU、1GB 内存、1Mbps 带宽 的极限配置下，同时运行两个 WordPress 实例确实极具挑战。默认配置下（如 PHP-FPM + MySQL），单个 WordPress 就可能吃光资源导致服务崩溃。

要实现“稳定运行”，核心思路是：极致压缩资源占用、减少并发请求压力、利用缓存绕过计算。以下是分层次的优化方案：

1. 系统级与数据库优化（基础生存线）

这是最关键的一步，必须将操作系统和数据库的开销降到最低。

• 操作系统精简

  • 更换轻量级 OS：如果还在用 Ubuntu/CentOS 完整版，建议换成 Alpine Linux 或 Debian Minimal。它们的基础内存占用可控制在 50MB-80MB 以内，为应用留出更多空间。
  • 关闭非必要服务：禁用 firewalld (改用 iptables/nftables)、sshd 以外的所有后台服务，关闭图形界面（如果有的话）。

• MySQL/MariaDB 调优

  • 放弃 MySQL，改用 SQLite：这是最激进但最有效的方案。WordPress 默认支持 SQLite 插件（WP-CLI 或专用插件）。SQLite 是文件型数据库，无需独立进程，内存占用极低，且无网络开销。
    • 操作：安装 sqlite3 扩展，使用 "WP-CLI" 将数据库迁移为 SQLite，或使用 "SQLite Database Integration" 插件。
  • 若必须用 MySQL：
    • 修改 /etc/mysql/my.cnf (或 mariadb.conf)，强制限制内存：

      [mysqld]
      key_buffer_size = 16M
      max_allowed_packet = 16M
      thread_stack = 2M
      thread_cache_size = 2
      query_cache_limit = 2M
      query_cache_size = 4M
      query_cache_type = 1
      innodb_buffer_pool_size = 16M  # 关键：限制 InnoDB 缓存
      tmp_table_size = 8M
      max_heap_table_size = 8M

    • 关闭慢查询日志：slow_query_log = 0。

• 开启 Swap 分区（虚拟内存）

  • 物理内存只有 1GB，必须开启 Swap 防止 OOM Killer 直接杀掉进程。
  • 操作：创建一个 2GB 的 Swap 文件。

    dd if=/dev/zero of=/swapfile bs=1M count=2048
    chmod 600 /swapfile
    mkswap /swapfile
    swapon /swapfile
    # 写入 /etc/fstab 实现开机自动挂载
    echo '/swapfile none swap sw 0 0' >> /etc/fstab

  • 注意：Swap 会降低性能，但在内存不足时能防止服务器挂掉。调整 vm.swappiness 为 10，减少频繁交换：sysctl vm.swappiness=10。

2. Web 服务器与 PHP 优化（降低单请求成本）

Nginx 比 Apache 更省内存，PHP-FPM 需要严格限制进程数。

• Web 服务器：Nginx

  • 确保只保留 Nginx，卸载 Apache。
  • 配置 Nginx 关闭不必要的模块（如 Perl, Lua 等），仅保留 http, stream, mail 必要模块。

• PHP-FPM 极致瘦身

  • 编辑 php-fpm.d/www.conf (或全局配置)：
  • 模式选择：使用 static 模式（不推荐，因为启动即占满内存）或 dynamic 模式。鉴于内存极小，建议使用 ondemand 模式（按需启动进程）。
  • 关键配置：

    pm = ondemand
    pm.max_children = 2   ; 总共最多允许 2 个 PHP 进程同时运行
    pm.start_servers = 1
    pm.min_spare_servers = 1
    pm.max_spare_servers = 1
    request_terminate_timeout = 30s ; 防止脚本死循环卡死

  • PHP 版本：使用 PHP 7.4 或 8.0。PHP 8.1+ 内存占用较高，除非代码极度优化，否则不建议。

• 多站点策略

  • 不要运行两个独立的 Nginx 站点配置来解析两个 WP。
  • 建议使用 Nginx 子目录映射 或 同一个 PHP-FPM pool 处理两个站点的请求，通过 $_SERVER['DOCUMENT_ROOT'] 区分路径。
  • 或者，如果两个站点流量都很低，考虑合并为一个 WordPress 多站点（Multisite） 网络，这样只需维护一套核心文件和数据库逻辑，大幅节省资源。

3. 缓存策略（以空间换时间，以缓存换计算）

没有缓存，1 核 CPU 处理两个 WP 的 PHP 解析会瞬间满载。

• 服务端缓存（Redis/Memcached）

  • 由于内存紧张，可能无法运行 Redis。如果必须运行，请将其配置为 maxmemory-policy allkeys-lru 并限制 maxmemory 为 128MB。
  • 替代方案：使用 Object Cache 插件配合 File-based cache（如 W3 Total Cache 的文件后端），避免引入额外的内存进程。

• 页面缓存（Page Cache）

  • 这是救命稻草。安装 W3 Total Cache 或 LiteSpeed Cache (需 LiteSpeed 面板，较省资源)。
  • 开启 静态 HTML 缓存：用户访问时直接返回 HTML 文件，跳过 PHP 和数据库查询。
  • 配置规则：对登录用户关闭缓存，对未登录访客开启全量缓存。

• 浏览器缓存

  • 在 Nginx 中配置静态资源（CSS, JS, Images）的过期时间（如 1 年），减少重复下载。

4. 应用程序层面的裁剪

• 主题与插件

  • 主题：使用极简主题（如 GeneratePress 免费版、Astra 或 Hello Elementor），严禁使用重型主题（带大量动画、拖拽构建器）。
  • 插件：每个站点插件不超过 5 个。
    • 必须：安全插件（Wordfence 太吃资源，建议用简单的防火墙规则）、缓存插件、SEO 插件（RankMath 比 Yoast 轻）。
    • 移除：所有统计插件、社交分享插件、表单插件（除非必要）。
  • 代码优化：手动删除 wp-config.php 中的调试项，禁用 WP_DEBUG。

• 图片优化

  • 所有上传的图片必须在本地压缩到 100KB 以下再上传。
  • 启用 WebP 格式转换（通过 Nginx 或插件）。

5. 流量控制（1Mbps 瓶颈）

1Mbps 带宽意味着每秒只能传输约 128KB 数据。如果两个站点同时有图片加载，页面打开速度会极慢甚至超时。

• CDN 提速：
  • 必须使用 CDN（如 Cloudflare 免费版）。将 CSS、JS、图片、字体全部托管到 CDN。
  • 配置 Nginx 让静态资源走 CDN，源站只负责生成动态 HTML。这能极大缓解带宽压力。
• Gzip/Brotli 压缩：
  • 在 Nginx 开启 Gzip 压缩，减小传输体积。

总结实施路线图

1. 第一周（生存阶段）：

   • 重装 Alpine Linux。
   • 安装 Nginx + PHP 7.4 (FPM ondemand, max_children=2) + SQLite (或极度受限的 MySQL)。
   • 开启 2GB Swap。
   • 部署两个 WP，使用极简主题，仅安装缓存插件。
   • 接入 Cloudflare CDN。

2. 第二周（优化阶段）：

   • 检查 Nginx 错误日志，调整 PHP 超时时间。
   • 分析慢查询，进一步精简插件。
   • 测试并发能力，观察 Swap 使用率。

风险提示：
即使经过上述优化，1 核 1G 跑两个 WP 依然处于“勉强维持”状态。

• 如果两个站点同时遭遇突发流量（如被爬虫攻击或热点事件），服务器仍可能宕机。
• 最佳建议：如果业务允许，强烈建议将其中一个站点迁移至免费的静态托管（GitHub Pages/Vercel），或者升级服务器配置到 2 核 2G，这是性价比最高的长期方案。