Question

我在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

我玩过数据库池中的连接数量。调整默认值＆amp;的大小db-dispatcher池大小但似乎没有任何区别。我觉得我缺少一些关于Play的线程池的基本信息。配置，因为我不认为服务器上的负载不应该是Play处理的问题。

Answer 1

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

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

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

Play 2.5 WebSocket Connection Build

几天后玩框架资源饥饿

1 个答案: