服务器脚本内存设置没有万能数字，但有一个相对稳妥的起点：单个脚本进程的峰值内存控制在物理内存的一半以内，同时给系统和页缓存留出两成左右的空间，剩下的再按并发数分配。 这条规则适用于绝大多数 Web 业务和定时任务，比凭感觉填一个 512M 或者直接写 -1 要靠谱得多。
先分清三层内存限制，否则调了也没用
很多人在 php.ini 里把 memory_limit 改到 1G，结果进程还是被杀掉，原因就是只动了最上面一层,脚本的内存限制其实有三道闸门。
语言运行时层：管的是脚本自己
PHP 的 memory_limit、Node 的 --max-old-space-size、JVM 的 -Xmx 都属于这一层，脚本申请超过上限，通常是脚本自身报错退出，进程还活着,这一层从来不是进程被杀的直接原因。
进程与服务层：决定单个服务能拿多少
systemd 的 MemoryMax、容器 cgroup 的 memory.max、ulimit -v 都在这一层，越界的后果是服务被强制终止，日志里常看到 cgroup out of memory 字样。
整机层：内核 OOM Killer 的最后裁决
物理内存真的不够时，内核会挑一个占用大的进程杀掉，查证方式是 dmesg | grep -i "killed process" 或 journalctl -k | grep -i oom。
| 限制层 | 典型配置位置 | 生效范围 | 越界后果 |
|---|---|---|---|
| 语言运行时 | php.ini、启动参数 | 单次脚本执行 | 脚本报错，进程存活 |
| 进程/服务 | systemd、容器 cgroup | 单个服务 | 服务被终止 |
| 整机 | 内核 OOM Killer | 所有进程 | 随机杀掉大内存进程 |
看这张表就明白：调大 memory_limit 只是让脚本敢多用内存，真正能不能用,得看下面两层给不给。
不同语言栈，脚本内存设置多少合适
PHP脚本内存限制设置多大合适
这是搜索量最集中的问题之一，按实际业务类型给区间,比抄一个固定值有效：
- 普通接口和小型站点：
128M到256M足够，峰值通常在几十兆管理系统、带插件的中型应用：256M到512M - 图片处理、批量导入、报表导出：
512M到1G，并且这类任务应该走 CLI 队列而非 Web 请求 - 不建议写成
-1，等于放弃了保护，一个死循环能把整机拖垮
改完用 php -i | grep memory_limit 确认生效，压测期间在代码里打印 memory_get_peak_usage(true)，拿到的才是真实峰值,别靠估算。
Python、Node 这类没有默认上限的脚本
Python 进程默认不受语言层约束，只受系统层限制，所以更靠谱的做法是直接给它套一个 cgroup 或 systemd 单元：
[Service]
MemoryHigh=800M
MemoryMax=1GMemoryHigh 是软阈值，超过后内核会施压回收；MemoryMax 是硬上限，Node 在较新版本中会读取容器 limit 自适应堆大小，但如果跑在裸机上，仍需手动指定 --max-old-space-size。
JVM 系不能照搬同一套算法
Java 服务除了堆，还要占 Metaspace、线程栈、直接内存和 JIT 代码缓存，行业共识认为，-Xmx 设为容器内存上限的七成上下比较安全，剩下三成留给堆外开销，把堆设成和 limit 一样大,是最常见的翻车方式。
云服务器脚本内存设置多少合适
共享型实例要更保守
云服务器里的突发性能型、共享型实例存在资源争抢，标称 2G 不代表随时能拿到 2G，近年来不少用户在共享型实例上跑脚本遇到偶发 OOM，排查下来并非自己的代码有问题，而是可用物理内存被挤压，这类机器上,脚本上限建议比独享型再往下压一档。
容器里的 limit 必须和运行时联动
docker run -m 1g 只设了 cgroup，容器内的进程读取 /proc/meminfo 时，老版本运行时看到的是宿主机总内存，脚本就会按大内存自我扩容，然后被 cgroup 杀掉，K8s 里对应 resources.limits.memory，同时要把语言层上限设得略低于这个值,形成梯度保护。
云服务器内存升级费用大概多少
这个问题的答案取决于计费方式，而不是一个固定数字，包年包月升配通常需要重启实例，按量付费则按实际使用时长结算；多数云厂商的内存与 CPU 是捆绑售卖的，单独加内存的选项较少，实际决策时，把“垂直升配”和“加一台实例、把脚本拆开跑”两条路的月度成本放在一起比，往往后者更划算，尤其是脚本本身可以并行拆分的时候，具体价格以各厂商价格页为准，不同地域、不同可用区差异明显。
内存过高怎么办：先看信号，再动手改
Python脚本内存占用过高怎么排查
按这个顺序走,基本能在半小时内定位方向：
- 先看谁在吃内存：
ps aux --sort=-rss | head -20 - 再看增长曲线：对目标进程的
VmRSS做定时采样，判断是阶梯式上涨还是一直线性上涨 - 阶梯式上涨通常是缓存池没有上限，线性上涨更可能是对象没有释放
- 用
py-spy dump --pid <pid>看调用栈，或开tracemalloc抓分配点 - 数据处理类脚本重点查是否整表读入，改成
chunksize分批 - 装饰器缓存检查是否漏了
maxsize
三个高频“假泄漏”
- 数据库连接池、HTTP 连接池没设上限，请求量一大就膨胀
- 日志 handler 持有对象引用，尤其是自定义 handler
- 子进程创建后没回收，父进程的进程表持续增长
这三类在监控曲线上都表现为内存缓慢爬升，但根因不在 Python 解释器。
内存过低的两类表现与处置
第一类是频繁换页：vmstat 1 里 si、so 持续非零，说明物理内存吃紧，性能已经开始塌方，第二类是直接被 OOM：进程无声消失,只有内核日志留痕。
处置顺序建议固定：先降并发、限队列长度，这是最快见效的；再确认运行时上限是否设得过高或过低；最后才是扩容，反过来先扩容,往往把问题掩盖几个月。
脚本内存限制和物理内存比例怎么配
单机多脚本的分配公式
用一句话概括：实测峰值 × 并发数 + 系统预留 ≤ 物理内存，系统预留一般按两成算,同机还跑数据库的话要再抬高一档。
一个粗略的对照区间
| 物理内存 | 单脚本建议上限 | 可并发脚本数（估算） |
|---|---|---|
| 2G | 256M | 4 到 6 |
| 4G | 512M | 6 到 8 |
| 8G | 1G | 8 到 10 |
| 16G | 1G 到 2G | 10 到 16 |
表里是经验区间，不是标准答案，真实值必须用压测峰值去校正，尤其是图片、视频、大数据量导出这类任务,峰值可能是均值的数倍。
今天就能执行的五步落地
- 用
free -m记录当前可用内存，作为基线 - 用
/usr/bin/time -v python script.py或memory_get_peak_usage(true)抓真实峰值，重点看Maximum resident set size - 按峰值乘 1.3 到 1.5 设语言层上限
- 用 systemd 的
MemoryMax或容器 limit 做兜底，两层之间留出梯度 - 接上 OOM 告警，把
dmesg里的 killed process 纳入监控项
关于服务器脚本内存设置的常见问答
服务器脚本内存设置多少合适，有没有通用公式？
没有放之四海皆准的数字，但有可复用的方法：实测峰值乘以 1.3 到 1.5 的余量，且不超过物理内存的一半，没有压测数据之前，任何数字都只是猜测，业内专家指出，绝大多数内存事故的根源不是上限设小了,而是从来没测过峰值。
脚本内存限制调大后还是被 OOM 杀掉，是什么原因？
三种可能：语言层上限调大了，但 cgroup 或 ulimit 的硬限制没同步；容器 limit 设了，但容器内进程读到的仍是宿主机内存，按大内存自我扩张；整机物理内存本身不足，内核直接介入，前两种查 cat /sys/fs/cgroup/memory.max 和 ulimit -a,第三种查内核日志。
内存不够时，先扩容还是先优化脚本？
判断依据是峰值是否合理，同样数据量下，峰值远高于同类业务的正常水平，先查泄漏和全量加载；峰值本身合理、只是并发上不去，再考虑升配或拆分实例，扩容易，定位难，但先定位再花钱,长期成本更低。
内存设置的本质不是找一个魔法数字，而是让三层限制形成梯度、让上限建立在实测峰值之上,这条原则比任何具体配置都更耐用。