内存超限的常见原因分析

搞BLAST调试这么多年，我见过最多的问题就是——内存吃满，然后进程被OOM Killer干掉。你想想看，一个比对任务跑了几小时，突然报个"Killed"，谁都得崩溃。其实大多数情况都不是BLAST本身的bug，而是我们在使用姿势上踩了坑。这一章我就把最常见的内存超限原因掰开揉碎了讲清楚，顺便带一些我自己淌过的浑水。

1. 数据库文件太大，直接撑爆内存

这是最朴素的原因，但也是最容易被忽略的。很多新手上来就用nr库（几十GB），然后不加任何参数直接跑，结果内存直接拉满。我刚开始做宏基因组比对时也犯过这个错，当时服务器256GB内存，我以为够用了，结果nr库索引加载就占了200多GB，再加上查询序列和中间结果……嗯，直接卡死。

核心问题：BLAST在比对前需要把数据库的索引（如BLASTDB）全部加载到内存里。数据库越大，内存占用越高。如果数据库超过物理内存的一半，基本就是个定时炸弹。

避坑指南：我曾经在一个生产环境中看到运维直接拿整个nt库（约150GB）做blastn，结果每次提交任务都导致节点OOM。后来我建议他们用-db_chunk分割数据库，或者用-remote模式走远程查询，问题就解决了。

数据库大小	内存占用（约）	建议操作
< 1GB	200MB - 500MB	直接加载
1GB - 10GB	2GB - 8GB	监控内存，考虑分块
10GB - 100GB	10GB - 80GB	必须分块或远程
> 100GB	远超物理内存	建议用-remote或索引

2. 查询序列太长，或批次体积过大

很多人以为只有数据库大才会吃内存，其实查询序列本身也很关键。你想想看，如果一条查询序列有几百万个碱基，BLAST需要把它切成很多小的seed片段（word），每个片段都要在数据库里查找匹配。这些中间结果会累积在内存里，直到比对完成才释放。

我印象最深的一次，有个做植物基因组的用户，用一条1.5M的基因组序列做blastn，结果跑了6个小时后内存涨到120GB，直接挂了。后来我把这条序列切成50kb一段，用-task blastn-short分别跑，内存只用了不到8GB。

建议做法：

• 单条查询序列长度超过100kb时，考虑拆分成重叠的片段
• 查询文件（FASTA）总大小如果超过1GB，分批次提交
• 使用-max_target_seqs 5限制每个查询的输出结果数，减少结果集内存开销

3. 线程数/并行度设置不当

BLAST支持多线程，但很多人以为线程数越大越快。其实每个线程会维护自己的匹配缓冲区和输出队列，如果线程数设得太大（比如超过CPU核数），反而会因内存争抢导致性能下降，甚至OOM。

我习惯用-num_threads参数，但一般不超过CPU物理核数的75%。举个例子，一台32核的机器，我通常设24个线程。为什么？因为BLAST的Master线程还要消耗额外内存，留一点给系统缓冲。

# 不推荐：把所有核塞满
blastn -db nt -query big.fa -num_threads 32 -outfmt 6

# 推荐：留出余量
blastn -db nt -query big.fa -num_threads 24 -outfmt 6

4. 输出格式选择了"全量输出"

-outfmt参数决定了输出内容的详细程度。默认的pairwise格式（outfmt 0）会把每条比对的序列细节都打出来，包括序列全长。如果数据库有1万条匹配，你可能得到10万行比对信息，这些信息是在内存中逐步生成的。

我自己曾经调试一个项目，跑完blast输出文件有20GB，结果发现内存使用峰值就是输出组装阶段。后来改用-outfmt 6（tabular），只保留必要字段，内存直接降了60%。

推荐做法：

• 如果只需要比对统计，用-outfmt 6或-outfmt 7
• 需要比对序列时，用-outfmt "6 qseqid sseqid pident length mismatch gapopen qstart qend sstart send evalue bitscore sseq"，只带必要字段
• 避免使用-outfmt 0或-outfmt 1处理大结果集

5. 索引构建消耗额外内存

如果你用的是自定义数据库，需要先用makeblastdb构建索引。这个过程中，程序需要把整个FASTA文件读入内存并计算k-mer频率，构建哈希表。对于重复序列多的数据库（比如基因组重复区域），哈希表会变得异常庞大。

我记得有个做细菌基因组项目的同事，他构建了一个包含5000个细菌基因组的数据库，makeblastdb直接用了70GB内存，服务器只有64GB，结果一直交换。后来我帮他加了-blastdb_vol选项，把索引分割成多个小文件，才搞定。

# 构建索引时限制内存使用
makeblastdb -in my_genomes.fa -dbtype nucl -blastdb_vol 10 -parse_seqids

这里-blastdb_vol控制每个索引文件包含的序列数，默认是2亿条，调小可以减少单次加载的内存。

6. 系统资源限制：ulimit和cgroup

很多情况下，BLAST本身并没有吃太多内存，而是系统对进程的内存限制太宽松，导致它无限膨胀直到被kill。或者反过来——系统限制了进程只能使用1GB内存，而BLAST需要2GB。

检查一下：

• ulimit -a看max memory size是不是unlimited
• 如果是容器环境，检查cgroup的内存限制
• SLURM等作业调度器有--mem参数，设小了会直接杀死任务

我曾在集群上遇到一个怪现象：同样的数据库和查询，在本地跑没问题，在集群上就OOM。后来发现是SLURM默认只给每个任务4GB内存，而BLAST需要8GB。加了--mem=16G后一切正常。

小结一下

上面这六条，基本覆盖了95%以上的BLAST内存超限场景。我个人调试时，会按照以下顺序快速定位：

1. 先看数据库大小：用blastdbcmd -info确认
2. 再看查询序列：如果太长就切分
3. 检查参数配置：线程数、输出格式、max_target_seqs
4. 确认系统限制：ulimit、cgroup、调度器