Воспроизведение фреймворка ресурсным голодом через несколько дней

Question

У меня возникла проблема в Play 2.5.8 (Java), когда конечные точки службы, связанной с базой данных, начинают работать по истечении нескольких дней, даже если загрузка ЦП и памяти сервера выглядит нормально. Конечные точки, которые не обращаются к БД, продолжают работать отлично.

Приложение запускается на экземпляре t2.medium EC2 с MySQL RDS t2.medium, оба в одной зоне доступности. Большинство HTTP-вызовов выполняют поиск / обновление базы данных со скоростью около 8-12 запросов в секунду, а также существует около 800 соединений / акторов WebSocket с ±8 запросами в секунду (90% сообщений WebSocket не обращаются к базе данных). Операции с БД - это в основном простые поиски и обновления, занимающие около 100 мс.

При использовании только пула потоков по умолчанию для достижения тупика потребовалось около 2 дней, и после перемещения запросов к базе данных в отдельный пул потоков согласно https://www.playframework.com/documentation/2.5.x/ThreadPools, это улучшилось, но только до 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-диспетчера, но, похоже, это не имеет никакого значения. Мне кажется, что мне не хватает чего-то фундаментального в пулах потоков и конфигурации Play, так как я не думаю, что нагрузка на сервер не должна быть проблемой для Play.

Answer 1

После дополнительных исследований я обнаружил, что проблема вовсе не связана с конфигурацией пула потоков, а скорее с соединениями TCP, которые создаются из-за переподключений WS до тех пор, пока сервер (или платформа Play) не сможет больше принимать соединения. Когда это происходит, обслуживаются только установленные соединения TCP, которые в основном включают в себя установленные соединения WebSocket.

Я еще не мог определить, почему соединения не управляются / закрываются должным образом.

Моя проблема связана с этим вопросом:

Play 2.5 WebSocket Connection Build