x时间后无响应的套接字（puma-ruby）

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

我正在使用正式的docker ruby-2.2.3-slim映像和最新的puma版本2.15.3，我还安装了Nginx作为反向代理。但我已经确定Nginx不是这里的问题，因为我已经尝试验证套接字是否使用它工作。插座不工作，我在那里也超时了，所以我可以忽略Nginx

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

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

此外，我在puma的日志中也找不到任何指示出问题的内容，这里是我的puma设置：

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

这是我的puma状态文件中的输出：

---
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（谷歌容器引擎）上

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

编辑 我将unix套接字替换为与Puma的tcp连接，结果是相同的，在x时间后仍然挂起

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

由于不太了解您的应用程序，我想说的是，在整个线程池耗尽之前，线程很可能会在没有超时的情况下执行一些长/阻塞调用，或者在一些计算上旋转

---

我们拭目以待。

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

那时我想可能是我与谷歌云SQL的连接出了问题。一旦我阅读了的faq，他们提到您必须调整您的计算实例，以确保它们保持打开您的DB连接。因此，我执行了他们建议的下一步步骤，为我解决了问题，我添加了这些步骤以防万一：

# 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

---

这是在谷歌计算引擎（在虚拟机上）还是谷歌容器引擎（在Kubernetes集群中）？如果是后者，具体部署方式如何？它在后者上运行，使用Kubernetes v1.1.2。我有一个Official base ruby映像，里面安装了nginx，里面安装了startup puma，所以所有内容都包含在一个映像中。