Kraken2 常被称为“很快的宏基因组物种分类工具”，于是很多人先装软件、再把线程拉满，最后却卡在数据库加载：进程被系统杀掉、hash.k2d 读不进去，或者同一批 FASTQ 在本地盘十几分钟完成，换到共享存储后速度突然掉到底。真正决定资源的往往不是 Kraken2 程序本身，而是你选择了哪一套数据库、数据库放在哪里，以及同时启动了几个任务。
截至发稿，Kraken2 官方 GitHub Releases 将 v2.17.2 标为最新版本。更值得关注的是数据库增长：Langmead Lab 的公开索引页显示，2026-02-26 的 PlusPFP 索引达到 221.8 GB，而同日的 Viral 索引只有 0.6 GB。两者都能被称为“Kraken2 数据库”，资源需求却相差约 370 倍。
先看数据库：压缩包大小不等于运行内存
公开索引页同时列出 archive size 与 index size。下载的是压缩包，分类时真正频繁随机访问的是展开后的索引；Kraken2 官方手册说明，为高效运行，需要有足够空闲内存容纳数据库，主要是 compact hash table。只按下载文件大小配盘和内存，解压后就可能立刻超预算。
| 数据库（公开日期） | 压缩包 | 索引大小 | 资源判断 |
|---|---|---|---|
| Viral（2026-02-26） | 0.5 GB | 0.6 GB | 病毒专项，不能替代综合库 |
| PlusPF-8（2026-02-26） | 5.5 GB | 7.5 GB | 受限库，适合低内存试跑 |
| PlusPF-16（2026-02-26） | 11.2 GB | 14.9 GB | 32 GB 主机更容易留出系统余量 |
| Standard（2025-07-14） | 70.8 GB | 91.8 GB | 实用起点通常要评估 128 GB 内存 |
| PlusPFP（2026-02-26） | 164.4 GB | 221.8 GB | 多样本与并发需评估 256 GB 以上节点 |
最后两行的内存建议是工程起点，不是官方硬门槛。还要给操作系统、输入缓冲、报告生成和并发任务留余量。数据库内容也不同：PlusPFP 比 Standard 增加 RefSeq 原生生物、真菌和植物；若研究问题只关心病毒，加载综合库不仅浪费资源，还会扩大需要解释的分类空间。
--memory-mapping 能省内存，但不是“零内存运行”
默认情况下，Kraken2 把数据库载入进程本地内存。--memory-mapping 让程序通过内存映射访问数据库，多个进程有机会复用操作系统页缓存，避免每个任务都复制一份完整索引。它适合一台服务器上连续处理多样本，但性能取决于页面是否已经缓存，以及底层存储的随机读取能力。
官方手册明确建议尽可能不要把 Kraken2 数据库放在 NFS。数据库访问并不是一次顺序读完；冷缓存时，网络盘延迟可能让“CPU 还有很多空闲”与“任务很慢”同时出现。更稳妥的结构是：数据库放本地 NVMe，原始 FASTQ 和最终报告放容量盘，任务开始前确认剩余内存与磁盘吞吐。
kraken2 --db /nvme/db/k2_pluspf_16_20260226 \
--paired sample_R1.fastq.gz sample_R2.fastq.gz \
--gzip-compressed --threads 24 \
--memory-mapping \
--report sample.kreport \
--output sample.kraken
命令能跑不代表结果已经可比。数据库名称、发布日期、Kraken2 版本、置信度阈值和是否使用 Bracken，都应与结果一起记录。同一项目中途换库，会同时改变可检出的物种范围、minimizer 集合和丰度估计基础，不能把前后两批报告直接拼接。
线程越多越快？先看瓶颈在 CPU 还是 I/O
--threads 24 只表示最多使用多少计算线程，不会自动解决数据库未缓存、网络盘延迟或 gzip 解压争用。第一次运行大型索引时，系统要把大量页面从磁盘读入内存；此时 CPU 利用率可能不高，但磁盘队列持续增长。第二个样本若复用热页缓存，速度往往明显不同。因此 benchmark 至少要分别记录冷缓存与热缓存，不要只挑最快的一次作为服务器能力。
多人共享节点还要限制“任务数×线程数”。四个 24 线程任务并不等于 96 核就一定合理：它们可能同时抢同一块 NVMe、重复解压输入，并产生大体量逐 read 输出。若下游只需要物种报告，可以评估是否保留完整 --output；若要追踪未分类 reads、做宿主过滤复核或复现，则应提前为分类结果和 FASTQ 副本预留容量。资源规划要围绕交付物，而不是只围绕命令能否启动。
32 GB、128 GB、256 GB，应该怎样选？
如果只是验证流程或做范围明确的病毒任务，32 GB 服务器通常有足够空间运行小型索引；若使用约 14.9 GB 的 PlusPF-16，还应限制并发，并观察实际峰值。面对约 91.8 GB 的 Standard 索引，可以从 128 GB 内存与本地 NVMe 评估。要使用 221.8 GB 的 PlusPFP，256 GB 只是较紧的工程起点；多人同时跑时，更应考虑内存映射、任务队列和页缓存复用，而不是直接把并发数设成 CPU 核数。
资源有限时，可以选择官方公开的 8 GB/16 GB capped 数据库，或在自建库时使用 --max-db-size 控制 hash table 上限。官方手册说明，超过上限时参考库会被下采样以适配大小。代价是数据库覆盖发生变化，因此必须把“能在小机器上运行”和“适合当前科学问题”分开判断，尤其不能把受限库的阴性结果解释成样本中一定不存在该物种。
自建数据库还包含下载分类学文件、整理参考序列、估算容量和填充 hash table 等阶段。官方手册给出的历史标准库示例在构建时约需 100 GB 磁盘，并提醒构建过程没有在容量估算之后自动断点续跑。今天的参考集合更大，实际空间必须以当次 library、taxonomy 和最终 hash.k2d 为准；最好把下载区、构建临时区和正式只读索引分开，构建失败才不会污染正在使用的数据库。
结果解释也有边界。Kraken2 的 confidence 阈值不是具有统一概率意义的“准确率”，不同样本复杂度和数据库都会改变分类表现。需要丰度估计时，Bracken 文件必须与数据库及 read length 配套；只复制一个旧的 Bracken 文件到新索引目录，虽然流程可能运行，却失去可比性。服务器解决的是稳定运行和可复现，不替代阴性对照、污染评估与生物学验证。
上服务器前，先检查这 5 项
- 看 index size，不只看压缩包。 下载空间、解压空间、运行内存是三笔账。
- 确认数据库覆盖。 Standard、PlusPF、PlusPFP、Viral 和 capped 版本回答的问题不同。
- 数据库放本地 NVMe。 若只能用 NFS，先用代表样本实测冷缓存与热缓存差异。
- 固定版本和日期。 保存 Kraken2 版本、数据库发布日期、MD5、参数与 Bracken 文件。
- 按并发估算峰值。 不用 memory mapping 时，多进程可能重复装载；使用后也要给页缓存和系统留余量。
如果你的 Kraken2 任务正在 OOM、数据库加载慢、多人并发互相影响，或不知道该选 Standard、PlusPF 还是 PlusPFP，可以准备数据库名称与日期、索引大小、样本数、FASTQ 总量、计划并发和目标输出。云生信可先判断瓶颈在内存、NVMe、网络存储、数据库覆盖还是参数，再分别沟通服务器租赁、环境部署或委托分析的适用范围。具体速度和峰值以代表样本实测为准。
