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