最近のオペレーター プロジェクトでは、Camunda のワークフロー エンジンを使用してタスクを配置および実行します. タスクは 15 分ごとに実行され、過去の期間の 800 以上のネットワーク要素のパフォーマンス インジケーターを取得し、事前定義されたルールのインジケーター判定ルールに従いますテーブルは、ネットワーク要素にアラームがあるかどうかを識別するために使用されます. 各タスクの実行時間は比較的長く、完了するまでに約 6 ～ 7 分かかります. また、このワークフロー エンジンには他にも不定期に実行されるタスクが多く、エンジン全体の負荷が比較的高くなります。その後、最近、Camunda API にアクセスできないという問題が頻繁に発生しており、エラー メッセージは HTTP 500 エラーであり、エラー メッセージは「Could not open JPA EntityManager for transaction; nested exception is org. hibernate.exception.JDBCConnectionException: JDBC 接続を取得できません"、タイプ: "CannotCreateTransactionException"
Camunda は Springboot 統合で実行しているため、このエラー メッセージから、データベース コネクション プールの不足が原因ではないかと考えました。また、インターネットで検索したところ、springboot 2.x バージョンは HikariCP を継承して JDBC 接続サービスを提供していることがわかりました.デフォルトの接続プール サイズは 10 です. Camunda がアクセスするバックエンド データベースは mysql であるため、mysql にもログインし、次のコマンドを使用して、現在の合計接続数と使用中の接続数を表示します。
select count(host) from information_schema.processlist where host like '123.123.123.123%';
select count(host) from information_schema.processlist where host like '123.123.123.123%' and command not like 'Sleep';このステートメントの 123.123.123.123 は、camunda サーバーのアドレスを表します. コマンドがスリープ状態でない場合、接続が休止状態ではなく、アクティブな接続であることを意味します.
上記のコマンドの結果からわかるように、camunda は現在、サイズが 10 の接続プールのみを作成します。スケジュールされたタスクはより複雑で長時間実行されるため、常に複数の接続を占有し、時間内に解放されず、他のタスクが実行されているときに一部の接続が消費されるため、上記のエラーが時々表示されます.
問題の原因を突き止めた後の解決策は非常に簡単で、camunda の springboot プロジェクトで、application.properties ファイルに設定 datasource.hikari.maximum-pool-size=100 を追加して解決します。
ちょっとしたエピソードですが、この解決策を運用保守担当者に伝え、構成の変更を依頼したところ、datasource.max-active の変更と勘違いしてしまい、問題は解決していません。 、 時間をかけて分析したところ、今後、構成の変更が計画通りに行われているかを確認する必要がありそうです。