跳到内容 
网络托管内存 决定一个页面有多少并发进程，以及处理请求的顺畅程度，而 CPU 和 输入/输出 决定了计算和数据流的速度。我将解释多大的内存才是合理的，内存大小、CPU 性能和 I/O 速度如何相互影响，以及我在实践中设定的优先级。
中心点
预祝 我将简明扼要地总结最重要的研究成果。
- 内存大小 决定并行运行的进程数量。
- CPU 即使内存很大，每秒的计算量也会受到限制。
- 输入/输出速度 决定了快速数据访问和高速缓存的优势。
- 山峰 比平均值更重要。
- 缩放 在成本和效率方面都胜过过大。
什么是虚拟主机内存 - 简要说明
内存 RAM 可作为服务器的快速短期内存，用于运行进程、缓存内容和活动会话。当许多 PHP Worker、数据库查询或缓存层并行运行并需要快速访问时，RAM 总能让我受益匪浅。缺失 记忆当应用程序达到极限时，进程会中止，服务器不得不主动交换到速度较慢的磁盘。这会导致上传、备份或图像处理过程中的时间损失、响应时间延长和错误。如果有足够的 缓冲器 我可以处理峰值负载，将会话保存在内存中，并实现流畅的内容管理系统工作流程。
为什么 "免费 "内存很少真正免费
未使用 在生产运行中，内存很少被浪费。现代操作系统将空闲内存用作文件系统缓存，将经常读取的文件、静态资产和数据库页面保存在内存中。这样可以减少 I/O 访问并稳定延迟。在监控工具中，这通常表现为 "几乎没有空闲"，尽管内存在需要时会立即释放。因此，我不仅要评估 "空闲 "内存，更重要的是评估 "可用 "内存或系统能在短时间内释放的内存比例。如果这个比例一直很低，而 I/O 等待时间却在增加，这就表明内存压力确实很大，并有可能出现以下情况 惊涛骇浪 (不断交换/存储）。健康的文件缓存缓冲区会直接影响内容管理系统和商店的性能。
估算 RAM 大小：从博客到商店
更大 并不会自动变得更好，因为未使用的内存只会花钱，而且没有任何作用。我从实际大小开始，测量负载峰值，然后逐步增加，而不是盲目出价过高。小型网站通常只需 1 GB 内存即可正常运行，而带有大量插件的内容管理系统、WooCommerce 商店或论坛则很快就需要 2-4 GB 或更多。同时使用的用户、导入和图像处理、缓存策略和数据库工作量都很重要。计划 获能避免 500 错误、超时链和昂贵的超大尺寸。
| 网站类型 | 建议内存大小 |
|---|---|
| 简单的静态页面 | 64-512 MB |
| 小型内容管理系统网站 | 1 GB |
| 公司中层 | 2-4 GB |
| 精心设计的网上商店 | 4-8 GB+ |
| 大型社区平台 | 8 GB+ |
PHP 内存限制、工作者和实际上限
PHP 内存限制 定义的是每次请求的上限，而不是实际消耗量。256 MB 的限制并不意味着每个进程都要使用 256 MB，许多进程都远远低于这一上限，但个别峰值可以加以利用。对于 PHP-FPM 我使用每次请求的平均消耗量来计算工作者的数量：我测量了实际的负载情况（前台、结账、管理），然后设置了 pm.max_children 以便为网络服务器、数据库、缓存和文件缓存提供足够的空间。我还限制 pm.max_requests以减少蠕变泄漏。OPcache、对象缓存（如在 RAM 中）和数据库缓存需要各自的预算，我将其纳入总体计算。结果是：吞吐量稳定，502/503 错误减少，延迟高度可预测。
RAM vs. CPU vs. I/O：相互作用
平衡 beats单一值--如果中央处理器的计算速度不够快或 I/O 速度减慢，那么大量的 RAM 也就没有什么用处了。强大的 CPU 可以快速处理 PHP 请求、压缩和数据转换，这意味着可以更好地利用 RAM 缓存和数据库。如果 CPU 较弱，即使内存仍然空闲，请求也会卡住。I/O 速度决定了数据在内存、固态硬盘/NVMe 和网络之间流动的速度；缓慢的 I/O 会消耗内存的优势。我还会检查 CPU 的线程策略，因为 单线程与多核 影响我的堆栈并行工作的程度。
调整中的实际优先事项
- 第一个高速缓存页面缓存先于数据库，OPcache 先于 CPU 调整，对象缓存先于 RAM 增加。
- 那么吞吐量PHP：设置与 CPU 和内存相匹配的 PHP Worker 数量；在扩展前消除慢速查询。
- I/O 制动器 解决：日志轮换、解耦图像任务、将备份时间窗口转移到低流量阶段。
- RAM 缓冲区 保持文件缓存：我避免激进使用缓存，以保持快速读取。
- 保护限制合理的上传限制、超时限制和队列，而不是并行过度。
认识和避免典型瓶颈
症状 找出原因：500 错误、空页面或上传失败通常表明 RAM 或 PHP 内存有限。如果 I/O 等待时间增加，服务器可能正在从 RAM 向磁盘写入数据，从而耽误了时间。图像处理过程中后台速度慢，说明内存不足或 I/O 速度慢。我使用内存利用率、I/O 等待、CPU 负载和响应时间监控来评估趋势，而不是快照。通常只需 增加 PHP 内存限制缓存，并在需要升级硬件之前删除不必要的插件。
监测实践：我实际测量的内容
接近系统 我监控可用内存（"可用"）、文件缓存共享、交换利用率、I/O 等待和上下文切换。在应用程序层面，我对 PHP Worker 使用率、队列长度、OPcache 命中率和对象缓存命中率感兴趣。在数据库中，我会检查缓冲区大小、临时表大小和同时连接数。结合响应时间分布（中位数、P95），我就能识别出是少数几个大请求正在中断，还是整个堆栈正在承受负载。我定义了具有滞后效应的警告阈值（例如 80% RAM > 10 分钟），以避免误报，并将峰值与 cron 作业、导入或备份相关联。
WordPress、插件和数据库：什么会真正占用内存？
WordPress 主要通过对象缓存、图像处理、备份和插件多样性从内存中获益。每个插件都会加载代码和数据，增加 PHP 内存预算，并可维持瞬态或缓存。当生成多种尺寸或构建 WebP 格式时，媒体工作流程需要额外的内存。数据库需要缓冲区来进行索引和查询；如果同时使用的用户数量增加，这些缓冲区也会随之增加。这就是我保留增长空间、优化查询计划、尽量减少插件开销以及有针对性地使用 OPcache 和对象缓存的原因，以便 存储负荷 仍可规划。
正确维度 OPcache、页面缓存和对象缓存
OPcache 减少了 CPU 和 I/O 负载，但对于大型代码库来说，需要几百 MB。我注意充分 内存消耗 和内部字符串的比例，从而避免强制重新编译。字符串 页面缓存 将负载从 CPU/DB 转移到 RAM/存储--非常适合重复页面浏览。过短的 TTL 会错失良机，过长的 TTL 会导致内容陈旧；我会根据更改频率来平衡 TTL。我根据更改频率来平衡 TTL。 对象缓存 (例如，在 RAM 中持久化）可大大降低数据库命中率，但需要明确定义的大小和驱逐策略。如果命中率随着内存利用率的提高而下降，我就会分配更多内存或缩小缓存键，以便将热数据保留在内存中。
实用指南：如何实际计算内存
程序 而不是速率：我检查当前的峰值负载，即每秒请求数、并发用户数和一天中最繁忙的进程数。然后，我确定每个 PHP Worker 和每个 cron/import 作业的典型内存消耗量，并为峰值添加安全系数。我会考虑文件大小和上传图片的数量，因为缩略图和转换会占用内存。对于 WordPress，我至少使用 1 GB 内存，对于 WooCommerce 和有许多扩展功能的网站，通常使用 2-4 GB 内存，如果流量大，则使用更大的内存。升级选项仍然很重要，这样我就可以 根据需要 在不停机的情况下向上扩展。
抽样计算：从 RAM 到 PHP 工人数
接受总内存为 2 GB。我保守地为操作系统、网络服务器、OPcache、对象缓存和文件缓存保留了 700-800 MB。这就为 PHP Worker 和峰值留出了 ~1.2 GB 的空间。测量结果是平均每个请求 120 MB，个别峰值可达 180 MB。
- 基线1.2 GB / 180 MB ≈ 最坏情况下 6 个工人。
- 实际操作1.2 GB / 120 MB ≈ 10 个工人，我设定为 8-9 个，以便为高峰期和后台作业留出空间。
- pm.max_requests 到 300-500，以消除泄漏和碎片。
如果负载增加，我首先会增加内存（更多缓冲区、更多 Worker），然后是 CPU 内核（更多并行处理），最后是 I/O 容量（如果 I/O 等待时间增加）。对于导入或图像任务，我会对并行性进行控制，以免前端用户受到影响。
I/O 速度：托管中的固态硬盘与 NVMe
输入/输出 这决定了内存缓存的运行状况、数据库的交付速度和备份的运行速度。NVMe 硬盘的延迟明显低于传统的固态硬盘，因此减少了对内存和 CPU 的负载，因为所需的维护更少。如果您移动了大量的小文件、日志或会话，您会立即在后台和加载页面时注意到这一点。我会检查提供商配置文件中的 NVMe 存储和合理的 I/O 限制，这样就不会在错误的地方对堆栈进行节流。我将在比较中详细介绍介质和延迟问题 固态硬盘与 NVMe因为存储技术 吞吐量 影响很大。
交换、OOM 杀手和安全缓冲区
交换 不是一个性能特征，而是一个安全气囊。较小的交换区可以缓冲短时峰值，并最大限度地减少 OOM 杀手 会突然终止进程。然而，永久交换意味着大量 I/O 丢失和延迟增加。与慢速固态硬盘相比，NVMe 造成的损失较小，但仍然很明显。我会保持适度的交换率，规划足够的 RAM 缓冲区并监控交换利用率；如果交换经常发生，我会缩减或均衡作业。在共享或容器环境中，cgroup 限制适用--超限会更快地导致 OOM 事件，这就是为什么保守的工作者数量和硬限制尤为重要的原因。
扩大规模，而不是过大：升级策略
缩放 这样既能节约成本，又能保持性能的可预测性。我从保守的内存大小开始，定义明确的阈值（例如，80% 使用率超过 10 分钟），然后计划升级。同时，我会优化缓存 TTL，减少不必要的 cron 时间间隔，并通过索引和查询缓存缓解数据库压力。如果流量出现意外增长，我会首先增加 RAM 缓冲区，然后增加 CPU 内核以提高吞吐量，最后在等待时间增加的情况下提高 I/O 容量。如果能注意到这个顺序，就能避免错误的投资，并加强 响应时间 在负载情况下。
扩展变量：共享、VPS、专用、群集
共享主机 提供方便，但对 RAM、CPU 和 I/O 有严格限制；适合中小型项目，缓存稳固。 VPS 可对内存分配、PHP-FPM、OPcache 和缓存进行更多控制--如果我想对工作者和服务进行微调，它是理想之选。 专用 可提供最大储备量和恒定 I/O，但只适用于长期高负载或特殊要求。 群组 WordPress/shop堆栈可以横向扩展，但需要无状态设计：将会话从 RAM 移至中央内存、同步媒体并使缓存失效。对于 WordPress/shop 堆栈，我计划将对象缓存和会话放在网络服务器之外，这样额外的节点就不会因为与内存相关的状态而失效。
绩效检查：我定期检查的关键数据
衡量标准 让瓶颈显而易见，并显示升级对哪些方面有真正的帮助。我监控内存使用率、页面缓存和对象缓存命中率、I/O 等待、CPU 负载（1/5/15）以及中位数和 P95 响应时间。随着内存使用率的增加，缓存命中率下降，这表明应为缓存分配更多内存。I/O 等待时间长，CPU 空闲，说明存储存在瓶颈，NVMe 或更好的限制可以解决这个问题。如果长期使用 PHP Worker，我会增加 CPU 内核或减少昂贵的请求，以便 吞吐时间 水槽
警报和跟踪：合理设置阈值
通知 我仔细计划：内存 > 85%，I/O 等待时间超过定义的阈值，只有在条件持续时间较长时才会触发。我跟踪 P95/P99，而不仅仅是中位数，这样就能看到异常值。在数据库中，我使用慢查询分析和连接峰值；在 PHP 中，我监控最大的内存罪魁祸首，并通过以下方法限制其寿命 pm.max_requests.在维护窗口，我会比较更改前后的跟踪记录，以便将真正的改进与测量噪音区分开来。这样，当内存升级实际上是缓存、索引或 I/O 限制的问题时，我就能避免盲目升级。
供应商选择：我在 RAM 报价中寻找什么
选择 如果我设定了明确的标准：内存小步扩展、公平的 I/O 限制、当前的 CPU 代数和 NVMe 存储，我就能更快地取得成功。好的收费标准允许灵活升级，提供透明的衡量标准，并提供足够的 PHP 工人。对于高产能的 CMS 和商店堆栈，我更倾向于 2-4 GB 内存以上的选择，具体取决于峰值行为。在许多比较中，webhoster.de 脱颖而出，因为内存选项、CPU 设备和 NVMe 存储设备共同构成了一个连贯的整体套餐。这就是我如何确保 绩效 对于不断增长的项目，无需进行耗时的迁移。
简而言之：我的建议
优先事项 我的设置如下：首先测量瓶颈，然后有针对性地平衡内存、CPU 和 I/O。我为 WordPress 规划了至少 1 GB 的内存，为大型商店或社区规划了 2-4 GB 的内存，为真正的高峰期规划了更大的内存，并始终提供升级选项。CPU 性能和 NVMe 存储可提高内存的优势，因为计算运行速度更快，数据到达速度更快。在增加硬件之前，我会持续关注监控、缓存策略和插件卫生状况。通过这种方法，我实现了 可靠 性能，控制成本，并始终保持可扩展性。
