云知道CLOUD1 核 1GB 跑 WordPress + MySQL，这配置在几年前还能凑合，现在基本属于“极限生存”模式。瓶颈非常明确，不是单一环节，而是内存、CPU 调度、IO 等待三者形成的恶性循环。
核心矛盾就一个：MySQL 和 PHP-FPM 都在抢那可怜的 1GB 内存。
1. 内存是头号杀手（Swap 灾难）
这是最直接的死穴。Linux 系统本身要占掉 200MB-300MB，剩下的 700MB 左右分给应用。
- MySQL 的贪婪：默认配置下，MySQL 的
innodb_buffer_pool_size往往设置得过大，或者随着查询压力自动膨胀。它需要大量内存来缓存数据页。一旦内存不足，MySQL 会疯狂触发 Swap（交换分区）。 - PHP-FPM 的堆积：WordPress 处理请求时，每个并发连接都会启动一个 PHP-FPM 进程。如果开启多个 worker，内存瞬间见底。
- 后果：一旦物理内存耗尽，系统开始使用硬盘做虚拟内存（Swap）。机械硬盘或普通 SSD 的随机读写速度比内存慢几个数量级。此时服务器响应时间会从毫秒级直接跳到几十秒甚至超时，表现为网站打不开，或者数据库连接超时。
2. CPU 单核的上下文切换与锁竞争
1 核意味着同一时间只能执行一条指令流。
- 高并发下的饥饿：当有少量用户同时访问（比如 5-10 个），MySQL 的线程和 PHP 进程都在争抢这一个 CPU 核心。频繁的上下文切换（Context Switch）会导致 CPU 大部分时间在“切换任务”而不是“干活”，实际计算效率极低。
- 锁等待：WordPress 插件多，数据库表结构复杂。在写操作（如保存评论、更新选项）时，MySQL 的行锁或表锁会阻塞其他读操作。单核 CPU 无法并行处理这些锁竞争，导致队列堆积，所有请求排队等待。
3. IO 等待（I/O Wait）飙升
在低配服务器上，你很难看到 CPU 占用率长期 100%，反而经常看到 iowait 很高。
- 原因：因为内存不够用，MySQL 频繁把脏页刷入磁盘，或者从磁盘读取不存在的页面（Page Fault）。
- 表现：数据库查询变慢，不是因为 SQL 写得烂，而是因为磁盘读写成了瓶颈。对于机械硬盘来说，这是致命伤；即使是 NVMe SSD，在 1GB 内存限制下，频繁的随机 IO 也会迅速占满带宽。
4. WordPress 自身的“吃相”
- 插件臃肿：很多轻量级主题还好，一旦装上 SEO 插件、缓存插件、安全扫描插件，WP 的初始化过程就会变得极其沉重。
- 无缓存依赖：如果没有配置 Redis 或 Memcached（1GB 内存根本装不下这两个服务），每次请求都要重新连接 MySQL，解析 PHP，生成 HTML。这种全量生成的模式对 1 核 1G 简直是降维打击。
破局建议（如果不换硬件）
如果你必须维持这个配置，必须做极端的优化：
- 强制限制 MySQL 内存：手动修改
my.cnf，将innodb_buffer_pool_size设为总内存的 10%-15%（约 64MB-128MB），禁止其过度膨胀。 - 关闭 Swap：虽然听起来反直觉，但在内存极度紧张且没有大内存硬盘做 Swap 的情况下，强制 OOM Killer 杀掉进程有时比无限拖慢系统要好（或者确保 Swap 空间极小且不被频繁调用）。更稳妥的是优化代码减少内存占用。
- 引入轻量级缓存：既然装不下 Redis，就用文件缓存（File Cache）或者利用 Nginx 的静态缓存功能（FastCGI Cache），把动态请求变成静态文件输出，绕过 PHP 和 MySQL。
- 精简插件：卸载所有非必要的插件，只保留核心功能。
- 更换数据库引擎：如果可能，考虑迁移到 SQLite（需配合 WP 插件），彻底消除 MySQL 的开销，但这对并发写入支持较弱，适合纯展示型博客。
结论：1 核 1GB 跑 WordPress + MySQL，瓶颈不在网络，也不在磁盘速度，而在于内存不足以支撑 MySQL 缓冲池和 PHP 进程驻留，导致系统陷入 Swap 交换和 CPU 上下文切换的死循环。除非你的访问量极低（日 PV < 1000）且内容高度静态化，否则这个配置在生产环境就是定时炸弹。