几天后播放框架资源不足答案

【问题标题】：Play framework resource starvation after a few days几天后播放框架资源不足
【发布时间】：2017-02-17 05:08:11
【问题描述】：

我在 Play 2.5.8 (Java) 中遇到了一个问题，即与数据库相关的服务端点在几天后开始超时，即使服务器 CPU 和内存使用情况似乎还不错。不访问数据库的端点继续正常工作。

应用程序在具有 t2.medium MySQL RDS 的 t2.medium EC2 实例上运行，两者都位于同一可用区中。大多数 HTTP 调用每秒大约 8-12 个请求对数据库进行查找/更新，并且还有 ±800 个 WebSocket 连接/参与者，每秒 ±8 个请求（90% 的 WebSocket 消息不访问数据库）。数据库操作主要是简单的查找和更新，大约需要 100 毫秒。

当仅使用默认线程池时，大约需要 2 天才能达到死锁，并且在根据 https://www.playframework.com/documentation/2.5.x/ThreadPools#highly-synchronous 将数据库请求移动到单独的线程池后，它得到了改善，但只有大约 4 天。

这是我当前在 application.conf 中的线程配置：

akka {
  actor {
    guardian-supervisor-strategy = "actors.RootSupervisionStrategy"
  }
  loggers = ["akka.event.Logging$DefaultLogger",
    "akka.event.slf4j.Slf4jLogger"]
  loglevel = WARNING

  ## This pool handles all HTTP & WebSocket requests
  default-dispatcher {
      executor = "thread-pool-executor"
      throughput = 1
      thread-pool-executor {
        fixed-pool-size = 64 
      }
  }

  db-dispatcher {
    type = Dispatcher
    executor = "thread-pool-executor"
    throughput = 1
    thread-pool-executor {
      fixed-pool-size = 210 
    }
  }
}

数据库配置：

play.db.pool="default"
play.db.prototype.hikaricp.maximumPoolSize=200
db.default.driver=com.mysql.jdbc.Driver

我已经玩弄了数据库池中的连接数量并调整了默认和 db-dispatcher 池大小的大小，但似乎没有任何区别。感觉我缺少有关 Play 线程池和配置的一些基本内容，因为我认为服务器上的负载不应该是 Play 处理的问题。

【问题讨论】：

您是否尝试过附加一个可以告诉您所有线程在做什么的调试器？您能否通过模拟更多请求来重现本地计算机上的行为（这样您就不必等待几天）

标签： java playframework threadpool

【解决方案1】：

经过更多调查，我发现该问题根本与线程池配置无关，而是由于 WS 重新连接而建立的 TCP 连接，直到服务器（或 Play 框架）无法接受更多连接。发生这种情况时，只会为已建立的 TCP 连接提供服务，其中主要包括已建立的 WebSocket 连接。

我还不能确定为什么没有正确管理/关闭连接。

我的问题与这个问题有关：

Play 2.5 WebSocket Connection Build

【讨论】：

这如何解释非数据库相关端点的正确响应？当您进行此类调用时，显然会建立新的连接。