内存容量的经验估算公式

先给结论：业务内存 ≈ 常驻服务基准 + 峰值并发数 × 单连接开销，再预留 20% 余量。这个公式不精确，但比"感觉 4G 够了"可靠得多。 一、按角色给系数 不同服务吃内存的方式差别很大。Web 应用按进程算：每个 php-fpm 进程大约 30-80MB，Java 应用直接按 -Xmx 上限估算。MySQL 把 innodb_buffer_pool_size（InnoDB 缓冲池参数）设为物理内存的 50%-70%，这一项就是大头。Redis 用 maxmemory 限住上限，配置多少占多少。系统本身和页缓存再留 1GB 上下。把各项加起来，基数就有了。估算时把常驻进程列成清单逐项填，监控 agent、日志采集这类小进程漏掉了，累加起来也有几百 MB。 二、为什么预留 20% Linux 会把空闲内存拿去做页缓存，内存塞满时缓存被回收，磁盘 IO 立刻上升，性能断崖式下跌。看内存用 free -h 的 available 列而不是 free 列，available 长期低于总量的 20%，就该安排扩容了。swap 频繁使用是性能毒药，一旦开始换页，响应时间放大几十倍，宁可提前扩容。 三、推演一个例子 一个论坛峰值并发 200，每个请求平均开销 15MB，PHP 常驻约 1GB，MySQL 缓冲池设 3GB：1 + 200×0.015 + 3 ≈ 7GB，预留两成后约 8.4GB。对应 8G 内存的机器就很紧张，直接上 16G 更稳妥；中等规模业务选高防云服务器 S4-8G 起步再观察也是常见做法。要是论坛还带图片附件和全文搜索，再各加 1GB 缓存预算。 四、监控与调整 内存是最容易线性扩容的资源，云服务器升配即可解决。日常监控盯三个信号：available 占比、swap（交换分区）是否被使用、OOM Killer 有没有动过进程，最后一条用 dmesg | grep -i oom 一查便知。扩容前做一次内存压测，模拟峰值并发跑十分钟，看 available 的最低点，这个值乘以一点二就是该有的容量。每次扩容把当时的公式参数记录下来，下次估算直接引用。 估算公式只是起点，跑起来之后要用真实数据修正它。公式算出的数和实测对不上时，以实测为准，公式只负责第一步的粗估。每月看一眼内存曲线，比任何公式都准。