Ruby on rails unicorn下的大量线程

我正在调试应用程序中的一些Posgtres连接泄漏。几天前，我们突然跨越了100个连接，而我们不应该这样做，因为我们只有8个独角兽工人和一个sidekiq进程（25个线程）

今天我在看htop，看到大量线程从我的独角兽工人那里产生。例如：

我读对了吗？这不应该发生，对吗？如果这些线程正在生成，您知道如何调试它吗

谢谢！顺便说一句，我的另一个问题-（Postgres连接）

编辑

我只是在这里遵循了一些技巧--当我从工作线程打印堆栈跟踪时，这里是当有许多线程时我得到的

[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `pop'
[17176] /u/apps/eventstream_production/shared/bundle/ruby/2.2.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:1057:in `block in spawn_threadpool'
[17176] ---
[17176] -------------------

这是我的unicorn.rb，它为after_fork中的EventMachine生成了一个线程

EventMachine的原因是-->

这正常吗？线程不应该被杀死吗？这是否也会导致不必要的数据库连接被打开？ 谢谢

更新： 我刚刚发现我使用的是一个旧版本的PubNub gem，它使用EM，我在PubNub.log文件中遇到了这些行-

D, [2016-04-06T21:31:12.130123 #1573] DEBUG -- pubnub: Created event Pubnub::Publish
D, [2016-04-06T21:31:12.130144 #1573] DEBUG -- pubnub: Pubnub::SingleEvent#fire
D, [2016-04-06T21:31:12.130162 #1573] DEBUG -- pubnub: Pubnub::SingleEvent#fire | Adding event to async_events
D, [2016-04-06T21:31:12.130178 #1573] DEBUG -- pubnub: Pubnub::SingleEvent#fire | Starting railgun
D, [2016-04-06T21:31:12.130194 #1573] DEBUG -- pubnub: Pubnub::Client#start_event_machine | starting EM in new thread
D, [2016-04-06T21:31:12.130243 #1573] DEBUG -- pubnub: Pubnub::Client#start_event_machine | We aren't running on thin
D, [2016-04-06T21:31:12.130264 #1573] DEBUG -- pubnub: Pubnub::Client#start_event_machine | EM already running

---

所以，毕竟，在你的特殊情况下，这种行为似乎是正常的

您提供（使用）的unicorn线程堆栈跟踪指向。EventMachine中的此代码在其他代码调用时调用，此方法在第一次调用时默认为20个线程池。我在较旧版本的

publinub

gem（例如）中发现了

EventMachine.defer

的用法，但它也可以从其他地方使用

因此，我认为这解释了您在每个worker上观察到的大量线程。它们大多在队列中等待，该队列暂停线程，直到有东西被推送到队列中（在EventMachine中再次延迟）。因此，除非您有大量的延迟操作，否则线程基本上什么也不做

如果您不需要在每个unicorn worker上准备20个线程以进行可延迟的操作（很可能您不需要），您可以尝试通过将设置为某个合理的数字来降低池中的线程数，例如：

EventMachine.threadpool_size = 5

我会把它放在unicorn配置中的

after\u fork

块中的某个地方

另外，作为另一种选择，您可以考虑使用周期性地杀死独角兽的工作人员。

---

顺便说一句，

pubnub

吐到其日志中的消息似乎没有问题，因为它只是告诉我们它发现了一个已经初始化的EventMachine线程，因此它不必启动一个新线程。澄清它。

今天在版本4中遇到了这个问题。当在后台工作线程中使用PubNub时，线程数将继续攀升，直到出现错误。解决办法如下：

client = Pubnub.new(...)
client.publish(...)
client.telemetry.terminate

---

我也不认为这是正常的。也许您正在应用程序代码中使用

线程

s？您是否可以尝试使用所描述的过程从unicorn线程获取堆栈跟踪（请特别参阅Ruby在任何给定时刻都在做什么？一节）？这样你可能会发现线程在哪里徘徊。哇。感谢@BoraMaI的链接，我猜你在

数据库.yml中配置了
reaper\u frequency
，所以中间线程是最常见的，我认为这是正常的。我们应该等到线程累积…@BoraMa ah ok.：）更新发现。真棒！！！！我非常感谢你分享了这么多东西如果不是太不礼貌的话，您是否可以查看我的其他问题-谢谢：）