监控目录的变化 - 潜在的高内存答案

【问题标题】：Monitoring directory for changes - potential high memory监控目录的变化 - 潜在的高内存
【发布时间】：2011-08-18 03:34:09
【问题描述】：

我目前正在使用 nodeJS 中的脚本来监视目录（及其子目录），并在将文件放置在那里后执行一些功能。实际上，这将是一个 FTP，用户在其中上传文件，对其进行处理，然后删除。

显然，我已经看到脚本的 CPU 使用率很高，因为它遍历目录，等待文件可见。但让我担心的是脚本运行的时间越长，内存使用量就越高（它只是呈指数级增长）。是否有一些轻量级的方法来监视目录的更改？

谢谢！

编辑：我目前正在使用 watch-tree，这很棒，但仍然存在内存增加问题。

【问题讨论】：

您识别的是第 3 方代码中的内存泄漏。尝试使用supervisor 它不太可能发生内存泄漏。（它是由 Isaacs 制作的！！）
听起来是个不错的选择！添加文件时如何监视目录（和子目录）？节点主管似乎只监视文件的更改（例如 server.js）
它还监视所有.js 文件的任何子目录。如果您尝试supervisor --help，它应该有一个-js 选项以进行更详细的控制。
感谢@Raynos，我已经开始配置它，并且正在使用以下命令 - supervisor -w Sites/data -e txt Sites/server.js - 根据带有监控的文档txt 文件的站点/数据文件夹。我的问题是，我如何访问这些更改？我希望能够传入它拾取的文件，这些文件已更改为在我的 server.js 中处理...
默认情况下，主管在文件更改时重新启动您的服务器。这是热重载。没有程序化 API。

【解决方案1】：

听起来你想要一个 FAM 或 inotify 的包装器。也许像node-inotify-plusplus 这样的东西对你有用。

【讨论】：

谢谢@rjp，我一直在研究类似的东西。我对任何解决方案的主要问题是监控过程将占用的内存级别，因为该系统需要一次在线 8 小时。 inotify 是一个好方法吗？根据我的研究，它是操作系统的一部分，因此内存效率很高......
FreeBSD/OS X 用户需要使用 kqueue 解决方案，因为这些平台上不存在 inotify/epoll。
可以用node-inotify-plusplus打印目录下文件修改的文件名吗？
另外，是否有可用的示例程序（使用 node-inotify）？我认为我们需要一些具体的例子来解决这个问题（并且 node-inotify 的文档相当混乱，所以一些例子在这里会有所帮助。）
@rjp 你能告诉我它与官方节点 api 中的fs.watch 有什么不同吗？