📚 课程目录第3章 BLAST运行环境与资源限制检查

3. BLAST运行环境与资源限制检查

我调试过的BLAST内存超限案例里，有三四成其实根本不是BLAST本身的bug。环境没配对、内核参数没调、隔壁作业抢资源……这些问题你换个机器跑一遍，问题就消失了。所以拿到一个OOM问题，别急着钻代码。

先检查环境。我个人的习惯是跑任何BLAST之前，先跑一组系统探测命令，把家底摸清楚。

3.1 资源层面：内存、CPU、磁盘IO

内存是BLAST的命门。我见过有人用free -h看一眼总内存就放心了，但实际可用内存可能已经给别的服务吃完了。

资源	关键命令	看什么	踩坑点
物理内存	`free -h`	`available`列，不是`free`列	`free`很小但`available`够用，其实没事
交换分区	`swapon --show`	交换是否启用，大小够不够	交换太大→BLAST被卡进swap→IO成为瓶颈
CPU核数	`nproc` / `lscpu`	物理核 vs 逻辑核	超线程算虚的，设`-num_threads`别超过物理核
磁盘写能力	`iostat -x 1 5`	`%util`、`await`	SSD高`await`说明temp目录碎片严重

一个小习惯：在跑大型BLASTp之前，我会先敲free -h && nproc && df -h /tmp。三秒，能筛掉至少一半的环境问题。

3.2 限制层面：ulimit、cgroup、作业调度器

你以为内存分配出去了？不一定。操作系统和调度器可能会静悄悄砍一刀。

举个最近的例子。我曾经帮同事排一个BLASTn的OOM，排了半天发现是ulimit -l锁了内存锁页。BLAST用mmap配了锁定页，锁不住就频繁缺页，性能血崩。

# 查当前用户的资源软硬限制
ulimit -a

# 重点关注
ulimit -v           # 虚拟内存上限（-1=不限制）
ulimit -l           # 可锁内存大小（KB）
ulimit -n           # 打开文件描述符数

为什么ulimit这么关键？
BLAST的大型索引文件会通过mmap映射进地址空间。如果ulimit -v设得太死，映射nr库时直接就OUT了，连报告都可能看不到。

很多HPC集群的登录节点和计算节点ulimit设置不一样。你在登录节点测得好好的，一提交作业就挂。我建议在作业脚本里显式加一行ulimit -v unlimited 2>/dev/null。

3.2.1 cgroup与容器环境

现在很多人用Docker/Singularity打包BLAST。这时候free -h显示的是宿主机，不是容器。看里面要这样：

# 容器内查实际可用内存
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
cat /sys/fs/cgroup/memory/memory.usage_in_bytes

# 如果limit设置比宿主机小，恭喜你，遇到隐形天花板了

我还遇到过一种情况：Kubernetes里设置了memory request != limit，limit是宿主机的一半，但BLAST启动了跟宿主机核数一样的线程。线程一多，内存锁页数翻倍，直接OOMKilled。嗯，这里要注意——线程数也要跟内存按比例缩。

3.2.2 PBS / SLURM作业调度器的陷阱

调度器	参数	常见问题
SLURM	`--mem`	单位默认为M！写`--mem=5g`可能被解释为5M，作业一跑就OOM
SLURM	`--cpus-per-task`	跟`-num_threads`对不上→资源争抢或闲置
PBS	`#PBS -l mem=8gb`	PBS是per节点还是per核？版本不同含义不同，建议查文档
SGE	`-l h_vmem=4G`	`h_vmem`硬限制，超了直接杀；`s_vmem`软限制只给警告

我吃过一次大亏：SLURM作业--mem=40G，但申请了8个CPU核，BLASTp设-num_threads 4。看起来没问题，结果实际内存占用了60G才OOM。排查后发现--mem没乘节点数，SLURM给的是每节点不是每核心，而TBLASTN的中间文件又占了一倍临时空间。从那以后，我的作业脚本里都会加一行：

echo "SLURM_MEM_PER_NODE=$SLURM_MEM_PER_NODE"

以此确认变量传进去了。

3.3 运行环境检查流程图

综合以上信息，我整理了一个检查流程。你遇到OOM，按这个顺序排查，不要跳步：

3.4 环境检查脚本（可直接用）

我自己在服务器上放了一个shell脚本叫blast_env_check.sh，跑BLAST之前先跑它，安心。把它放到~/.local/bin/，全局可用。

#!/bin/bash
# blast_env_check.sh - 运行BLAST之前的环境检查

echo "========== BLAST运行环境检查 =========="
echo "1. 物理内存："
free -h | grep "Mem:"

echo ""
echo "2. 交换空间："
swapon --show 2>/dev/null || echo "（无交换分区或未启用）"

echo ""
echo "3. CPU信息："
echo "物理核数：$(nproc --all)  建议-threads不超过此数"

echo ""
echo "4. ulimit关键项："
ulimit -v
ulimit -l
ulimit -n

echo ""
echo "5. 作业调度器（如果有）："
if [ ! -z "$SLURM_MEM_PER_NODE" ]; then
    echo "SLURM作业内存限制：$SLURM_MEM_PER_NODE MB"
fi
if [ ! -z "$PBS_NCPUS" ]; then
    echo "PBS作业CPU核数：$PBS_NCPUS"
fi

echo ""
echo "6. BLAST版本与可执行路径："
which blastn 2>/dev/null && blastn -version | head -1

echo ""
echo "========== 检查完成 =========="
if grep -q "SELinux" /etc/selinux/config 2>/dev/null; then
    if getenforce 2>/dev/null | grep -q "Enforcing"; then
        echo "⚠ SELinux已启用，可能限制mmap。建议测试前临时关闭。"
    fi
fi

  一个更实用的技巧：把这个脚本放在~/.bashrc里，每次打开新终端自动跑。这样你在登录节点习惯性地看一眼输出，很多坑在提交作业之前就筛掉了。

3.5 资源检查常见误区

我总结了几条高频翻车点。划重点：

只看总内存。 你该看的是available，不是total。缓存和buffer也能被BLAST回收，free列很小不代表不够用。
以为Docker容器里free -h是准确的。 容器里看到的MemTotal多数跟宿主机一样，除非你用了--memory限制。真要看容器限制，去读cgroup文件。
作业脚本里不打印调度变量。 SLURM/PBS传进来的环境变量很多，你完全不知道--mem到底传了几多。加个echo $SLURM_MEM_PER_NODE，直观。
线程数跟核数瞎匹配。 BLASTp的线程数一旦超过物理核，上下文切换带来的内存开销可能超过你本省的内存。
忽略临时目录IO性能。 BLAST中间文件写临时目录，IO差会导致瓶颈，不会直接OOM，但会表现为“内存涨上去了但作业跑不出来”。

不要忘了：ulimit 设置是 per process 的。你开多线程，每个线程的栈空间也占虚拟内存。设ulimit -v 4000000（4G），8线程，每个线程栈默认8M，那光栈就吃了64M。如果你是32位系统、启用了PAE，地址空间更紧，一不小心就Cannot allocate memory。

说到这，环境检查这块基本铺开了。资源够了、限制松了、调度器没坑了，再去追BLAST本身的问题，才能事半功倍。我个人觉得，环境检查是调试里性价比最高的一步——花五分钟看命令输出，省几个小时定位脑雾。多数时候，答案就藏在free或ulimit -a的输出里。