📚 课程目录第3章诊断内存溢出

诊断内存溢出：错误信息解读、日志分析与排查方法

内存溢出报错来了，别慌。先看一眼错误信息长什么样，再翻翻日志，基本就能锁定问题。

我个人习惯，遇到 BLAST 跑崩了，第一件事不是改参数，而是把终端里最后 20 行输出保存下来。很多时候，错误信息本身就告诉了你原因。下面我带你一条一条拆。

常见错误信息类型

BLAST 内存溢出的错误信息，翻来覆去就那几种。我整理了一张表，方便你对照。

错误信息片段	含义	常见原因
`Out of memory` / `Cannot allocate memory`	进程申请内存时操作系统拒绝	数据库太大、查询序列太长、`-num_threads` 开太高
`Segmentation fault (core dumped)`	段错误，通常因访问非法内存地址	数据库索引损坏、内存碎片、磁盘 I/O 错误导致加载数据异常
`Killed`（无 core dump）	进程被系统 OOM Killer 杀掉	物理内存耗尽，比 Out of memory 更隐蔽
`Bad allocation`	C++ `new` 操作失败	单次内存申请超过剩余空间，或堆内存碎片化严重
`std::bad_alloc`	与上一条类似，C++ 异常	常见于 blastn 处理超长 read 时

⚠️ 注意：Killed 和 Segmentation fault 容易被误判为代码 bug。其实在内存紧张时，系统直接释放进程，不给你留日志的机会。我当时遇到一个案子，用户一直怀疑是 blastn 有内存泄露，结果查出来是 – 他把整个 RefSeq 数据库索引文件放在了 tmpfs 里。嗯，物理内存 16GB，索引 20GB，不 killed 才怪。

日志分析：关键指标看哪里

BLAST 在跑的时候会输出一些运行时信息，很多人直接跳过只看结果。我建议你把下面这几行盯牢。

举个例子，你跑 blastn 时加了 -outfmt 17（SAM 格式）或者默认的 tabular，标准错误里会有类似这样的内容：

# BLASTN 2.15.0+
# Query: seq1
# Database: nt
# Fields: query acc., subject acc., % identity, alignment length, mismatches, gap opens, q. start, q. end, s. start, s. end, evalue, bit score
# 1 hits found
# CPU time: 23.45s
# Real time: 15.21s
# Max memory used: 8.7 GB
# Total memory used: 6.2 GB
# Database size: 478,391,283 letters
# Number of sequences in database: 127,855,412
# Effective search space: 2.14e+12
# Algorithm: BLASTN (megablast)

重点看三个地方：

Max memory used：跑完之后实际占用的峰值内存。如果这个值已经接近或超过你的物理内存，那下次跑很容易崩。
Total memory used：累计分配的内存，注意可能包含重复释放，但能反映内存压力趋势。
Effective search space：这个数字越大，理论上内存消耗也越大。它和查询长度、数据库总长度、word size 都有关系。

💡 我的习惯：在跑大批量任务之前，先用一条典型序列试跑，记录 Max memory used。然后估算：如果要跑 1000 条序列，内存会不会爆？如果估算值超过物理内存 80%，我建议你拆任务或者调整参数。

另外，日志里的 Real time 和 CPU time 也值得关注。如果 CPU time 远大于 Real time，说明多线程并行度好；反过来如果 CPU time 和 Real time 非常接近，可能是 I/O 瓶颈，内存分配频繁，甚至 swap 了。

排查方法：三步定位根因

我自己总结了一套排查流程，画了个图，你跟着走就行：

💡 流程图里的“检查数据库索引”那块，我单独说两句。段错误不一定是索引坏了，但概率很大。我遇到过用 makeblastdb 创建索引过程中磁盘写满，生成的 .pal 文件只有一半大小。结果 BLAST 一读就直接 segfault。重新创建索引就好了。

实操：怎么检查 Max memory 和 Effective search space

回到日志部分。如果你没看到 Max memory used，可以手动加 -logfile 参数输出详细日志。举个例子：

blastn -db nt -query my_query.fa -out results.txt -logfile blast_debug.log

# 然后 grep 一下：
grep -i "max memory used" blast_debug.log
grep -i "effective search space" blast_debug.log

如果日志里没有，或者你用的是远程集群看不到日志，别慌。可以在命令行里挂 time -v 或者 /usr/bin/time -v，它会显示最大驻留内存：

/usr/bin/time -v blastn -db nt -query my_query.fa -out results.txt 2>&1 | grep "Maximum resident set size"

这个指标和 Max memory used 基本一致。我个人习惯在两台机器上做基准测试：一台 32GB，一台 64GB。如果 64GB 上不崩，32GB 上崩，那基本就是内存不够了，剩下就是调参数或者换机器的问题。

避坑指南：我曾经掉进去的三个坑

坑一：忽略了 -num_threads 的内存放大效应。我有一年做宏基因组分析，blastn -num_threads 32，以为线程越多越快。结果每个线程都要维护自己的哈希表，内存直接翻了 10 倍。后来改成 16 线程，内存降了一半，速度反而更快了。
坑二：把 Killed 当成了普通的 killed by signal。有一次客户说 BLAST 总是被 kill，查代码没问题。我让他 dmesg 看一眼，结果全是 Out of memory: Killed process ...。说白了就是 OOM Killer 干了活，根本不是 BLAST 的 bug。
坑三：拿 htop 看内存占用，却忽略了 swap。我曾经盯着 RES 看，觉得 12GB 内存没满啊，为什么进程被杀了？后来一看 SWAP 用了 20GB，系统早就在疯狂换页了。检查内存一定要看 free -h 里的 available 字段，它才是真实可用的物理内存。

快速排查清单

最后给你一份我贴在自己工位上的检查清单，遇到内存溢出直接对着做：

错误信息是哪一类？如果是 Killed，直接查 dmesg | tail -20。
日志里 Max memory used 是多少？和物理内存对比。
查询序列有多长？数据库总大小？我建议用 blastdbcmd -info -db nt 查看。
线程数是否合理？-num_threads 不要超过物理核心数的一半（尤其是超线程场景）。
是否使用了 -parse_deflines？这个选项在数据库很大时额外占用内存，能不用就不用。
尝试降低 -word_size 或增大 -evalue 阈值，减少展开的种子数。
如果还是不行，考虑分库分任务，或者换用 megablast 的 -task megablast 降低内存。