ホームページ  >  記事  >  Spring Data JPAストリームを監視する方法

Spring Data JPAストリームを監視する方法

WBOY
WBOY転載
2024-02-22 14:01:071191ブラウズ

php エディター Youzi は、Spring Data JPA フローの監視に関する Java の質問と回答を提供します。開発中、データ フローをリアルタイムで監視することは、システム パフォーマンスの最適化とトラブルシューティングにとって重要です。この記事では、Spring Data JPA フローを監視する方法を紹介します。これにより、データ処理プロセスをより深く理解し、問題を適時に検出し、それに応じて対処できるようになります。 Spring Data JPA フローを効果的に監視し、システムの安定性とパフォーマンスを向上させる方法について説明します。

質問内容

このブログに書かれている通りにSpring Data jpaストリーミングを利用しようとしています。ただし、プロセスや進行状況をログで監視することはできません。プロセスがデータをバッチで抽出しようとすると、ログに複数の SQL クエリが出力されるはずですか?そうでない場合、すべての行が一度にロードされていないことをどのように確認すればよいでしょうか?

このブログやこのブログのような他のブログでは、mysql の hint_fetch_sizeinteger.min_value に設定する必要があると提案されており、これが解決策になるかもしれないと思いましたが、これにより次の例外がスローされます:

2024-01-29 14:40:20.843 警告 78247 --- [nio-8080-exec-1] o.h.engine.jdbc.spi.sqlExceptionhelper: sql エラー: 0、sqlstate: s1000 2024-01-29 14:40:20.843 エラー 78247 --- [nio-8080-exec-1] o.h.engine.jdbc.spi.sqlExceptionhelper: ストリーミング結果セット com.mysql.cj.protocol.a.result.resultsetrowsstreaming@ 4ca63fa5はまだ活動中です。ストリーミング結果セットが開いていて、特定の接続で使用されている間は、ステートメントは発行されません。さらにクエリを試行する前に、アクティブなストリーミング結果セットに対して .close() を呼び出したことを確認してください。 終了時間: 48 org.springframework.orm.jpa.jpasystemException: 結果セットを抽出できません。ネストされた例外は org.hibernate.Exception.genericjdbcException: 結果セットを抽出できません org.springframework.orm.jpa.vendor.hibernatejpadialect.converthibernateaccessException(hibernatejpadialect.java:331) で

これは私のリポジトリ コードです:

リーリー

ストリーミングのパフォーマンスを自分で確実に監視できないため、上記が Spring Data jpa でストリーム クエリを使用する正しい方法であるかどうかを保証したいと思いますか?

更新

上記の例外は、同じ呼び出しメソッド内で findallstream メソッドを繰り返し呼び出したために発生します。そのうちの 1 つを削除すると、例外が修正されました。

回避策

データがバッチで取得されているかどうかを示すログ構成が見つかりません。しかし、ローカルでパフォーマンスをテストする方法を見つけました。

ストリーミング機能をテストするには、数百万のレコードを含むデータベースにアクセスする必要があります。 docker イメージ https://www.php.cn/link/7092d5eb1bbca1a22bdc69ba3f517e68 を使用して mysql 従業員データを使用します

Docker イメージをセットアップした後、mysql ワークベンチをサーバーに接続する際に問題が発生しました。 Docker イメージは、デフォルトでは ssl 接続を受け入れるように構成されていないようです。接続を確立するには、use ssl フラグを無効にする必要がありました。この設定は、mysql ワークベンチの [ssl] タブに表示されます。

アプリケーションの接続文字列も次のように構成する必要があります:

リーリー

従業員データベース内のデータは、salaries という名前のテーブルで構成されており、このテーブルには約 280 万行があります。

テストのために、リポジトリ クラスに次のメソッドと、これらのメソッドを呼び出すための単純なコントローラーを持つ小さな Spring Data jpa アプリケーションを作成しました。 リーリー

次に、読み取ったデータを json オブジェクトに変換し、複数のスレッドを使用してファイルに書き戻すための小さなコードを書きました。これは、実際のケースでの処理をシミュレートするためです。

これが私が観察したことです。

  • リスト方式を使用すると、メモリ使用量が大幅に増加します。最初のクエリにほとんどの時間がかかりましたが、すべてのデータが読み込まれると、実際のデータ処理はすぐに完了しました。

  • ストリーム方式を使用する場合、メモリ使用量への影響はほとんど目立ちません。ただし、全体として、完了処理部分のパフォーマンスはリスト方式と同等か、それよりも劣ります。

  • ######結論は######
上記の調査結果から、リポジトリ メソッドの

stream 戻り値の型は、メモリ不足のリスクがある場合、つまり out メモリ例外が発生する場合にのみ使用する必要があるという結論に至りました

。それ以外の場合、アプリケーションがすでに十分な規模のサーバーで実行されている場合、メモリ使用量に対する全体的な影響はほとんど目立たず、プロセスがすぐに完了した場合に一時的なものにすぎません。

Intellij プロファイラーからのメモリ使用量統計 left ->リストメソッド実行時

右 -> ストリームメソッド実行時

    以上がSpring Data JPAストリームを監視する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

    声明:
    この記事はstackoverflow.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。