「未処理の拒否TimeoutError:Knex:接続の取得がタイムアウトしました。プールがいっぱいになっている可能性があります。.transacting(trx)呼び出しがありませんか?」 問題。 実行中のクエリがたくさんあるので、それを引き起こしているクエリを見つけることができません。 この問題は、postgresのサイズが大きくなると深刻になるようです。 解決策はありますか?
私もこの問題に直面しています。
私も同じ問題を抱えてる。
解決策は、ソースを分離して修正することです。 これは「クエリ」エラーではなく、アプリケーションアーキテクチャの問題です。 このエラーは、knexが(デフォルトの)60秒以内に接続を取得できない場合に発生します。その理由としては、プールがいっぱいである可能性があります。
言い換えれば、エラーを引き起こす可能性のあるものはたくさんあります。 最も一般的な2つは次のとおりです。
.transacing(trx)
を呼び出すのを忘れるが、すでに最大プールにいると、トランザクションがアイドル状態になるだけでなく、接続を取得できなかったためにエラーがスローされます。このエラーが発生した場合は、データベースの状態を確認する必要があります-アイドル状態の接続がたくさんありますか? 接続が多すぎますか? 等
私もこのエラーに直面しています。
rejecter(new _bluebird2.default.TimeoutError('Knex: Timeout acquiring a connection. The pool is probably full. ' + 'Are you missing a .transacting(trx) call?'));
^
TimeoutError: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?
アーキテクチャの接続を掘り下げる作業をしているときに、このエラーによってアプリケーションがクラッシュするのを防ぐ方法はありますか? または、少なくともエラーはスタックを指摘する可能性がありますか?
@rsfernandesビルダーでcatch
ハンドラーを使用している限り、このエラーによってアプリケーション全体がどのようにクラッシュするかはわかりません。
スタックに関しては、 longStackTraces
をお勧めします。 このエラースタック専用のknexには何も組み込まれていません。
FWIW AWS Auroraデータベースサービスでこのエラーが発生しました。これは、非アクティブの後にデータベースを終了する自動シャットダウン機能が原因で発生しました(データベースの自動起動には1分ほどかかり、knexがタイムアウトしました)
https://github.com/tgriesser/knex/issues/3159auroraの提案を回避するためのいくつかの回避策のリストがあります。
@wubzz
- プールは、トラフィックが多い場合や手順が長時間実行されている場合などに、最大容量で少なくとも(デフォルト)60秒間ノンストップで継続的にビジー状態に保たれます。
これが問題である場合、単純に少ない作業を行うことができない場合に取るべき可能な推奨事項は何ですか? 😅
タイムアウトまたは最大容量を増やしますか?
私の問題は、knexではなく、awsRDSのセキュリティグループのインバウンドルールにありました。 ローカルマシンのIPアドレスのみに設定されていたため、ec2インスタンスから接続できませんでした。 エラーメッセージが役に立たなかったのでイライラしていました。
このエラーメッセージが表示される場合は、knexが接続を確立できないことに関連している可能性があります。 だからあなたのネットワークもチェックしてください!
ええ、接続が完全にブロックされた場合に発生する可能性があると思います...異なる接続タイムアウトとacquiteタイムアウトを設定すると、これら2つのケースを区別できる可能性があります。
私はこれらのバージョンの問題を解決しました:
"knex": "^0.21.1",
"objection": "^2.1.3",
"pg": "^8.0.3"
ノード14ではなくノード12に切り替える必要がある場合があります
データベースプールの制限がありました。最小値と最大値を設定することで問題を修正できました。
Macでも同じ問題が発生しました。 コマンドラインターミナルからknexを実行していて、突然このKnex:Timeout ...の問題が発生し始めました。 問題はbashではなくzshシェルに移行していることがわかりました。 私は長い間bashを使用してきましたが、最近Appleのガイドラインに従ってzshに切り替えてみました。 bashに戻るとすぐに修正されました。
それが誰かを助けることを願っています。
ノード14ではなくノード12に切り替える必要がある場合があります
これは、Mac Dockerで機能しました-ノード(v14)の代わりにnode:12を作成します。 ありがとう。
nvm exec 12 node ./src/index...
を使用してサーバーのノードバージョンを使用するように強制しようとしましたが、上記のエラーが発生していました。
ノードを直接起動することで、エラーがなくなり、接続が確立されました。
したがって、プレーンで通常のセットアップと、おそらくノード12を使用していることを確認してください。
@batadamnjanovicあなたは丸2日間の調査の後で私を救ってくれました。 TY !!
最も参考になるコメント
私はこれらのバージョンの問題を解決しました: