共享主机网站为什么变慢：LVE 限制、503 错误与 PHP X-Ray

网站突然变得卡顿，或者访客看到了 503 Resource Limit Reached 错误。很多人的第一反应是怪服务器，或者直接换更大的套餐。但在共享主机上，原因通常出在您的应用内部，而借助 cPanel 中现成的工具，您自己几分钟就能找到问题所在。

您的账户运行在独立容器中

每个 WebGee 共享主机和经销商账户都运行在各自的轻量级虚拟环境（LVE）中，这是一种资源限制固定的 CloudLinux 容器。如果某个账户的脚本失控或遭受攻击，它会被限速或进程被终止，而其他账户照常运行，不受影响。设置这些限制，就是为了让别人的问题永远不会变成您的问题。

除非您的套餐另有说明，每个账户的配额如下：

• CPU：1 核
• 内存：1 GB
• 入口进程：30 个并发

完整说明请参阅 CloudLinux 与 LVE 限制详解。

根据症状判断触及了哪项限制

每项限制被触及时的表现各不相同，这能帮您判断该从哪里查起：

• CPU：网站变慢，但请求仍能完成。
• I/O：网站变慢，涉及大量磁盘读写的操作尤其明显。
• 入口进程（EP）：出现 503 错误，因为请求会被直接终止。
• 物理内存（PMEM）：出现 503 错误，或进程被终止。

CPU 和 I/O 限制会拖慢网站，入口进程和内存限制则会让网站直接无法访问。网站卡顿和返回 503，触及的并不是同一项限制。

为什么慢网站更容易耗尽入口进程

入口进程是指账户内当前正在处理的请求。这项限制针对的是同一时刻能运行多少个请求，既不是每小时，也不是每位访客。一个 PHP 请求通常不到一秒就能完成，完成后名额会立即释放。

问题在于，每个请求耗时越长，触及限制所需的访客就越少。一个耗时 5 秒的页面，占用名额的时间是 200 ms 页面的 25 倍。一旦请求开始排队，页面会变得更慢，占用名额的时间也更长。正是这种恶性循环，让网站往往是突然崩溃，而不是逐渐变慢。

超出限制的请求会被内核以 SIGKILL 终止，访客就会看到 503 错误。常见的诱因都是长时间运行的任务：

• 需要运行好几分钟、却每分钟执行一次的 cron 任务
• 随页面加载触发的 WP-Cron
• 每个请求都会发起缓慢外部 API 调用的插件
• 没有索引的数据库查询

更多详情请参阅 什么是入口进程。

查明触及了哪项限制

先打开 cPanel → Resource Usage。这里会显示触及了哪项限制、发生在什么时间，以及当时有哪些进程在运行。

1. 在 cPanel 中打开 Resource Usage。
2. 选择涵盖网站变慢、出现 503 错误或收到告警邮件的时间段。
3. 查看触及的是哪项限制：CPU、I/O、入口进程还是内存。
4. 打开该时刻的快照，其中会列出导致问题的进程。

快照能帮您从症状追溯到原因。如果故障集中在某个特定时间点，接下来请检查 cPanel → Cron Jobs，因为执行间隔很短的重负载任务是常见的罪魁祸首。

完整操作步骤请参阅 收到资源使用告警怎么办 和 解决 503 Resource Limit Reached 错误。

用 PHP X-Ray 追踪慢请求

Resource Usage 告诉您触及了哪项限制，PHP X-Ray 则告诉您请求内部的时间花在了哪里。它会追踪真实请求并逐项拆解耗时，让您不必再猜测问题出在插件、数据库查询还是外部调用上。共享主机、经销商主机和 Premium 主机均可使用该功能。

1. 在 cPanel 中打开 X-Ray。
2. 选择要追踪的域名或子域名。
3. 填写您自己的 IP 地址，将收集的请求数设为 10–20，并选择一个足够复现卡顿的时间范围。
4. 开始追踪，然后在浏览器中多访问几次那个慢页面。
5. 等 Collected Requests 列出现数据后，打开收集到的追踪结果。

