第3章 BLAST内存溢出典型场景：大型数据库加载、高序列数比对、多线程并行、数据库索引过大
内存溢出这个问题，做BLAST生信分析的老手基本上都踩过坑。我本人也不例外，印象最深的是有一次跑一个大肠杆菌宏基因组项目，数据库接近50GB，比对几百个样本，结果提交任务后还没到预处理阶段就直接OOM killed了。嗯，回过头来看，其实就是没搞清楚BLAST吃内存的底层逻辑。
这章我把最常见的四个典型场景拎出来，一条一条讲透。你想想看，排查问题如果不知道问题长什么样，那排查效率会非常低。所以咱们先知道哪些场景容易崩，之后才好对症下药。
3.1 大型数据库加载——BLAST最常规的内存杀手
BLAST在比对之前，需要把数据库的索引结构加载到内存里。这个索引不只是序列本身，还包括了很多辅助结构，比如seed表、哈希桶、位置列表等等。说白了，数据库文件在磁盘上多大，内存里占的往往不止那么大。
关键指标：BLAST数据库加载内存 ≈ (序列数据原始大小 + 索引辅助结构) × 1.1 ~ 1.3
我见过很多新手以为数据库文件只有2GB，那内存肯定够。但实际运行时，blastn或blastx的进程一下子就冲到8GB以上。为什么会这样？因为数据库索引结构是经过压缩且带有额外映射的，特别是加了subject_besthit或task选项时，辅助结构更多。
举个实际例子。用makeblastdb构建一个包含100万条蛋白质序列的数据库，文件大小大约1.5GB。加载到内存后，PSI-BLAST的索引常驻内存大约需要3.2GB。这还是没算多线程共享的部分。
# 查看数据库基本信息
bash$ makeblastdb -in uniprot_sprot.fasta -dbtype prot -out sprot_db
# 构建完成后查看文件大小
bash$ ls -lh sprot_db.*
sprot_db.psq 850M # 序列数据
sprot_db.pin 1.2G # 索引结构
sprot_db.phr 2.3G # 头标信息
sprot_db.pot 80M # 其他辅助你在BLAST命令里不加任何限制，直接拿这个数据库去比对，内存占用大概率冲到4GB以上。
| 数据库类型 | 原始fasta大小 | 索引后总大小 | 典型内存占用（单线程） |
|---|---|---|---|
| nt核酸库（NR版） | ~80 GB | ~110 GB | ~50-70 GB（部分内存映射） |
| nr蛋白库（NR版） | ~60 GB | ~90 GB | ~40-60 GB |
| UniRef50 | ~15 GB | ~25 GB | ~12-18 GB |
| 自建小型库（1万条） | ~10 MB | ~30 MB | ~50-80 MB |
注意：大型数据库加载时，如果服务器物理内存不足，BLAST会使用内存映射文件（mmap），但这不意味着不会OOM。mmapped文件虽然不会一次性全部加载到物理内存，但频繁的缺页中断会导致性能急剧下降，最终在大量并发请求时还是会被OOM killer杀掉。
3.2 高序列数比对——批量提交时的内存雪崩
很多人习惯把几千条甚至几万条序列放在一个FASTA文件里，然后用blastn -query bigfile.fasta -db mydb -out out.txt。你觉得它能处理得了？
实际上，BLAST默认会把所有查询序列一次性读入内存，然后建内部哈希表、种子表等等。假设你提交了10万条短读序列，每条150bp，原始数据只有约15MB。但BLAST内部会为每条序列创建一个完整的比对上下文，包括候选命中列表、扩展区间、分数矩阵等。这些中间结构加在一起，内存占用很容易膨胀10~20倍。
我个人习惯的做法是：先拆成小份，比如每1000条一个文件，然后并行或串行执行。如果必须要一个命令搞定，那就用-num_threads配合-max_target_seqs控制内存。
# 错误示范：一次性提交10万条序列
blastn -db nt -query 100k_reads.fasta -out 100k_out.txt -num_threads 16
# 可能直接OOM或运行几天死掉
# 正确做法：用split拆分成小批次
fasta_split -i 100k_reads.fasta -n 100 -o split_reads
# 然后循环提交
for f in split_reads_*.fasta; do
blastn -db nt -query "$f" -out "${f%.fasta}_out.txt" -num_threads 4
done小技巧：先用seqkit stats统计一下查询文件的总序列数和总长度，心里有个数。如果总长度超过1e9 bp，建议按每1e8 bp拆分一个任务。
3.3 多线程并行——不是线程越多越快
BLAST从2.2.31版本开始支持-num_threads参数。很多人上来就设-num_threads 32或者64，觉得核心多用起来爽。但你想想看，每个线程都需要自己的内存空间来存储比对路径、扩展结果、候选hit。线程越多，内存开销几乎是线性增长。
- 每个额外的线程约增加：300MB ~ 800MB（取决于数据库大小和任务复杂度）
- 线程同步开销：大量线程同时读数据库的内存映射区，锁竞争会拖慢性能
- 实际最优线程数通常在4~8之间，超过16后性能增长很小甚至下降
# 对比实验：使用相同数据库和查询序列，只改线程数
time blastn -db nt -query 1k_16S.fasta -out /dev/null -num_threads 1
# real 12m35s mem 1.8GB
time blastn -db nt -query 1k_16S.fasta -out /dev/null -num_threads 8
# real 2m10s mem 4.6GB
time blastn -db nt -query 1k_16S.fasta -out /dev/null -num_threads 32
# real 2m05s mem 8.9GB
time blastn -db nt -query 1k_16S.fasta -out /dev/null -num_threads 64
# real 2m12s mem 12.1GB (性能反而下降)你看，从32线程到64线程，内存几乎翻倍，但时间居然还慢了。这明显就是线程过多导致内存带宽饱和、缓存颠簸。我建议：多线程不要超过物理核心数的一半，而且最好搭配-max_target_seqs 5或10来限制命中数量，减少内存使用。
3.4 数据库索引过大——索引结构本身吃内存
BLAST的索引文件除了序列数据，还有：
- 种子hash表：记录所有固定长度种子（words）在数据库中的位置。对于核酸库，word size通常是11（blastn）或28（megablast），每个种子对应一个链表头。
- 位置列表：每个种子在数据库中出现的位置索引，这些列表的长度和序列数量成正比。
- 辅助索引：比如压缩分数表、gap开放罚分表等。
我遇到过一个真实案例：一个同事用makeblastdb -in all_genomes.fasta -dbtype nucl -hash_index构建了一个带有哈希索引的数据库，文件大小是原始fasta的3倍。然后他用这个数据库跑blastn，每次启动都要花2分钟加载索引，内存占用高达原始数据的5倍。最终在64GB的机器上撑不住。
避坑指南：如果你用-hash_index，数据库索引体积大约增大2~3倍，内存占用也会显著增加。如果不是特别频繁的查询，普通线性索引足够用了。
总结一下索引类型的内存影响：
- 默认线性索引：内存 ≈ 数据库文件大小 × 1.5
- 哈希索引（-hash_index）：内存 ≈ 数据库文件大小 × 3~4
- 组合索引（同时保留多个索引）：内存 ≈ 数据库文件大小 × 5+
3.5 典型场景的显式症状
我们可以通过系统日志确认具体是哪类问题。下面是我最常用的排查命令：
# 查看dmesg中的OOM killer记录
dmesg | grep -i "killed process" | grep -E "blast|makeblastdb"
# 典型输出：
# [376541.234567] Out of memory: Killed process 12345 (blastn) total-vm:25847100kB, anon-rss:18563400kB, file-rss:123000kB
# 这里 total-vm 表示虚拟内存，anon-rss 是实际物理内存占用如果再细化一点，看到anon-rss占很高而file-rss不高，说明主要是中间数据结构吃内存，不是数据库本身。如果file-rss接近数据库文件大小，那就说明数据库索引被完整映射进了物理内存。
千万别忽略swap：如果物理内存不够，系统会使用swap，但BLAST的随机访问模式会导致严重的swap抖动。我看到过很多案例，SSD都被swap写坏了。所以最好关闭swap或者限制BLAST进程的memory.limit。
3.6 一张图看懂核心逻辑
我把这四类场景的关系和诊断思路画成了一张SVG流程图，方便你对照排查。注意看红色分支是致命OOM路径，绿色是可控路径。
3.7 本章小结
这四种场景其实互相交织。比如你既用了大型数据库，又开了32线程，还塞了10万条查询序列，那基本上属于三重叠加，内存想不爆都难。
- 大型数据库加载：优先考虑物理内存是否≥数据库索引估计大小的2倍；否则用mmap模式或分布式方案。
- 高序列数比对：拆分成小batch，每批千条左右，用循环提交。
- 多线程并行：锁定4~8线程，配合
-max_target_seqs降低内存。 - 索引过大：避免
-hash_index，使用默认线性索引。