Calibre 资源不足速查：OOM killed、Too many open files 与磁盘写满怎么分

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。Calibre 跑大芯片 DRC/LVS/PEX 时，「跑不动」有一大半不是工具坏了，而是某一类系统资源先撞到天花板：内存被 OOM-killer 杀、文件句柄耗尽、工作目录所在磁盘写满、线程开太多把每核内存翻几倍。这四类问题症状都像「作业挂了」，判据和处置却完全不同。本篇只讲资源配额触顶的分诊与降载；非法内存访问导致的崩溃见 Calibre 段错误崩溃速查，不退出也不推进的卡死见 Calibre 运行卡死/超时速查，正常流程背景见 Calibre 物理验证实操，排错总入口见 开源 EDA 报错排错中心。

本文要回答的问题

• calibre 进程跑着跑着消失，dmesg 里有 OOM 记录，怎么确认就是它？
• 报 Too many open files 是工具 bug 还是系统限额，限额在哪改？
• 作业在导出结果阶段死掉，和内存耗尽有什么不同体征？
• -turbo 开了多线程，为什么内存占用反而成倍涨？
• 不换机器，有哪些手段把一次验证的资源峰值压下来？

一、报错原文与现象

资源触顶的现场通常是下面四类之一，主机名与路径均为占位。

1. 内存耗尽，进程突然消失或自己报错：

Killed
# dmesg:
Out of memory: Killed process 41722 (calibre) total-vm:208G, anon-rss:132G

或 Calibre 自己在 transcript 里留下分配失败的记录后退出：

Error: Out of memory.  Cannot allocate <size> bytes.
Fatal: Memory allocation failed during geometry processing.

前者是内核 OOM-killer 挑内存占用最大的进程开刀，Calibre 来不及说话；后者是它主动申请内存失败，说明先撞到了某条限制线。

2. 文件句柄耗尽：

ERROR: Unable to open file "<run>/svdb/...": Too many open files

不是磁盘满，也不是权限问题，而是单进程打开文件数超过了 ulimit -n 的线。

3. 磁盘空间或 inode 写满，且常发生在结果导出阶段：

No space left on device
Disk quota exceeded: cannot write to <work_dir>/drc_results

空间和 inode 是两条独立的线：df -h 看着有余量，df -i 却可能已经 100%——海量小结果文件吃的是 inode。

二、四类资源速查表

现象 / 尾行	资源类型	一判据	处置方向
终端只剩 Killed，dmesg 有 OOM 行	物理内存	dmesg | grep -i kill 见 calibre	降峰值、减线程、换大内存机
transcript 报 Out of memory 后退出	内存限制线	ulimit/cgroup/调度 MEMLIMIT	查限额来源，放宽或压进配额
-turbo 线程越多越早死	线程×内存叠加	RSS 随线程数近似成倍上涨	降低 -turbo 线程数
Too many open files	文件句柄	ulimit -n 仅四位数	提交脚本里调高 nofile
No space left / Disk quota exceeded	磁盘空间	df -h <work_dir> 100%	清 SWDB/临时结果、换大盘
df -h 有余量但写文件失败	inode	df -i IUse 100%	清海量小文件目录
时报时不报、并发时才死	多作业抢资源	dmesg 时刻多作业并存	调度层限并发、内存准入

表中量级都是典型形态，具体阈值一律以本机、本单位调度策略与所用 Calibre 版本为准。

三、分诊决策图

先判资源类型，再谈降载，是这类问题唯一的正确顺序。

读这张图抓住一个分叉：入口只有一个「作业异常终止」，但 dmesg、ulimit、df 三条命令会把它切成内存、句柄、磁盘三条互不相干的通道。红色是入口现象与命中的资源根因，蓝色是分诊动作，橙色是对症降载，紫色是把一次性救火沉淀成监控与预算。不要四类问题一律「重排试试」——句柄和磁盘问题原命令重跑必然在同一堵墙上再死一次。

四、逐条排查展开

第一步永远是问内核，而不是先猜参数。 进程消失后立即执行：

dmesg | tail -50 | grep -i -E "kill|memory"
ulimit -a | grep -E "open files|virtual|stack"
df -h <work_dir> ; df -i <work_dir>

dmesg 里出现 Killed process ... (calibre) 并附带 total-vm/anon-rss，就是 OOM 实锤，还顺手给出了案发时的内存水位；任务日志最后停在几何处理（geometry）或 PEX 提取阶段，与大版图展开的内存高峰吻合。若进程是报 resource limit 一类错误退出而非被信号杀死，则查 ulimit、cgroup memory.max 以及 LSF 的 MEMLIMIT——机器有空内存却申请失败，基本都是撞在这些人为限制线上。

