背景：
手头的某个项目系统上线运行了很长一段时间了，之前一直在给客户解决功能性的需求问题，现在才着手处理系统运行中的稳定性问题和性能问题。
环境：
Ruby 1.9.3-p374 + Rails 3.2.11 + Unicorn 4.5.0 + Nginx
现象：
现象 1：unicorn.stderr.log 中几乎每天都有几条这样的出错信息：
Error: Couldn't open file ':source'（就这么一行几个单词，前面连时间都没有），nginx 的 error.log 中时不时也有这样的出错信息：2013/01/06 13:56:58 [error] 1484#0: *12266 upstream timed out (110: Connection timed out) while reading response header from upstream...，但在 production.log 中却没有显示现象 2：系统运行时似乎存在内存泄漏，内存占用会一直地缓慢上升，让我不得不十天半个月左右重启一下 unicorn
问题：
问题 1：现象 1 中的
Error: Couldn't open file ':source'是否就是upstream timed out引起的？（由于 unicorn 的这一条出错信息前没有时间，所以我只是怀疑，无法肯定）原因是什么？如何消灭它？问题 2：内存泄漏一般说来是什么引起的？是我代码的问题还是 Rails 本来就有这个问题？
请各位不吝指教，谢谢。
给你一个参考的 unicorn 配置文件，你给的信息很少，所以只能说 配置有问题。。至于 nginx 报上游服务器超时，是因为 unicorn 启动失败导致的 https://github.com/jasl/start_up/blob/master/config/unicorn/production.rb 另，内存泄露一直是 ruby 的老毛病，所以 unicorn 默认是 30s 重启一次 worker
@jasl 谢谢关注。
信息很少是因为这条出错信息太孤立了，就这么孤零零的一行时不时的出现，google 也找不到类似的案例。
我认为应该不是配置问题，但我回头把 unicorn 完全按手册重新配置一遍看看能不能解决这个问题。
关于内存泄漏，的确看来是一个普遍现象，我就暂时不去纠结这个问题了，呵呵。不过我刚刚发现了这个东西：https://github.com/kzk/unicorn-worker-killer 可以代替我的手工重启 unicorn 的需求。
BTW，您说的 unicorn 默认 30s 重启一次 worker 肯定是理解错了，应该是worker 的执行时间超过 30s 就重启它
如果我记得没错的话，30s 的设置是超时时间，比如你的 rails 有个数据查询超过 30 秒，导致 unicorn 无法在 30s 内返回 response，此时 master process 自动去 fork and kill 当前这个 worker process。
@lgn21st 恩，就是这样的，你这个解释更全面。
考虑过一般机器的性能，特别是 VPS 上的话，得适当增大超时时间才行，我一般是设置为 65s，超过 65s 的慢查询才使用 delayed_job 放到后台，不然需要异步执行的代码就太多了。