如何在 Ruby on Rails 中监视打开的文件描述符？
背景：
我的 Rails 服务器最近遇到了一个问题，它会停止响应，需要反弹才能恢复并运行。此问题是由于控制器在收到 POST 后进行一些分叉，以执行一些重量级并发处理 - 服务器响应时间不断增加，直到服务器完全停止响应。我很确定我已经解决了这个问题（在 fork 上复制的数据库连接没有在子进程中关闭），但是如果能权威地测试这个问题就太好了。
问题：
有没有办法从我的 Rails 应用程序内部监视打开的文件描述符？它在 Linux 上运行，因此我一直在研究 proc 文件系统和 lsof 命令来观察打开的文件描述符；这很混乱，因为它只为您提供当前进程的快照。理想情况下，我想在处理之前、期间和之后打印父进程和子进程中打开的文件描述符，以确保文件描述符不会在欢迎后保持打开状态。
Background:
I had an issue with my Rails server recently where it would stop responding, requiring a bounce to get it back up and running. This issue was due to a controller that does some forking upon receiving a POST, to do some heavy-weight concurrent processing -- server response time kept increasing until the server completely stopped responding. I'm pretty sure I have fixed that issue (DB connections copied upon fork weren't getting closed in child processes), but it would be great to authoritatively test that.
Question:
Is there a way to monitor open file descriptors from inside my Rails app? It's running on Linux, so I've been mucking around with the proc filesystem and the lsof command to observe the open file descriptors; this is messy, because it only gives you a snapshot of the current processes. Ideally I would like to print the open file descriptors in the parent and child processes before, during, and after the processing, to ensure that file descriptors don't stay open past their welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种可以考虑的方法（可能是最简单的）是使用某种后台工作程序，例如使用 Workling，并使其间隔运行 lsof，并使用语法获取输出：
类似 lsof 的程序如果运行过于频繁，确实会损害性能。也许每 10 到 30 秒一次。也许会降低到 5 秒，但这确实是一个挑战。我假设您有一个专用服务器或一个强大的虚拟机。
在后台工作人员中，您可以将这些命令结果存储到变量中，或将其 grep 到您真正要查找的内容（如所示），并根据需要访问/操作数据。
One method to consider (probably the simplest) is using a background worker of some sort, such as with Workling, and making it run
lsofin intervals, and getting output using syntax:Programs like
lsofcan really hurt performance if run too frequently. Perhaps every 10s to 30s. Perhaps down to maybe 5s, but that's really pushing it. I'm assuming you have a dedicated server or a beasty virtual machine.In your background worker, you can store these command results into a variable, or grep it down to what you're really looking for (as demonstrated), and access/manipulate the data as you please.