PumaサーバがDeadrockする

Question

Ruby on Railsのアプリケーションを動かしているとたびたびPumaがDeadrockしてしまいます
常にというわけではなくたまに起こり、再現性はありません。

再起動すれば直るのですが、最終的な解決には至っていません。

環境

CPU 1core, RAM 4GB, CentOS7

エラーログ

vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/session/abstract/id.rb:226:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/cookies.rb:613:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/callbacks.rb:26:in `block in
 /home/mastodon/.rbenv/versions/2.5.0/lib/ruby/2.5.0/delegate.rb:83:in `method_missing'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack/store_proxy/redis_store_proxy.rb:31:in `in
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack/cache.rb:49:in `do_count'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack/cache.rb:19:in `count'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack/throttle.rb:27:in `[]'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack.rb:89:in `block in throttled?'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack.rb:88:in `any?'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack.rb:88:in `throttled?'
 vendor/bundle/ruby/2.5.0/gems/rack-attack-5.0.1/lib/rack/attack.rb:143:in `call'
 vendor/bundle/ruby/2.5.0/gems/warden-1.2.7/lib/warden/manager.rb:36:in `block in call'
 vendor/bundle/ruby/2.5.0/gems/warden-1.2.7/lib/warden/manager.rb:35:in `catch'
 vendor/bundle/ruby/2.5.0/gems/warden-1.2.7/lib/warden/manager.rb:35:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/etag.rb:25:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/conditional_get.rb:25:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/head.rb:12:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/session/abstract/id.rb:232:in `context'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/session/abstract/id.rb:226:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/cookies.rb:613:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/callbacks.rb:26:in `block in
 vendor/bundle/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/callbacks.rb:97:in `run_callbacks'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/callbacks.rb:24:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/debug_exceptions.rb:59:in `c
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/show_exceptions.rb:31:in `ca
 vendor/bundle/ruby/2.5.0/gems/lograge-0.7.1/lib/lograge/rails_ext/rack/logger.rb:15:in `call_app'
 vendor/bundle/ruby/2.5.0/gems/railties-5.1.4/lib/rails/rack/logger.rb:24:in `block in call'
 vendor/bundle/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/tagged_logging.rb:69:in `block in tag
 vendor/bundle/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/tagged_logging.rb:26:in `tagged'
 vendor/bundle/ruby/2.5.0/gems/activesupport-5.1.4/lib/active_support/tagged_logging.rb:69:in `tagged'
 vendor/bundle/ruby/2.5.0/gems/railties-5.1.4/lib/rails/rack/logger.rb:24:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/remote_ip.rb:79:in `call'
 vendor/bundle/ruby/2.5.0/gems/request_store-1.3.2/lib/request_store/middleware.rb:9:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/request_id.rb:25:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/method_override.rb:22:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/runtime.rb:22:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-timeout-0.4.2/lib/rack/timeout/core.rb:122:in `block in call'
 vendor/bundle/ruby/2.5.0/gems/rack-timeout-0.4.2/lib/rack/timeout/support/timeout.rb:19:in `timeout'
 vendor/bundle/ruby/2.5.0/gems/rack-timeout-0.4.2/lib/rack/timeout/core.rb:121:in `call'
 vendor/bundle/ruby/2.5.0/gems/actionpack-5.1.4/lib/action_dispatch/middleware/executor.rb:12:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-2.0.3/lib/rack/sendfile.rb:111:in `call'
 vendor/bundle/ruby/2.5.0/gems/rack-cors-0.4.1/lib/rack/cors.rb:81:in `call'
 vendor/bundle/ruby/2.5.0/gems/railties-5.1.4/lib/rails/engine.rb:522:in `call'
 vendor/bundle/ruby/2.5.0/gems/puma-3.11.0/lib/puma/configuration.rb:225:in `call'
 vendor/bundle/ruby/2.5.0/gems/puma-3.11.0/lib/puma/server.rb:624:in `handle_request'
 vendor/bundle/ruby/2.5.0/gems/puma-3.11.0/lib/puma/server.rb:438:in `process_client'
 vendor/bundle/ruby/2.5.0/gems/puma-3.11.0/lib/puma/server.rb:302:in `block in run'
 vendor/bundle/ruby/2.5.0/gems/puma-3.11.0/lib/puma/thread_pool.rb:120:in `block in spawn_thread'
 method=GET path=/ format=html controller=HomeController action=index status=401 duration=18.72 view=0.00 d

 ThreadError (deadlock; recursive locking):

 app/models/setting.rb:26:in `[]'

試したこと

最初はpumaサーバのワーカ数がCPUコア数と一致していなかったことが原因かと思って、
workersを0に変更しました。
しかし未だにdeadrockが起こります。

#Puma server settings
WEB_CONCURRENCY=0
MAX_THREADS=5

#config/puma.rb
threads_count = ENV.fetch('MAX_THREADS') { 5 }.to_i
threads threads_count, threads_count

if ENV['SOCKET'] then
  bind 'unix://' + ENV['SOCKET']
else
  port ENV.fetch('PORT') { 3000 }
end

environment ENV.fetch('RAILS_ENV') { 'development' }
workers     ENV.fetch('WEB_CONCURRENCY') { 0 }

preload_app!

on_worker_boot do
  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)
end

plugin :tmp_restart

どこに原因があるかも不明な状態なので、なにかご教授いただければと思います。
よろしくお願いいたします。

Answer 1

ThreadErrorですが、どうもPuma::ThreadPool内で何かの競合が起きているようなので、threadを1にして、workerを3くらいに設定してみるのはどうでしょうか？
JRuby等ではなくCRuby(MRI)で動かしているんでしたら、GVLのおかげでthreadはそれほど強力に効くわけでもない思います。

Pumaはproductionでは使ってないので詳しくないのですが、ご参考になれば。