重点排查以下几种情况，大致按出现频率从高到低排列：

• 同一条慢数据库查询被重复执行多次，通常是插件在循环中执行查询。启用对象缓存往往就能直接解决。
• 缓慢的外部 HTTP 调用，例如插件连接授权服务器或某个 API。在调用返回之前，页面无法完成加载。
• 某个插件占用了绝大部分时间。将其禁用后再追踪一次，即可确认。

带截图的详细步骤请参阅 找出拖慢网站的原因。

别把 PHP memory_limit 当成账户限制

memory_limit 限制的是单个 PHP 脚本可以分配的内存。您可以在 cPanel → Select PHP Version → Options 中修改它（参阅 更改 PHP 版本和设置）。在导入大量数据、处理大尺寸上传图片、运行商品目录庞大的 WooCommerce 商店，或应用文档明确要求更高内存时，适当调高是合理的。

但它并不会提高账户的内存限制。账户内存限制由您的套餐决定，也正是它导致了 503 错误。把 memory_limit 设得高于账户配额毫无意义，因为脚本一旦达到账户限制，无论如何都会被终止。

正常的 WordPress 页面加载在 128–256 MB 内就绰绰有余。如果您的首页需要 1 GB，说明有东西加载了远超所需的内容：可能是插件在不加限制地查询、出现了无边界的循环，或者每个请求都在处理图片，而不是只在上传时处理一次。调高任何数值之前，请先用 X-Ray 追踪一下。

要查看实际生效的值，可以创建一个包含 <?php echo ini_get('memory_limit'); 的 PHP 文件，访问后再将其删除。在 Bolt-Cache 下，PHP Selector 的设置会被忽略，实际值取自 .user.ini。更多内容请参阅 了解 PHP 内存限制。

把资源占用降下来

先从应用入手。按以下顺序操作，大多数问题都能得到解决：

1. 启用缓存。缓存的页面不会经过 PHP，因此也不会占用入口进程。先从 LiteSpeed Cache 开始，再为已登录用户和后台管理区域加上 Redis 对象缓存。
2. 排查插件。先禁用全部插件，等待几分钟，然后一边观察 Resource Usage，一边逐个重新启用。
3. 修复 cron 任务。WP-Cron 在页面加载时运行，在高负载下这种机制并不合适。请 用真正的 cron 任务替代 WP-Cron，并延长其他重负载任务的执行间隔。
4. 检查异常流量。机器人和爬虫消耗的资源与真实客户一样多。
5. 扫描恶意软件。被入侵的网站会把资源浪费在替别人干活上。请 扫描网站中的恶意软件。

赶在访客之前发现问题

cPanel 中的 Site Quality Monitoring 会每小时检查一个域名的在线状态，并每周进行一次全面的健康与性能扫描，查找失效链接、缺失的元数据、慢页面和混合内容。该功能默认关闭，需要创建项目后才会启用：

1. 在 cPanel 中选择 Site Quality Monitoring。
2. 选择 Monitored domain，并填写用于接收通知的 Email Address。
3. 勾选同意框，然后点击 Create Project。

请使用不托管在被监控账户上的邮箱地址，否则宕机告警可能永远无法送达。监控看到的是访客视角，因此无法告诉您页面为什么慢。如果它报告间歇性宕机，请检查 Resource Usage，因为原因往往是资源限制，而不是服务中断。

设置详情请参阅 Site Quality Monitoring。

什么时候升级才是正确选择

请先诊断，再升级。升级只会抬高上限，并不能解决消耗资源的根源，失控的插件只会消耗得更多。如果 Resource Usage 快照显示是正常流量在执行正常任务，那么就可以提高限制，这正是 Elastic Cloud 套餐的用武之地。提交工单时附上您的 Resource Usage 数据，WebGee 会为您提供建议。