Lambda関数のテスト中にいくつかの問題が発生しています。私のテストでは、Lambda関数のN
実行を並行して実行します。私のラムダ関数では、Knexを介してデータベース接続を取得します。私は、コード内の他のものに応じて、物事を修正/破壊しているように見えるdb init _pool: { min: 0, max: [1 or 5] }
_の設定をいじり回していました。
ラムダ関数を20回実行すると正しい結果が出力されますが、最大500にすると(本番環境で見られるものはこれを簡単に超えてしまいます)、問題が発生し始めます。 _Error: ER_CON_COUNT_ERROR: Too many connections
_、_Error: pool is draining and cannot accept work
_などのエラーが発生しています(ラムダ関数の最後にKnexのknex.destroy()
インターフェイスを使用している場合)。 AWS LambdaとRDSで接続とスケーリングのスケーリングを処理する正しい方法は何ですか? AWSで同じストレステストを実行すると、ローカルマシンで発生している問題が再現されますか?
タスクのごく一部を実行するために数千のプロセスをスピンオフするのは簡単です。しかし非効率的です。 「プロセス」は重いです。スレッドはやや重いです。 MySQLへの数千の接続が可能ですが、すべてを同時に行うことはできません。
マルチプロセスまたはマルチスレッド環境では、「数が多すぎる」と速度が低下します。これは、OS(または一部のエンティティ)が不十分なリソースを共有するために多くの作業を行っているためです。たとえば、MySQLは数百のidle接続を処理できますが、数十を超えるactive接続では処理速度が低下します。それを超える場合は、クライアントまでのチェーンを上り、新しい接続を生成する頻度を調整するのが最善です。
私はあなたが言及している他の製品に精通していませんが、同時アクティビティを数百ではなく数十に抑えることをお勧めします。
または方法を見つけます。アプリケーションでは、「再帰」ではなく「反復」します。一方、MySQLは個々の行を処理するよりも、データの「ベクター」(テーブル)を処理する方が便利であることを覚えておいてください。たぶん、あなたはアプリの「並列」のいくつかを「ベクトル」としてMySQLにプッシュできますか? Win-Win:接続が少ない。 MySQLの効率が向上します。
エラーはデータベースへの接続の数が原因であり、各Lambda関数は少なくとも1つを開き、あなたの場合、その数はRDSインスタンスで使用可能な接続の数を超えています。
AWSコンソールを介してそれを上げることができます。max_connectionsを探すだけです。これはステップバイステップのチュートリアルです。
https://github.com/jollygoodcode/jollygoodcode.github.io/issues/16
このリンク(他の多くは同様の値を示しています)によると、次の表に、各インスタンスサイズでサポートされる接続数が示されています。
MODEL max_connections
t1.micro 34
m1-small 125
m1-large 623
m1-xlarge 1263
m2-xlarge 1441
m2-2xlarge 2900
m2-4xlarge 5816
それが役に立てば幸い
Lambdaで接続プーリングを許可するには、説明されているように、ハンドラー関数の外部でプールを作成する必要があります here 。
記事の執筆者は 彼のGithubでの例 を指していますが、それは存続しますが元の記事は消えます。