2. 计算资源瓶颈分析：内存、CPU、GPU、I/O 瓶颈识别
做空间单细胞分析，说白了就是跟计算资源掰手腕。我入行那会，第一次跑 10X Visium 数据，笔记本直接卡死，风扇响得像要起飞。后来才明白——不提前找准瓶颈，你的集群再大也白搭。
这一节咱们就把四个大头挨个盘一遍：内存、CPU、GPU、I/O。我会把自己踩过的坑都抖出来，你跟着走一遍，至少能省下一半的调试时间。
2.1 内存瓶颈——Swap 就是你的催命符
空间单细胞数据，一张 Visium 切片动辄几百 MB 到几个 GB。如果你只有 16 GB 内存，上来就读 10 个样本——嗯，等着系统 OOM killer 吧。我在一个项目中遇到过，同事把 32 GB 机器跑满，结果 swap 分区一直写，一个脚本跑了三个小时还没出结果。后来一看，90% 的时间花在内存交换上了。
怎么识别？ 用最简单的方法：
# 实时看内存和 swap
free -h
# 看进程 RSS
top -o %MEM
# 或者用 htop 更直观
htop一旦 swap used 持续增长，或者 free -h 显示 available 低于总内存 10%，基本可以断定是内存瓶颈。
我个人的经验阈值：
- < 32 GB 内存：只能跑 1~2 张 Visium 切片，且要用 memory-mapped 读取
- 64 GB：可以处理 4~6 张，但 Spotclean 之类的预处理需要手动释放内存
- 128 GB+：基本能跑完整 pipeline，但别开太多并行
我曾经踩过的坑：R 语言的 Seurat 对象在转 H5 时，如果不清除中间变量，会在内存里残留一份冗余。一个 3 GB 的 Seurat 对象，加上转换后的 AnnData，直接翻到 9 GB。后来我养成习惯，每步之后显式调用 gc() 或 del。
2.2 CPU 瓶颈——别被核数骗了
你以为 64 核就一定快？错了。空间单细胞很多步骤是串行的。举个例子，读取每个 spot 的 barcode 计数矩阵——这步只能用单线程。你分配 64 个核，只有 1 个在工作，剩下的 63 个在围观。
怎么识别 CPU 瓶颈？ 看 CPU 占用率和负载曲线：
# 每个核的使用率
mpstat -P ALL 1
# 负载和平均负载
uptime
# 看哪些步骤吃 CPU
pidstat -u 1如果 %user 不高于 80%，而 %iowait 很高，说明 CPU 在等 I/O，这时候别加 CPU 了。反过来，如果 %user 接近 100% 但只有 1~2 个核满载，那就是并行度不够。
| 观测现象 | 瓶颈类型 | 常见原因 |
|---|---|---|
| load average > CPU 核数×2 | CPU 过载 | 并发任务太多，或算法不优化 |
| 单核 100%，其他核空闲 | 串行瓶颈 | 基因计数、Umap 投影等步骤 |
| %iowait > 30% | I/O 瓶颈 | 不是 CPU 问题，别加核了 |
| 用户态低，系统态高 | 系统调用开销 | 频繁的文件读写或网络请求 |
我的建议：对于 Python 的 Scanpy，用 num_workers 参数调并行。但我发现实际效果并不线性——超过 8 个 worker，磁盘争抢反而更慢。所以一般我会控制在 4~8 之间。
2.3 GPU 瓶颈——显存是硬天花板
说到 GPU，很多人以为只要上了 GPU 就起飞。但空间单细胞里的深度学习模型（比如 SpaGCN、stLearn、SEDR）对显存需求很凶猛。一张 12 GB 的 RTX 3060，跑个 5000 spot 的数据集都紧张。
怎么识别 GPU 瓶颈？
# 看显存使用、GPU 利用率
nvidia-smi
# 或者持续监控
watch -n 1 nvidia-smi重点关注两个值：
- Memory-Usage：如果接近 100%，恭喜你，碰到显存天花板了。这时要么换大显存卡，要么降 batch size。
- GPU-Util：如果经常低于 50%，说明数据加载或预处理是瓶颈，GPU 在等 CPU 投喂。
我记得有一次跑 SpaGCN，GPU 利用率只有 20%，但显存用了 10 GB。一看 Input pipeline，每次都是 CPU 算完所有 spot 的距离矩阵才传给 GPU。改成了异步预处理，GPU 利用率直接跳到 85%。
另外注意——某些框架默认用 CPU 回退。比如 TensorFlow 的 tf.config.list_physical_devices('GPU') 如果返回空列表，说明代码根本没用到 GPU。这种乌龙我见过不止一次。
2.4 I/O 瓶颈——隐藏最深的拖油瓶
这一点我特别想强调。很多人上来就去优化算法，其实 80% 的慢都出在 I/O 上。空间单细胞数据是稀疏矩阵、HDF5、H5AD、TIFF 图像的混合体。小文件满天飞，加上 NFS 网络延迟，等着哭吧。
怎么识别 I/O 瓶颈？
# 磁盘读写速率
iostat -x 1
# 看每个进程的 I/O
iotop
# 文件系统挂载参数
mount | grep nfs关键指标：
- await：IO 请求平均等待时间，超过 10 ms 就需要注意了
- %util：如果持续接近 100%，磁盘基本满载
- r/s, w/s：单位时间读写次数。小文件多导致 IOPS 打满，但吞吐量很低
| 环境 | 典型症状 | 推荐解法 |
|---|---|---|
| 本地 HDD | 高 await，低 IOPS | 换 SSD |
| NFS 远程挂载 | 高延迟，小文件慢 | 改用并行文件系统（Lustre/GPFS）或本地缓存 |
| HDF5/H5AD 读取 | 单线程读取卡住 | 启用 chunked storage + compression filter |
| 大量 .mtx.gz | gzip 解压 > 读取时间 | 预解压或改用 zstd |
我曾经在云上做项目：所有数据放在对象存储（S3）上，每次读取都走 HTTPS 下载。跑一次完整 pipeline 需要下载 30 GB 数据，解压缩再处理。光是数据准备就占了总时间的 40%。后面改成先挂载本地 SSD 缓存，用 rsync 增量同步，一下子快了 3 倍。
2.5 多瓶颈叠加——实际中常常是组合拳
你看，找单一瓶颈不难。难的是好几个瓶颈同时出现。我举个例子：
- 内存不够 → 触发 swap → 磁盘 I/O 飙升
- 磁盘 I/O 飙升 → CPU 等待 → %iowait 变高
- CPU 空闲但 GPU 节点内存不够 → 模型训练失败
这时候你单看 top 是看不出门道的。需要一套排查流程：
- 先用
dstat或者htop看全局概览 - 确认资源消耗最大的进程（
ps aux --sort=-%mem） - 对疑点进程用
strace -c -p看系统调用时间分布 - 如果是 Python 程序，加上
memory_profiler和cProfile定位热区
# 一条查看所有瓶颈的命令（综合）
dstat -t -c -d -m -n --top-cpu --top-io --top-mem 5这样每 5 秒输出一次，你能同时看到 CPU、内存、磁盘、网络和占用最高的进程。配合我上节提到的基线记录，一眼就能看出哪里异常。
我的习惯：准备一个笔记本，专门记录每次跑 pipeline 时的资源图。时间一长，我都不用跑命令，看任务日志里的 wall time 和 max_memory 就能猜出瓶颈是啥。说白了，经验就是靠这些记录堆出来的。
到这儿，四类瓶颈的识别方法基本讲完了。下节咱们会讲怎么根据这些瓶颈去配置硬件——嗯，别急着买卡，先得搞清楚自己的瓶颈到底在哪里。不然就是花冤枉钱。