数日後にフレームワークリソースの枯渇を再生する

Question

サーバのCPU &メモリ使用量は問題ないようですが、数日後にデータベース関連のサービスエンドポイントがタイムアウトするPlay 2.5.8（Java）の問題が発生しています。 DBにアクセスしないエンドポイントは、引き続き完全に機能します。

アプリケーションは、t2.medium MySQL RDSを持つt2.medium EC2インスタンス上で実行され、どちらも同じ可用性ゾーンにあります。ほとんどのHTTPコールは、毎秒約8-12リクエストでデータベースへのルックアップ/更新を行います。また、±8リクエスト/秒のWebSocket接続/アクタが±800あります（WebSocketメッセージの90％がデータベースにアクセスしません）。 DB操作はほとんどが単純なルックアップ&の約100msの更新です。

デッドロックに達するまでに約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 
    } 
    } 
} 

データベース構成：私はの大きさを調整するDBプール&に接続の量と周り果たしている

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

デフォルトの& db-dispatcherプールサイズですが、違いはありません。 Playのスレッドプールについて何か根本的な欠如があると感じています。サーバー上の負荷がPlayの処理に問題ではないはずはないと思うので、&の設定です。

Answer 1

さらに調査した結果、この問題はスレッドプールの設定に関連するのではなく、サーバ（またはPlayフレームワーク）がこれ以上の接続を受け入れることができなくなるまでWS再接続によって発生するTCP接続であることがわかりました。これが起こると、確立されたTCP接続のみが処理され、確立されたWebSocket接続がほとんど含まれます。

まだ接続が管理されていない/閉じられていない理由をまだ特定できませんでした。

私の問題は、この問題に関する：

Play 2.5 WebSocket Connection Build