x时间后的无响应套接字(puma-ruby)

Question

随机时间后，我的彪马设置中出现了一个没有响应的套接字。到目前为止，我还不知道是什么导致了这个问题。我希望这里有人能帮我们找到一些答案，或者给我指明正确的方向。我有以下设置：

我使用的是官方的docker ruby-2.2.3-slim镜像和最新的彪马2.15.3版本，我还安装了Nginx作为反向代理。但我已经确定Nginx不是这里的问题，因为我已经尝试使用这个脚本来验证套接字是否正常工作。插座不工作了，我在那里也暂停了，这样我就可以忽略Nginx了。

这是一个测试环境，所以服务器没有遇到任何极端负载，我还检查了内存消耗情况，它还有几个GB的可用空间，所以这也不是问题所在。促使我查看puma套接字的是我在Nginx错误日志中得到的错误消息：

upstream timed out (110: Connection timed out) while reading response header from upstream

此外，我在彪马的日志中找不到任何表明问题所在的东西，下面是我的彪马设置：

threads 0, 16
app_dir = ENV.fetch('APP_HOME')
environment ENV['RAILS_ENV']
daemonize
bind "unix://#{app_dir}/sockets/puma.sock"
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
pidfile "#{app_dir}/pids/puma.pid"
state_path "#{app_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
  require 'active_record'
  ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
  ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[ENV['RAILS_ENV']])
end

这是我的美洲狮状态文件中的输出：

---
pid: 43
config: !ruby/object:Puma::Configuration
  cli_options:
  conf:
  options:
    :min_threads: 0
    :max_threads: 16
    :quiet: false
    :debug: false
    :binds:
    - unix:///APP/sockets/puma.sock
    :workers: 1
    :daemon: true
    :mode: :http
    :before_fork: []
    :worker_timeout: 60
    :worker_boot_timeout: 60
    :worker_shutdown_timeout: 30
    :environment: staging
    :redirect_stdout: "/APP/log/puma.stdout.log"
    :redirect_stderr: "/APP/log/puma.stderr.log"
    :redirect_append: true
    :pidfile: "/APP/pids/puma.pid"
    :state: "/APP/pids/puma.state"
    :control_url: unix:///tmp/puma-status-1449260516541-37
    :config_file: config/puma.rb
    :control_url_temp: "/tmp/puma-status-1449260516541-37"
    :control_auth_token: cda8879717be7a645ea323d931b88d4b
    :tag: APP

该应用程序本身是最新版本4.2.5上的Rails应用程序，它部署在GCE（谷歌容器引擎）上。

如果有人能给我一些关于如何进一步调试的建议，我将不胜感激。因为现在我看不到任何可以进一步帮助我的输出。

编辑

我用到彪马的tcp连接替换了unix套接字，结果相同，在x次之后仍然挂起

Answer 1

我从开始

• 每个puma实例成功处理了多少请求
• 确保用执行请求的线程的线程id记录每个请求的开始和结束，你会看到什么

由于不了解您的应用程序，我认为线程很可能会在没有超时或在某些计算上旋转的情况下执行一些长时间/阻塞调用，直到整个线程池耗尽。

我们拭目以待。

Answer 2

我终于发现了我的应用程序为什么会这样运行。在尝试使用tcp连接并切换到Unicorn后，我开始寻找其他可能的来源。

就在那时，我想我与谷歌云SQL的连接可能是个问题。我读过Cloud SQL的常见问题后，他们提到你必须调整你的计算实例，以确保它们保持打开你的数据库连接。所以我执行了他们建议的下一步，这为我解决了问题，我添加了它们以防万一：

# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time