在 Facebook 的 Watchman 应用程序中，文档中的某处写着 this：
大多数系统对可以有效监视的目录数量都有限制；当超过该限制时，文件系统监视的性能和可靠性会下降，有时甚至会停止运行。
这对我来说似乎很模糊。在它“停止运行”之前，如果我开始观看太多文件，我究竟会发生什么？我们是在谈论 100 个文件、1,000 个文件、100,000 个文件吗……？ （我意识到这个数字在不同的系统上会有所不同，但对现代 Unix 笔记本电脑的合理限制的一些粗略想法会很有用）。
我有一个用例，需要查看整个 node_modules 文件夹（其中包含深度嵌套的子目录中的数千个文件），我想在开始研究之前知道它是否完全无法启动。
【问题讨论】：
标签： watchman
抱歉，如果这些文档没有您希望的那么清晰。
首先，我们专门构建了 watchman 来加速必须在非常大的树上运行的工具，尤其是这棵树，自写这篇文章以来，它只会变得越来越大：
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
Facebook 的主要源代码库非常庞大——比 甚至是 1700 万行代码的 Linux 内核 2013 年有 44,000 个文件
我目前没有任何关于回购规模的最新公众号可以分享，但这里的重点是，这对于绝大多数应用程序来说应该都可以正常工作。
现在是超出限制时系统的行为。答案取决于您使用的操作系统。
影响此行为的主要系统限制有 2 个；其中之一是直接限制观看项目的数量；超过时，您将无法观看其他任何内容。在 Linux 上运行时，Watchman 会将这种情况视为不可恢复并将自己标记为中毒；在这种状态下，它不可能准确地报告正在监视的目录数量范围内的文件更改，直到您提高系统限制或放弃尝试监视文件系统的该部分。
在 OS X 上运行时，由于 fsevents API 中的诊断不佳，Watchman 无法判断是否超出了此限制；如果我们无法启动手表，我们可以最好地判断。因为 fsevents 没有告诉我们发生了什么，而且这个限制不是用户可配置的，所以我们不能将进程置于中毒状态。
另一个系统限制是内核为 watchman 进程缓冲的项目数量。如果该缓冲区溢出，内核将开始丢弃更改通知。它将通知守望者它这样做了，这将导致守望者执行（可能，鉴于树可能很大）昂贵的树重新爬网，以确保它可以（重新）发现它可能由于以下原因而错过的任何更改溢出。
OS X 有类似的限制和类似的恢复行为，但不允许用户提高限制。我还没有在野外观察到 OS X 上发生这种情况，所以我假设这个系统限制的默认值是一个非常合理的默认值。
至于各种文件大小的实际限制，这实际上取决于您的系统；文件系统、存储设备、CPU 功率和您可能在该系统上运行的其他应用程序会影响可以将更改应用于文件系统并由内核报告的速率，以及您的系统能够使用来自内核的事件。
更改这些文件的速度是一个重要因素；如果您有一个非常大且繁忙且频繁更改的树（>100 名工程师每天进行多次提交并频繁地变基），那么您遇到重新抓取案例的风险就会增加。
调整系统限制没有万能的解决方案；如果/当你达到极限时，你需要尝试一下并提高极限。
【讨论】：