内存类问题的第一刀：砍线程，而不是先申请机器。 Calibre 的多线程（常见入口是 -turbo，线程数写法与默认值随版本和 license 特性不同，以本单位版本的手册为准）在版图并行分区时，各线程要维护各自一份几何数据，典型表现是线程数翻倍、RSS 也成倍上涨。大芯片在 16 线程下勉强能跑、开到 32 线程反而 OOM，是常见现象而非异常。先把线程数压到物理核数与 license 多线程席位的较小值，再看峰值落多少；线程与席位不匹配时还会内部排队，表现与 Calibre 运行卡死/超时速查 中的假性卡死同源。部分版本提供内存上限类选项（如以 -maxmem 一类命名的开关，具体名称与语义查本机 calibre -help 与发行说明，不要跨版本照搬），它的作用是让工具在接近上限时主动收缩并行度，属于保险丝而非扩容手段。

第二刀：层次化验证与分块，缩小单趟处理规模。 flat（展平）模式会把整颗芯片在内存中展开，层次越深、重复单元越多，展平后的几何数据膨胀越剧烈。两种拆法：一是 hierarchical/层次化流程，让工具按设计层次分而治之，顶层只处理边界交互；二是按窗口或指定单元分块（window 验证、selected cell 验证），把一次全芯片 DRC 切成多块提交，单块峰值只与最大块相关，而不是总和。代价是边界区域需要补验证、流程与结果合并更复杂——这是拿周转流程换可跑性，大芯片迟早要做。

句柄类问题：调 open files 限额。 SVRF 规则 include 大量文件、SWDB 结果库以大量小文件组织时，Calibre 单进程同时打开的文件数会冲到五位数，而不少登录环境的 ulimit -n 默认只有 1024 或 4096。在提交脚本开头显式调高（如 ulimit -n 65536，能否设置及上限受 /etc/security/limits.conf 约束，以管理员配置为准），LSF 作业还要确认作业环境继承的是新值而非交互默认值。改完用 cat /proc/<pid>/limits 对运行中的进程核实，不要只信提交终端的回显。

磁盘类问题：盯住工作目录，而不是家目录。 Calibre 运行时写的 SWDB 数据库、临时结果和导出报告都落在 runset 指定的工作目录，常见翻车点是工作目录在配额很小的家目录或 NFS 共享盘上。处置三件套：确认 df -h 与 df -i 两条线；把历史 run 的 SWDB 与临时目录清理或归档；大芯片的工作目录放到本地大盘或配额充足的专用卷，NFS 只做结果归档。inode 耗尽专坑海量小文件的结果库，表现就是「空间还剩很多却写不进去」。

降载仍不够时，换机器并把峰值测出来。 内存是这四类资源里唯一没法靠「删东西」腾出来的——层次化和分块是压缩需求，物理内存才是容量。提交到大内存队列前，先用采样把真实 RSS 峰值记下来，作为申请配额的依据：

top -b -d 30 -p <pid> | tee calibre_rss.log

看 RES（常驻物理内存），不要看 VIRT。同机并发多个大作业时，单作业峰值没变也可能叠加 OOM，且被杀的往往是「最肥」的那个 calibre——这类问题改工具参数无效，要在调度层做内存准入和并发上限。

五、预防与纪律

• 新 deck 首跑先测峰值：RSS 采样曲线归档为该设计的内存预算基线，规模增长时同步上调。
• 提交脚本固定四连查：显式 ulimit -n、确认工作目录所在卷的空间与 inode、输入重定向、日志落盘，不继承登录环境的默认限额。
• 线程数对齐两顶帽子：物理核数与 license 多线程席位取较小值，内存吃紧时宁可减线程。
• 大芯片默认层次化模板：规模超过单机可跑水位的设计，直接走层次化/分块脚本，不等 flat 跑挂了再返工拆。
• 工作目录与归档分离：SWDB 进本地大盘，跑完只归档报告与必要结果，定期清临时库。
• 并发受内存准入管控：按物理内存与单作业预算限制同机作业数，避免峰值叠加触发随机 OOM。

这一篇在知识体系里的位置

本篇是 EDA 排错速查簇中「资源触顶」节点的 FAQ 页，与 Calibre 段错误崩溃速查（非法内存访问，查规则与数据而非配额）、Calibre 运行卡死/超时速查（不退出也不推进）合起来覆盖 Calibre 运行期故障的三种主要死法；物理验证的正常 runset 与流程见 Calibre 物理验证实操，更多 EDA 报错主题从 开源 EDA 报错排错中心 进入。

一句话总结

Calibre 资源不足先按「内存、句柄、磁盘」分诊：进程突然消失查 dmesg 的 OOM 记录，Too many open files 查并调高 ulimit -n，导出阶段死查 df -h 与 df -i 两条线；确认内存触顶后，先砍 -turbo 线程数（线程翻倍常带来 RSS 翻倍），再上层次化验证与窗口/单元分块压缩单趟规模，配合工作目录清理与大内存提交机，最后把 RSS 峰值、线程数与工作卷空间写进提交脚本纪律防复发。