4. 系统内存与BLAST参数：了解可用内存设置，合理分配资源

好，我们接着聊。上一章我们把报错信息摸了个透，但有个很现实的问题——知道了是内存溢出，接下来怎么办？

我见过好多次这样的情况：有人对着 Out of memory 报错看了半天，然后直接加了个 -Xmx 参数，结果程序照崩不误。

嗯，原因很简单——你压根不知道自己机器还剩多少内存，也不知道 BLAST 到底能吃进去多少。

4.1 先搞清楚你手上有多少内存

这个听起来像废话，但真不是。很多人连 free -h 都没跑过就直接开搞。我建议你先看一眼系统的真实状态。

命令	用途	输出示例（部分）
free -h	查看物理内存总量、已用、可用、Swap	Mem: 125Gi total, 98Gi used, 27Gi available
top -bn1 | head -5	快速看总内存和 CPU 负载	MiB Mem : 128000 total, 25000 free
ulimit -a | grep memory	确认进程内存上限（ulimit 限制）	max memory size (kbytes, -m) unlimited
grep MemAvailable /proc/meminfo	精确获取可用内存（单位 kB）	MemAvailable: 28000000 kB

我个人习惯第一眼就看 MemAvailable，而不是 free 那列。为啥？因为系统会把缓存算进可用里，实际你可用的比 free 多不少。

4.2 BLAST 的几个「吃内存」大户

说白了，BLAST 的数据库索引和查询过程中的数据结构是内存消耗的主力。我拆成三个部分讲：

• 数据库索引加载——-db 指定的数据库会整颗索引树读进内存，尤其是蛋白质类库（比如 nr），体积大得吓人。
• 查询序列缓冲区——-query 里的序列会分批读入，但 -num_threads 设高了，缓冲区也跟着膨胀。
• 结果排序与去重——-outfmt 6 输出前，中间结果会先攒在内存里，等排序完才落盘。

你想想看，这三个地方同时吃内存，加起来就是灾难。

4.3 最关键的两个参数：-num_threads 和隐含的并行度

很多人觉得线程设多就跑得快，嗯，这是个大坑。

我记得有一次项目里，有人把 -num_threads 设成 64，结果数据库加载阶段就直接炸了。一查，64 个线程每个都要维护自己的索引副本，内存直接翻了几倍。

线程数	单线程估算内存	总估算内存	效果
4	8 GiB	约 36 GiB（含共享）	运行稳定，吞吐适中
16	8 GiB	约 80 GiB（共享部分减少）	内存紧张，容易 OOM
32	8 GiB	超过 140 GiB	大概率溢出

为什么会这样？因为 BLAST 内部使用 线程本地存储（TLS） 来做并行检索。说白了，每个线程都有一份自己的缓存区，线程越多，重复数据越多。

所以我的建议是：先跑 -num_threads 4 试水温，如果内存还很充裕，再慢慢往上加。别一上来就往死里怼。

4.4 数据库类型对内存的「隐形影响」

我当年刚入行时犯过一个错，以为所有数据库占的内存都一样。其实差别巨大。

• 核苷酸库（nt）：压缩率高，索引相对小。大约每 1Gb 文件用 0.5～1.5 GiB 内存。
• 蛋白质库（nr）：因为序列长度短、打分矩阵复杂，索引膨胀明显。每 1Gb 文件用 2～4 GiB 内存。
• 自定义长序列库：比如基因组 scaffolds 或宏基因组长 contigs——这类库的 GI（基因标识符）列表和偏移表会非常大。我见过一次，只有 500Mb 的 FASTA，建出来的索引吃了 8 GiB。

4.5 手动控制内存上限：-max_mem 与内核级别的限制

BLAST+ 2.12 以后加了 -max_mem 参数，我觉得这是最实用的改进之一。

# 限制 BLAST 最多用 32 GiB 内存
blastn -db nt -query reads.fa -out results.txt -num_threads 8 -max_mem 32G

# 用 MB 为单位也行
blastp -db nr -query proteins.fa -out results.txt -num_threads 4 -max_mem 16000M

但是要注意：-max_mem 只是一个软限制，BLAST 会尝试遵守，但某些内部流程（比如结果排序）可能短暂超限。所以别卡着边界设，我习惯留 20% 的余量。

如果你是在集群或者 Docker 里跑，还可以用 cgroup 或 docker run --memory 来做硬限制。配合使用最稳。

4.6 内存不够时的「降级策略」

好，假设你机器确实只有 16G，但数据库是 nr（70G+ 大小）——直接跑就是自杀。怎么办？

我常用的几个办法，按推荐程度排：

1. 拆分查询：把 query FASTA 切分成小文件，一批一批跑。比如 split -l 1000 reads.fa chunk_，然后逐批提交。
2. 过滤数据库：用 blastdb_aliastool -seqidlist 只选取一部分序列建索引，减少内存占用。
3. 换用 MegaBLAST/Empirical：对于高度相似序列，MegaBLAST 比普通 BLAST 内存占用低很多。
4. 开启 -use_index false：关掉索引，直接用顺序扫描，内存降下来了，但速度会慢 5～10 倍——用在实在没内存的时候。

4.7 实战：从一台 48G 机器上榨出最大吞吐

我拿最近一个项目举例。机器配置：48 GiB RAM，16 核 CPU，运行 BLASTN 比对 nt 数据库（约 12G 索引）。

第一轮我直接跑默认参数，系统报告 free -h 显示 MemAvailable: 40 Gi。结果 BLAST 跑到一半就 OOM 了。

排查方法：

• 先用 top 看——发现 BLAST 进程一度占到了 36 GiB，还一直在涨。
• 再用 ls -lh /db/nt.* 看索引——.phr 文件 6.8G，.pin 1.2G，.psq 4.3G。光索引就需要 12.3G 左右。
• 加上查询序列缓冲区和排序开销，默认线程 16 的情况下，内存峰值轻松突破 40G。

解决办法：

# 降线程，加内存软限制
blastn -db nt -query query.fa -out results.txt \
      -num_threads 8 \
      -max_mem 36G \
      -evalue 1e-5 \
      -outfmt '6 qseqid sseqid pident length mismatch gapopen qstart qend sstart send evalue bitscore'

跑起来后，htop 显示 BLAST 占用了大约 32G 左右，留了 16G 给系统。耗时比默认参数慢了大概 15%，但没有崩溃。说白了，有时候慢一点比「跑不完」要好一万倍。