Linux inotify 监听大量文件时怎样控制资源

Linux inotify 监听大量文件时，先减少监听对象和无用事件，再分别预算 watch、instance 与事件队列。若业务只需要知道某目录内容发生变化，通常应监听目录、维护有上限的脏目录集合，而不是给每个文件创建独立监听。提高限制只能增加容量，不能修复消费速度不足或丢失后的状态不一致。

官方接口文档：https://man7.org/linux/man-pages/man7/inotify.7.html

先把文件数量换成监听对象预算

这次迁移的是应用的监听策略，不是某个内核版本升级。目标是本地目录索引、增量构建等“最终状态正确”任务，不是记录每一次文件操作的审计系统。下面是设计对照：

目录监听并不递归，子目录仍须单独登记。估算预算时，数的是实际需要覆盖的目录或 inode，而不是文件总数；硬链接也不能简单按路径数量等同于独立 watch。排除构建输出、依赖缓存、临时文件夹通常有用，但索引业务依赖这些内容时不能直接排除。

区分三种配额和两个常见错误

max_user_watches约束同一真实用户 ID 的 watch 总量，max_user_instances约束其 instance 数量。一个 instance 拥有自己的事件队列，max_queued_events在创建 instance 时用于确定队列容量。调高 watch 数不会自动提高另两项。配置应按同一用户下所有工具共同预算，不按单个应用独占计算。

inotify_add_watch()的 ENOSPC可能表示 watch 配额到达，也可能是内核所需资源无法分配，不应只按“磁盘满”处理。ENOMEM表示内核内存不足；权限、路径和对象类型错误则要单独处理。重复登记同一 instance 内已监听的 inode，会返回已有 watch descriptor，并可能修改其 mask，不能把重复调用当成互不干扰的订阅。

inotify_init1()的 EMFILE既可能来自 instance 配额，也可能来自进程打开文件描述符限制；ENFILE对应系统范围的打开文件限制。创建非阻塞 instance 可使用 IN_NONBLOCK，并用 IN_CLOEXEC减少 exec 后意外保留描述符；这些标志不提升容量，也不替代关闭资源。

用 fdinfo 看实际占用，不猜默认值

先在目标 Linux 主机读取当前值，默认值会受系统和配置影响。以下均为只读示例，不包含直接改系统配置的命令：

# 分开读取 watch、instance 和队列限制，保留输出用于预算
sysctl fs.inotify.max_user_watches fs.inotify.max_user_instances fs.inotify.max_queued_events

# 使用目标服务 PID；12345 只是示例，不代表实际进程
watch_pid=12345
awk '/^inotify wd:/ {n++} END {print "fdinfo watch 行数:", n+0}' /proc/"$watch_pid"/fdinfo/*

# 同时查看该进程文件描述符限制，避免把 EMFILE 全归因于 inotify
awk '/Max open files/ {print}' /proc/"$watch_pid"/limits

/proc/PID/fdinfo中，inotify 文件描述符条目会列出监听信息。上面的总数是该进程可见条目中 watch 行的合计，不是整个用户的精确去重占用：共享 instance、复制描述符或跨进程共享会让简单加总重复计数。进程退出、权限不足也会导致读失败。预算更适合结合应用维护的 instance/watch 计数，记录峰值与失败接口，而不是只抓一次数字。

只有确认需求真实且主机资源允许时再调整系统参数，并保存原值与持久化配置来源。队列上限变更不能假设已经改变既有 instance 的容量，必要时按维护计划重新创建。不要给所有主机复制一个无限放大的“通用推荐值”。

把事件消费与业务任务分开

内核会合并尚未读取的相邻同类事件，应用不能依靠事件条数统计写入次数。因此建议把事件理解为“这个范围的状态需要重新读取”。消费层尽快读取并解析，昂贵的文件扫描、哈希和重建交给受限工作队列。

应用侧可以设计如下数据结构：dirty_dirs按目录去重，work_queue承接扫描任务，rescan_required代表索引可能失效。这些是应用设计标识，不是 inotify API。目录集合大小和工作队列长度都设上限；达到上限时升级为受控重建，不能继续无限追加路径。

合并策略还要同时限制安静等待窗口和最长等待时间。只采用“最后一次事件之后再等一会儿”，在持续写入时可能永远不触发处理。批量大小、并发扫描数与截止时间应根据业务延迟目标设置，记录合并后的任务数与恢复耗时，不在没有测量时承诺性能提升比例。

溢出意味着索引不再可信

遇到 IN_Q_OVERFLOW，该 instance 的事件历史已经不完整；此类事件的 wd为 -1。应先识别它，再做普通 wd 到路径的查找，不能因查不到目录而忽略。业务缓存需要标记失效，并在受控预算下重建可能受影响的范围；没有证据时不要只刷新最后看到的一个文件。

新目录出现或移入后，登记监听并扫描已存在内容，考虑登记前后的竞态。重建期间继续接收变化，安排必要的补扫；“扫完一遍”并不自动成为强一致快照。重命名事件要允许跨读取批次和缺失配对。移出监控范围、目录删除与 IN_IGNORED还需要维护路径映射与监听生命周期。

停止服务时关闭所持描述符；所有引用该 instance 的描述符关闭后，相关监听资源才释放。对于网络文件系统上的远端变化、mmap 写入等限制，不应承诺 inotify 全部捕获；需要另行确定业务是否接受轮询或其他同步机制。

迁移前后要比较哪些现象

先在小范围切换，再按相同文件树和变更负载比较：登记 watch 峰值、instance 数、读取延迟、业务队列高水位、溢出次数与索引恢复时间。不要只比较进程 RSS，它不能替代内核资源预算。下面场景供读者做回归，本文没有实际执行这些测试。

• 同目录连续写入：任务可以合并，但最长等待时间应有界。
• 原子替换与跨目录重命名：最终路径和内容能够重新读取。
• 新子树移入：已有文件不能漏进索引，子目录监听能补齐。
• 消费者短时变慢：工作队列不无限增长；溢出后进入可观测的恢复状态。
• 反复启停：应用计数回落，不能留下不必要的实例引用。

迁移清单很短：确定覆盖范围，登记实际资源预算，限制业务队列，实现失效重建，最后再讨论调高系统配额。旧逐文件方案是否回退，要由覆盖能力与资源指标决定；回退也必须遵守当前额度，不能同时长期运行两套全量监听。

提高 ulimit 就能解决 watch 不足吗？

不能。打开文件描述符限制与 watch 配额不是同一个资源；应根据具体失败的系统调用判断。

能把每个事件都当作一次写入吗？

不能。合并与溢出都让事件数量失去精确计数意义，inotify 更适合变化通知。

目录监听会漏掉子目录吗？

只登记父目录不足以覆盖深层目录，需要管理子目录的监听和新增内容扫描。

接口参考：https://man7.org/linux/man-pages/man2/inotify_add_watch.2.html、https://man7.org/linux/man-pages/man2/inotify_init.2.html、https://man7.org/linux/man-pages/man5/proc_pid_fdinfo.5.html。