独角兽下的大量线程
我正在调试应用程序中的一些Posgtres连接泄漏。几天前，我们突然跨越了100个连接，当我们不应该-因为我们只有8个独角兽工人和一个侧基克进程(25个线程)。
我今天看了htop，发现我的独角兽工人正在产生大量的线程。例：
我看对了吗？这不应该发生对吧？如果这些是正在生成的线程，那么知道如何调试吗？
谢谢!顺便说一下，我的另一个问题- (Postgres连接) 调试独角兽postgres连接泄漏
编辑
我只是在这里遵循一些提示- http://varaneckas.com/blog/ruby-tracing-threads-unicorn/ -当我从工人的线程中打印堆栈跟踪时，这里是我得到的，当有很多线程时。
[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 https://gist.github.com/steverob/b83e41bb49d78f9aa32f79136df5af5f，它在after_fork中为EventMachine生成了一个线程。
EventMachine的原因是-> https://github.com/keenlabs/keen-gem#asynchronous-publishing
这是正常的吗？线程不应该被杀死吗？这是否也会导致非必要的db连接被打开？谢谢
更新：，我刚刚发现我使用的是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回答 2
Stack Overflow用户
发布于 2016-04-09 07:06:17
所以，毕竟，在你的特殊情况下，这种行为似乎是正常的。
您提供的独角兽线程堆栈跟踪(使用这种方法获得)指向EventMachine中的方法。EventMachine中的此代码在其他代码调用EventMachine.defer时被调用，这种方法在第一次调用时产卵 默认是由20个线程组成的池。我发现EventMachine.defer在pubnub gem的旧版本(例如这里)中使用，但它也可以从其他地方使用。
因此，我认为，这解释了为什么在每个工作人员身上观察到大量的线程。他们主要在挂起线程的方法中等待，直到队列中有东西被推送(在EventMachine中再次推迟)。因此，除非您有大量延迟操作，否则线程基本上什么也不做。
如果您不需要在每个独角兽工作人员上有20个线程为可推迟的操作做好准备(很可能不需要)，您可以尝试通过将 变量设置为一些合理的数目来降低池中的线程数，例如：
EventMachine.threadpool_size = 5我会把它放在独角兽配置中的after_fork块中。
另外，作为另一种选择，您可以考虑使用独角兽-工匠杀手宝石定期杀死独角兽的工人。
顺便说一句，pubnub向日志中吐出的消息似乎没有问题，因为它只是告诉我们，它找到了一个已经初始化的EventMachine线程，因此它不必启动一个新的线程。这个源代码澄清了这一点。
Stack Overflow用户
发布于 2019-11-25 22:05:15
当在后台工作人员中使用PubNub时，线程数会继续上升，直到我们得到一个错误。解决办法如下：
client = Pubnub.new(...)
client.publish(...)
client.telemetry.terminatehttps://stackoverflow.com/questions/36497328
复制相似问题
腾讯云开发者
