2009-04-24 17 views
5

私は、持続性のためにHibernateとHSQLDBを使用するオープンソースのJavaアプリケーションを持っています。すべての私のおもちゃのテストでは、物事は速く実行され、すべてが良いです。私は数ヶ月間このソフトウェアを継続的に稼動させてきたクライアントがおり、その間にデータベースは大幅に成長し、パフォーマンスは徐々に低下しました。最終的にデータベースが問題になる可能性がありました。私がログ・ステートメントから知る限り、サーバー内のすべての計算が迅速に行われるため、これはDBが不完全であるという仮説と一致しています。hsqldb/hibernateアプリケーションのパフォーマンスをチューニングする方法

私は、プログラムの通常のプロファイリングを行って、ホットスポットがどこにあり、何がかなりの時間を費やしているのかを理解する方法を知っています。しかし、私が知っているすべてのプロファイラーは、プログラム内の実行時間をモニターし、外部リソースへの呼び出しについてあなたに助けを与えません。パフォーマンスを最適化する場所を特定するために外部dbコールを使用しているプログラムのプロファイルに、どのツールを使用していますか?

少し盲目的に探し回っていますが、いくつかのホットスポットが見つかりました。特定のクラスのすべてのオブジェクトを列挙している箇所に気付きました。基準[.setMaxResults(1)]への1行の変更は、その呼び出しを0.5秒から事実上瞬時に変更しました。私はまた、データベースから同じ質問を1回の取引で何度も尋ねる場所も見ています。答えをキャッシュする方法はまだ分かりませんが、本当に欲しいのは、これらの種類のものをより体系的に探すのに役立つツールです。

答えて

3

残念ながら、私が知る限り、そのためのツールはありません。

しかし、あなたが点検したいと思うかもしれないいくつかのものがあります。

  • は、あなたの代わりに遅延ロードの積極的なロードを使用していますか?あなたの問題の記述によって、あなたが遅延読み込みを使用していないように見えます。
  • 2次キャッシュをオンにし正しく設定しましたか?クエリキャッシュを含める? Hibernateのキャッシング機構は非常に強力で柔軟性があります。
  • Hibernate Searchの使用を検討しましたか?クエリに応じて、Apache Luceneの上にあるHibernate Searchのフルテキストインデックスはクエリを高速化できます(インデックスシステムは非常に強力です)。
+0

私はDB構成でパフォーマンスチューニングを行っていません。私は、私の問題は、質問が不完全であるか、間違った質問を何回も繰り返す可能性が高いと想定していました。私はクエリとその費用の数を減らす方法を見つけ出したいと思っています。そして、その使用量を80%削減した後、キャッシングなどの負荷を減らしてdb自体をスピードアップします。しかし、私はDBの使用状況を調整する専門家ではありません。アプリケーションの前にDBを調整することを提案しますか? – PanCrit

+0

問題が休止状態になっていることが確かであれば、DBを調整することは役に立ちません。 チューニングする前に、パフォーマンス上の問題の根を正確に追跡して最適化するためのプロファイラツールなどを使用してください。 残念ながら、簡単な方法はありません。良いニュースは:今日のIDEはすべて、まともなプロファイリングをサポートしています。 – razenha

0

どのくらいのデータをHSQLDBに保存していますか?ファイルのすべてを保存しているだけなので、大量のデータを管理するとうまくいくとは思えません。

+0

私はそれがhsqldbが何をすることができるかと比較して巨大だとは思わない。 .scriptファイルは、ほぼ300K行の長さ(32891015文字)です。私は以前に見て、3000の市場と150Kの取引がDBに格納されています。すべてのオブジェクトに合計250K行あります。 – PanCrit

0

探していたものをIronGrid/IronEye/IronTrackSqlというツールが使用していました。残念ながら、彼らは失業しました。彼らは最終段階で製品をオープンソース化しましたが、私はかなりの時間ソースまたはバイナリを見つけることができませんでした。

私は最近、プロファイリングのためにYourKitを使用しています。これは、最もよく呼ばれるステートメントと最長実行ステートメントを見つけるためのSQL時間をプロファイルできるからです。 IronGridほど詳細ではありませんが、貴重な情報を提供します。最新のデータベース/休止状態のチューニング・セッションでは、問題は休止状態であることが判明しました。また、いつ、どうやってレイジー・ローディングを実行していたのか、多数の項目を選択するときに、デフォルトの賢明なオーバーライドを追加しました。

0

ここに報告するロット私はいくつかの結果を得て、まだ良い答えを探しています。

私は助けるツールのカップルを見つけた:(BTrace、またはトレースを内蔵した)

VisualVMは、トレースを支援するために主張したが、私はタイミングを示す任意のツールを見つけることができませんでしたonメソッド呼び出し。

YourKitは有用であると評価されています。私はオープンソースライセンスを求めました。

私が見つけた最も有用なものは、Hibernateの統計情報です。プロパティに hibernate.generate_statistics trueを設定した場合は、sessionFactory.getStatistics()を送信して、どのオブジェクトが格納され、取得されたか、キャッシュにどのような影響があるかの詳細な統計情報を確認できます。 qeuryStatisticsには、コンパイルされた各クエリ、キャッシュヒットとミス、クエリが実行された回数、返された行の数、平均、最大と最小の実行時間が表示されます。これらのタイミングは、時間がどこにあるかを豊富に明らかにしました。

私はキャッシングに関する読書をしました。 Razenhaの提案は正しかった。 [彼の答えは今のところ正しいとマークします]私は自分のプロパティにhibernate.cache.use_query_cache trueを追加し、ほとんどのクエリにquery.setCacheable(true);を追加しました。私はまた、いくつかの.hbm.xmlファイルに<cache usage="read-write"/>を追加しました。今では私の統計のほとんどがキャッシュヒットの大部分を占めており、パフォーマンスは大幅に向上しています。

私は実行タイミングをトレースするのに役立ついくつかのツールが好きですから、最も明らかな問題ではなく最悪の問題を攻撃することができますが、これは大きな助けになります。おそらく上記のトレースツールの1つが助けになるでしょう。

+0

yourkitは便利で使いやすいです。 – PanCrit

0

Terracotta 3.1では、Terracotta Developer Consoleを使用してリアルタイムですべての統計を監視できます。キャッシュ統計の履歴グラフを見ることができ、クラスタ全体またはノードごとのハイバネート統計またはキャッシュ統計を見ることができます。

テラコッタはオープンソースです。詳細およびダウンロードはTerracotta for Hibernateです。

関連する問題