如何让 WordPress 完全运行在内存中
这可不是你爷爷奶奶那辈子的LAMP架构。这是把WordPress直接塞进内存的操作——就像把赛车引擎塞进本田思域，跑得飞快到连硬盘是什么都忘了。大多数开发者整天忙着修补插件，祈祷能让PageSpeed评分稍微提升点。而我？我直接从虚空启动完整堆栈，加载至内存，随时准备在毫秒间消亡重生。
你不需要这个。没人真正需要这个。但或许你来到这里，是因为厌倦了延迟。厌倦了借口。厌倦了运行时不发出嘶吼的基础设施。
“里克(Rick)”有两种形态：一种是“商业界的弗雷德·罗杰斯”，他真诚关怀你这个人，总带着微笑完成任务；另一种是“帽人”——当你服用过量苯海拉明时出现的幻象，那个在视野边缘阴森游荡的疯狂存在。眼前这个作品，正是帽人献给你的礼物。
若不想读我这疯癫絮语，请直奔从内存运行WordPress的Ansible剧本(见我GitHub)
背景
在我职业生涯中遭遇的无数糟糕项目堆里，最令我抓狂的莫过于从前任开发者手中接手的WordPress站点。这些垃圾堆充斥着疏于维护和技术缺陷。
当我像从废品场拼装车队般改造这些站点时，作为Linux服务器管理员而非WordPress开发者，我从性能优化角度学到了 大量 经验。WordPress本身可以运行得非常快，也有插件能实现这个目标——但真正的速度提升来自服务器调优。曾有人与我针锋相对地坚持认为缓存是加速WordPress的唯一途径。这些人根本不懂大规模服务器集群的管理之道。在WordPress上堆砌缓存插件根本毫无作用，反而会错失大量性能优化机会。
市面上存在大量专注于WordPress托管的服务商，但即便他们对自身技术栈的性能调优也仅止于此。主流WordPress托管商基本都采用无头架构部署站点。诚然，无头WordPress具备诸多优势，远胜于共享主机平台上的传统WordPress站点，但无论如何切分，服务器始终扮演着关键角色！所有关键操作都在服务器端发生。即便到了2025年，人们仍需填写表单，林赛或史蒂夫仍需登录更新内容，若涉及商品销售，结账流程更需状态管理。
那么如何在不拿电锯大刀阔斧修改代码库的前提下提升速度？拿你刚接手或搭建的旧WordPress站点试试看，更新部分或全部插件后会发生什么。网站崩溃得如此彻底，仿佛黑洞骤然开启，整座城市都被吸进事件视界——只因你更新了那个诡异的WooCommerce插件到最新版本。简直像把叉子插进电源插座。
我经历过至少上百次这样的循环：接手技术债务堆积如山的破旧WordPress站点(足以让小国破产)，客户却要求昨天就要运行流畅。这些可不是小本经营的家庭作坊，而是企业级WordPress站点，还集成着ERP系统之类的定制功能——这些系统早随着chixilub小行星让恐龙尝到太阳滋味时就灭绝了。多数时候，我只能守着这些网站维持运转，直到整个站点重构完成，或是客户内部依赖项目终止，摆脱与网站对接的陈旧系统。最近承接的项目让我顿悟：是时候打破WordPress开发者惯用的传统技术栈思维了。有时需要这样的契机，才能真正反思自己的所作所为及其背后的意义。我决定不再盲从既定模式，彻底重构技术栈。于是，我以追求极致速度的系统管理员视角，完成了这场变革。
为何要在内存中运行WordPress？
简而言之：因为延迟就是浪费生命
内存的速度比最快的磁盘阵列快上几个数量级。我们说的可是纳秒级与毫秒级的差距——快上百万倍，具体数值取决于你对硬件的钻研程度。你的固态硬盘，哪怕是最新款的NVMe驱动器，还在等总线信号时，内存早已在高速公路上疾驰，引擎转速飙到极限，后备箱里塞满了炸药。你可曾尝试用冰冷的硬盘托管热门网站？这如同让瘾君子跑马拉松。RAM从不等待，从不乞求。它在操作系统尚未察觉时，便已从虚空中撕扯数据，猛然塞进CPU。其余一切不过是延迟与谎言。
WordPress如何运作？简单得很。请求像最后一杯酒的醉汉般猛撞443端口。Apache、NGINX、Litespeed——无论你派了什么门卫把守大门——接住请求，点头示意，再把它蹒跚送回PHP。这才是真正的肌肉。PHP唤醒WordPress，像油腻小餐馆的快手厨师般拼凑出请求的页面，再沿管道轰回最初敲门的那位。
但问题来了：这个看似无害的页面加载过程，实则经历了一场漫长的旅程。它触发文件系统，启动磁盘读取，探查数据库(数据库本身又会再次访问磁盘)，最终拼命挤进内存，刚好赶上被塞进CPU，再通过网卡喷涌而出。每次请求都是如此。
别跟我扯SSD、NVMe，或是你表哥那套自组的RAID集群——他毕竟懂点电脑。磁盘I/O永远是道坎。永远是延迟。永远是每次点击都拖着网站在泥潭里爬行的瓶颈。这不仅低效，简直是 敌对行为。必须彻底铲除。
因此我的理念是：去他妈的磁盘I/O。整个系统都该在内存里运行。不再有旋转的磁盘，不再有等待的缓冲区。直接加载到内存里，让它咆哮起来。别担心数据持久化，这事儿以后再说。也许吧。
调优方案概述
让我们拆解这个方案。
这绝非简单的WordPress安装。这是性能与所有拖后腿因素之间的铁拳对决。系统每个组件的部署都旨在打破常规，追求 性能突破。我们不用Docker或Kubernetes，不依赖apt更新，更不会像2007年那样在cPanel里点来点去。我们用Ansible配置裸机，用喷枪和焊枪打造堆栈的每个关键部件。
RAMDisk支撑的WordPress
WordPress根目录并非从磁盘读取。它挂载在Ansible配置时创建的tmpfs支撑的RAMDisk中。为何如此？
- 传统磁盘I/O——无论是SATA SSD、NVMe还是ZFS——都会为 每个 请求增加延迟。
- 即使经过良好缓存的文件仍需执行文件系统级权限检查、读取循环，有时还需重组碎片。
- 因为当WordPress完全驻留内存时，其运行速度堪称神速。
在配置阶段，Ansible会从对象存储(如R2或S3)提取已验证的站点归档文件(tar包)，将其解压至临时tmpfs挂载点(如/mnt/wordpress)。随后将NGINX根目录直接指向该内存盘。若机器重启，数据即刻消失。这并非缺陷，而是设计初衷。本站点旨在快速启动与终止，而非持久运行与衰减。
持久化操作发生在热路径之外。您可通过定时rclone同步任务备份数据，亦可选择不备份。无论哪种方式，运行路径都100%绑定内存，其速度足以令商业主机汗颜。
RAMDisk支撑的MariaDB
没错，你没看错。数据库同样驻留在内存中。零磁盘写入。零日志记录。零安全网。唯有纯粹、未经玷污的瞬时速度。
我们配置MariaDB将所有数据文件——包括ibdata、日志及表存储——存储于专用的tmpfs卷中，通常挂载在/mnt/mariadb等路径。这意味着：
- 所有表直接在内存中读写
- 查询或事务完全不产生磁盘I/O
- 临时表永不触及物理存储
- 索引、连接、缓存页——所有内容仅存在于RAM中
为何如此设计？
因为每次磁盘写入都是吞吐量的负担。因为页面加载不应受限于存储控制器。更因为这个架构秉持“速度优先，持久性次之”的设计理念——即便需要持久性，也需用户主动请求。
我们不依赖文件系统缓存，而是直接在内存之上构建数据库。
如何避免数据丢失？
我们将MariaDB视为实时演绎：
- 备份实现外部化。Ansible通过
rclone或mysqldump将热快照同步至对象存储(兼容S3)，支持定时或手动触发。 - 恢复操作具有幂等性。若机器崩溃，只需重新运行Ansible，它便会拉取最新备份并回滚至原位置。十秒后，业务即可恢复运行。
但若操作得当，目标并非让数据库永生不灭，而是要呈现WordPress有史以来最快的动态页面。
为何至关重要
传统主机将应用逻辑与数据库存储分离，而我们将二者整合至内存中。由此构建的WordPress架构具备以下特性：
- PHP读写MySQL的速度超越多数Redis缓存层
- 查询响应速度甚至快于传统主机触发磁盘队列的响应时间
- 若自动化配置得当，整个堆栈可在冷启动状态下于一分钟内完成全站加载
基于AMD EPYC(或Xeon)的Debian 12系统
Debian 12提供稳定现代的基础架构，行为可预测且支持长期维护。其默认软件包并非尖端版本，这恰是优势所在。我们不希望发行版自以为聪明，这些技巧我们自有Ansible来处理。
选择AMD EPYC是经过深思熟虑的决策。EPYC具备以下优势：
- 高内存带宽——对基于RAM的主机至关重要
- 大容量L3缓存——完美适配高频页面构建
- 核心功耗效率高——横向扩展时尤为关键
- IOMMU与NUMA感知能力——当扩展至集群规模时，可用于精细调整性能。
英特尔处理器虽可胜任，但EPYC在实现高吞吐量时能精准平衡性能与散热，避免发热问题。
手动编译NGINX
我们不采用apt install nginx。我们不信任维护者掌控运行环境。取而代之的是：
- 从nginx-quiche分支获取源代码(Cloudflare实现的QUIC与HTTP/3方案)
- 编译自定义模块，包括：
- Brotli：实现预压缩静态内容交付，相比gzip可削减15-25%负载
- ngx_devel_ kit + ngx_http_ lua_module：支持在配置文件中使用Lua脚本。可实现CSS/JS内联、执行认证逻辑或动态修改头部信息——无需调用PHP。
- 移除冗余模块：邮件、流处理、自动索引等。更小的二进制文件意味着更快的启动速度和更少的CVE漏洞。
最终获得的精简二进制文件专为以下场景优化：
- 内存级静态资源交付
- 低延迟TLS握手(HTTP/3完全省略TCP层)
- 无需WordPress路由的动态请求逻辑
同时需覆盖systemd单元文件指向/usr/local/nginx/sbin/nginx，确保自定义二进制文件不受软件包升级影响。
此方案使NGINX更像固件而非软件。
使用Ansible配置内存驻留WordPress
Ansible在配置阶段一次性完成部署：
- 安装依赖项
- 下载NGINX及模块源代码
- 根据指定参数编译所有组件
- 生成
nginx.conf、mime.types、fastcgi_params及 Lua 逻辑文件 - 将
/mnt/wordpress挂载为tmpfs - 从对象存储将压缩包解压至内存
- 配置 PHP-FPM 和 MariaDB
- 使 MariaDB 通过独立内存盘运行
- 部署 systemd 单元覆盖配置
系统运行时不存在编排机制，不会在用户不知情的情况下进行重配置。您只需声明所需环境，Ansible 便会像刷写 BIOS 般一次性构建完成。
此方案使基础设施具备可预测性、声明式特性及快速恢复能力。节点损毁？无妨。重新运行剧本即可。
堆栈安装指南
以下是配置 Ansible Playbook 的具体步骤：
操作前请先在云服务商处创建新虚拟机，推荐配置：8GB 内存 + 2 个虚拟 CPU。
1.) 克隆 Git 仓库。若通过命令行运行 Git，请执行：
git@github.com:rickconlee/wordpress-from-ram.git
修改以下文件以适配新服务器：
wordpress-from-ram/inventory.ini-template
wordpress-from-ram/site.yml-template
在文件中将“change me”或<your_var_ here>标记处替换为实际配置。
执行以下命令：
$ ansible-playbook -i inventory.ini site.yml
约10分钟后，整个技术栈将完成安装并部署全新的WordPress实例——所有内容均运行于内存中！
本文文字及图片出自 How To Run WordPress Completely From RAM
Pagespeed给这个人的网站评分72分：https://pagespeed.web.dev/analysis/https-rickconlee-com/foj4…
而我这个普通的WordPress网站得分为83：https://pagespeed.web.dev/analysis/http-egypt-urnash-com/a1r…
我的网站是2012年搭建的WordPress站点，持续运行至今。它运行在Apache服务器后端，安装了缓存插件，没有任何特殊配置。
推荐使用WP Super Cache插件[0]——它能生成预压缩的静态站点，随后可配置Web服务器[1]优先加载这些文件，或仅在缓存缺失时才将请求转交PHP处理。
在Pagespeed工具中分别获得97分和88分[2]。
[0] https://wordpress.org/plugins/wp-super-cache/
[1] [https://github.com/simonrupf/docker-php-wp/blob/master/etc/n…](https://github.com/simonrupf/docker-php-wp/blob/master/etc/nginx/location.d/wp _super_ cache.conf)
[2] https://pagespeed.web.dev/analysis/https-bobcat-dssr-ch/0ziq… / https://pagespeed.web.dev/analysis/https-simon-rupf-net/auk5…
虽然网站使用了CDN(Cloudflare)，但页面并未缓存(“cf-cache-status: DYNAMIC”)。有时这反而导致加载变慢，因为数据需要在<->Cloudflare<->服务器之间往返，而非直接访问服务器。
鞋匠的孩子没鞋穿。在自由职业巅峰期，我的网站永远排在最后。接的项目让我忙得不可开交，根本没空打理自己的网站。
这是Wordpress网站，页面速度达96分https://pagespeed.web.dev/analysis/https-www-storwell-com/wn…
对此我持怀疑态度。PHP Opcache已能将所有PHP文件加载编译至内存，仅需执行一次(或文件修改时重新加载)。这是WordPress站点最有效的优化手段(除运行在优质硬件上——多数主机商无法提供)。
MySQL/MariaDB同样具备强大的内存缓存机制——这些技术可不会停滞不前几十年…即便假设此方案有效，你完全可以采用数据库复制到另一台机器(甚至同一台机器上的其他容器)实现持久化存储。
而那些(很可能是AI生成的)色彩评论很快让人感到厌倦。
最关键的是，没有前后对比数据，这些测试毫无意义
讽刺的是，Cloudflare正阻止我访问该网站：
出于好奇，您知道Cloudflare为何封禁您吗？是浏览器完整性检测、IP信誉问题？我正尝试为静态网站放宽设置，希望能确保最大程度的访问畅通。
根据我对Cloudflare的经验，硬性封禁要么源于类似已知漏洞的行为，要么是网站运营方屏蔽了特定国家/IP范围。其他情况要么是烦人的验证码，要么是稍好些的“管理挑战”(通常是加载页面前的快速验证或手动勾选框)。
完全没头绪。纯净版桌面版和移动版Safari，有线和5G网络，全都遭封锁。
Cloudflare Ray ID: 98d7e0b319f3f390
我在Ubuntu 25.04的Firefox上被封禁，使用德国住宅FTTH线路；同时在Android 15的5G网络下，Firefox和Chrome均被封禁。
我使用德国主流运营商o2的手机访问网站时也遇到封锁，只是点击了Hacker News的链接而已…
此情况很可能是国家封锁，不让可恶的欧洲人阅读珍贵内容。使用美国VPN(IP信誉差)能正常访问，但德国本地运营商(IP信誉良好)无法访问。
挪威访问正常，所以应该不是国家封锁。通常封锁欧盟的网站也会封锁挪威。
英国也能访问。通过葡萄牙、法国、荷兰和丹麦的VPN也能访问。只有从巴西访问时被封锁。
同样情况。我的德国IP被封禁了。
我也被封禁了。我们所在的国家可能被作者通过CloudFlare屏蔽了。
Linux页面缓存+PHP-FPM OPcache已将常用PHP代码保存在内存中(预热后无需每次请求都访问磁盘)，若数据集可容纳于内存中，只需调整innodb buffer pool大小即可，无需将整个MariaDB数据目录移至tmpfs而牺牲持久性。
页面仅显示
抱歉，您已被封禁
您无法访问 rickconlee.com
为何被封禁？
本网站采用安全服务防御网络攻击。您刚执行的操作触发了安全防护机制。可能导致封禁的操作包括：提交特定词汇短语、SQL命令或格式错误的数据。如何解决此问题？
请邮件联系网站所有者告知封禁情况。请说明页面弹出时的操作内容，并附上本页底部显示的Cloudflare Ray ID。
Cloudflare Ray ID: 98d88522ad55dbab
您的IP地址: 2a02:3035:671:c0fa:cfc0:827c:68bc:ba8e
性能与安全由Cloudflare提供
谢谢Cloudflare！
我也被屏蔽了。我们所在的国家可能被作者通过CloudFlare设定了封禁策略。
另一种方案是启动前将所有内容复制到/dev/shm，就此收工。现在所有内容都从内存加载。更新只需将源目录内容复制回/dev/shm后重启即可。
这和文章记录的方法有什么区别？
我猜本质相同，只是我用约30个词表达了约2000词的内容，还少用了3.2MB数据来传达 🙂
让我想起MongoDB(至少早期版本)。速度快得惊人。直到崩溃导致数据丢失——剩下的只有尖叫。
我也曾在内存中运行MariaDB，但仅限于集成测试(数据本就是虚构的)。否则我敢说，仅靠系统管理员的小技巧，你不可能设计出比他们更优的方案。
我猜现代文件系统缓存到内存的技术已相当成熟，但普通网站难道不早就完全从内存提供服务了吗？如果代码+资源只有几兆大小，操作系统难道不会识别这是热数据且不会更新，从而在初始读取后就不再从磁盘读取？
我遇到过这类小型网站的性能问题：多数缓存系统针对大型企业或热门程序优化，导致每次加载都变成“异常”的冷启动场景。虚拟机需要唤醒，Cloudflare实际只在单点存储数据，HTTP缓存值无法合理设置，更糟的是文件仍需从磁盘读取。更糟的是，测试时因加载频率较高容易忽略此问题。虽然文件系统或服务器参数可调优，但我认为追求卓越性能的小型网站，终究需要在某个环节手动管理缓存。
问题并非出在Cloudflare仅在单点缓存数据，而是数据被缓存于距离最后发起请求的用户最近的边缘节点。地理位置不同的用户很可能访问完全不同的边缘节点，这些节点需要向源服务器获取数据来填充缓存。
Cloudflare的免费分层缓存选项对我的网站很有帮助。当本地边缘节点缓存缺失时，它有时能从其他Cloudflare服务器获取数据，而非始终请求源站，这有效减轻了源站负载。
同意需要调试和验证缓存机制，我PHP网站最大的优化之一就是调整apc/OPcache缓存大小。
对于小型冷门网站，Cloudflare反而会拖慢TTFB(首次字节时间)，因为它们不会与源服务器保持Keepalive连接。这意味着从Cloudflare POP到源服务器的TCP/TLS建立成本更高，反而不如直接连接。我曾尝试部署智能Worker和cloudflared，但均未见成效。
他们本可启用保持活动连接，但小型网站在边缘节点流量不足，难以维持连接。
难道你不认为TTFB的小幅延迟是值得的代价，毕竟CDN能带来更优的扩展性？
如今已不是无需担心机器人流量构成DDoS攻击的时代了。网站无法响应的后果远比额外的TCP/TLS配置严重得多。
> 文件是从磁盘读取的。
这里说的磁盘是指旋转的机械硬盘，还是指NVMe固态硬盘？两者的延迟差异相当巨大。
代码中包含必须执行的数据库调用，涉及读写操作。处理器固然精密，但若它们(更准确地说，它们与操作系统)真有如此智能，WordPress安装速度理应默认更快。
这或许不足为奇——想想看：典型服务器除了托管特定WordPress站点外，还承担着大量其他任务。
取决于数据/资源的数量。由于所有AI机器人，默认缓存很容易不足，因为网站不再存在访问最频繁的URL，每个URL(及其查询参数组合)最终都成为高频访问对象。
该网站被Cloudflare感染，无法查看文章。
页面速度评分已反映此问题。即便数据驻留内存也无济于事，因为多数页面/加载本就通过CDN和缓存完成。
服务器同样会将高频请求数据放入内存。
> 大部分页面/加载本就会通过CDN和缓存处理
并非总是如此。多数网站CDN(本质是反向代理)默认不缓存页面，以防止私有内容外泄。必须手动启用/配置缓存规则。
本例中Cloudflare未缓存HTML：“cf-cache-status: DYNAMIC”。若启用页面缓存，状态应显示为“HIT”或“MISS”。
若能提供标准安装与内存运行模式的性能对比就更好了。
内存成本高昂。通过为非认证流量启用NGINX fastcgi缓存，甚至完全绕过PHP处理，就能获得显著提升。
AI垃圾——顶部是AI生成的图片，正文充斥着破折号和ChatGPT式表达。
更明显的破绽是文章半数篇幅充斥着毫无必要的夸张填充…
此处的加速效果绝大部分源自数据库，而将其部署在tmpfs上简直易如反掌。使用Docker时，只需一行命令即可实现！例如：
docker run -d –tmpfs /var/lib/mysql -p 127.0.0.1::3306/tcp -e MYSQL_ROOT_ PASSWORD=[password] mariadb:11.8
当然，要使这种方案合理，必须建立完善的备份机制。
哇，真酷！之前完全不知道–tmpfs参数(我提交这篇文章是因为觉得有趣，但并非原作者)
我快速浏览了下，感觉就像让ChatGPT放飞自我写“有趣”内容时的风格。
“让我们拆解这首曲子。这绝非简单的WordPress安装，而是性能与所有拖慢它的因素之间的一场铁拳搏斗。”
为什么不直接用反向代理将页面缓存到内存，或者用Cloudflare之类的方案？
强制提醒——2025年别用WordPress。
采用无头CMS加静态网站生成器方案，例如Strapi搭配Astro。
但WordPress确实具备企业级惯性/网络效应，就像Jira、Jenkins和Java(及其他技术)那样。
长期以来WP早已不再只服务于“代码即诗歌”的极客群体——尤其在近期深陷争议后更是如此。默认选择WP的人看重的是海量插件生态，无论是Shopify集成还是营销活动的精细化追踪。他们根本无法理解为何有人偏爱“无头架构”。在他们眼中，静态网站如同被Y2K彗星灭绝的恐龙。
我们固然可以争论WP是否“最佳方案”，但它无疑是最能开箱即用的解决方案。你选择的CMS或许也提供现成的通用方案，但我怀疑它能否应对市场总监用那套老旧可靠的集成服务必然引发的边界案例。Shopify+Google Analytics+Salesforce+Airtable[1]在WP上始终运行良好，可突然间这个号称更优的“无头”CMS竟频频抛出各种愚蠢错误。
若插件缺失，总有WP/PHP开发者能以合理价格定制解决方案。反观你提到的Strapi和Astro，恕我直言，这还是我第一次听说。
我并非赞同现状，但若有人委托我搭建WP站点，我会提供经过强化防护的EC2服务器，运行Apache/NGINX环境下的WP。然后我就能继续处理更重要的事务了。
[1] 仅举例说明。
虽然WP并非我的首选，但将二元答案作为唯一事实依据也不妥当。
无论个人偏好或理解如何，总会有大量Strapi、Astro或其他方案无法实现的需求。
永远存在“大多数情况”的例外。我认为WordPress在全新项目中已无用武之地。若项目规模微小到无需内容管理系统，纯HTML才是更优解。反之“大多数情况”下，无头内容管理系统才是更佳选择。
你是否接触过非技术用户？目前几乎没有(至少我所知范围内)静态网站生成器能满足大型企业传播团队的友好性需求。值得注意的是，Strapi还将单点登录等核心功能设置为企业付费墙后…这本身就是重大缺陷。
WordPress自有其价值，对互联网上最受欢迎的内容管理系统之一一概否定，未免过于武断。
这种观点可以理解，但DIY并非多数人的首选方案。
> 它挂载在基于 tmpfs 的 RAMDisk 上
> 因为即使缓存良好的文件仍需文件系统级权限检查、读取循环，有时还需重组碎片。
我以为 tmpfs 仍需文件系统级权限检查，还是我理解有误？
我认为他们指的是缓存文件的元数据检查仍需访问磁盘。若此情况始终成立我会感到惊讶，但除此之外我实在无法理解其他可能。