这种情况我之前在集群上踩过好几次坑，PBS/Torque的内存配置逻辑有时候和直觉不太一样，咱们一步步拆解排查：

1. 先确认内存参数是不是真的生效了 #

很多时候问题出在参数的理解错误上：

• Torque里的mem是节点总内存，而pmem是每个CPU核心的内存配额。如果你设置了nodes=1:ppn=4,mem=6gb，那整个节点只有6GB内存，4个核心共享，每个核心实际能用到的内存可能远低于你预期的6GB。如果你的程序是单进程，应该用pmem=6gb（每个核心分配6GB）或者nodes=1:ppn=1,mem=6gb（单核心独占节点6GB）。
• 还要注意参数的单位格式：有些集群只认小写的gb/mb，写6G可能会被当成默认值处理。可以用qstat -f <你的作业ID>查看作业的实际资源配置，确认Resource_List.mem或Resource_List.pmem是不是你设置的6GB。

2. 检查环境变量的差异 #

终端里的环境（比如LD_LIBRARY_PATH、PYTHONPATH或者程序专属的配置变量）和PBS作业的默认环境可能不一样，这会导致程序在队列里运行时内存占用飙升：

• 在作业脚本开头加上source ~/.bashrc（如果你用bash）或者source ~/.profile，把终端的环境变量导入进来。
• 可以在终端里运行env > terminal_env.txt，然后在脚本里对比输出env > pbs_env.txt，找出差异的变量并手动设置。

3. 程序的并行/线程设置可能偷偷吃内存 #

如果你的程序支持多线程/多进程，在终端运行时可能因为终端的限制只用到1个核心，但在PBS里因为ppn设置了多个核心，程序自动拉起了多个线程，总内存直接翻倍/翻几倍：

• 比如OpenMP程序，要在脚本里设置export OMP_NUM_THREADS=1，强制只用1个线程；
• 如果是Python程序，检查是不是用了multiprocessing模块，有没有限制进程数；
• 把ppn暂时改成1，测试一下是否还会OOM，排除并行导致的内存叠加问题。

4. 监控实际内存使用，别光看报错 #

有时候OOM报错可能是误判，或者程序的内存峰值比你预期的高很多：

• 在作业脚本里加个简单的内存监控，比如：

# 后台定时记录内存使用
while true; do
    ps -o rss=,vsize=,cmd= -p $(pgrep your_program_name) >> mem_log.txt
    sleep 30
done &
MONITOR_PID=$!

# 运行你的程序
./your_program --your-args

# 结束监控
kill $MONITOR_PID

• 作业结束后用qacct -j <作业ID>查看maxrss（实际物理内存峰值）和maxvmem（虚拟内存峰值），看看是不是真的超过了你申请的6GB。

5. 虚拟内存的坑 #

有些程序会用到大量虚拟内存，而Torque默认可能只限制物理内存，当虚拟内存超了也会触发OOM。可以在作业脚本里加上vmem=8gb（比物理内存高一些），给虚拟内存留够空间。

试试上面这几步，大概率能找到问题所在。

内容的提问来源于stack exchange，提问作者Uday Chopra