0

400k行のテーブルで同じクエリ（いくつかの内部結合を使用したSELECT）を実行すると、Mac OSXではLinuxやWindows7よりも約30倍長くかかります。確かに、ハードウェア構成は異なりますが、違いはありません。そのような大きな違いを保証するのに十分です。Mac OSX10.6を実行しているいくつかのコンピュータでパフォーマンスの問題を再現することができました。奇妙なことに、長いクエリ実行の途中でH2を強制終了し、次回の起動時にH2にデータベースを修復させた後、期待どおりのパフォーマンスが得られました。しかし、これを一貫して再現することはできませんでした。

Mac OS Xで気付いたのは、クエリを送信してから数秒後に、CPUとディスクの両方の使用量がほぼゼロになり、クエリ結果を返す直前に戻るだけであるということでした。
テストコンピュータには、次のバージョンのJavaがインストールされています。

  • Mac OS X：Java（TM）SEランタイム環境（ビルド1.6.0_24-b07-334-10M3326）Java HotSpot（TM）64ビットサーバーVM（ビルド19.1-b02-334、混合モード）
  • Linux：Java（TM）SEランタイム環境（ビルド1.6.0_20-b02）、Java HotSpot（TM）64ビットサーバーVM（ビルド16.3-b01、混合モード））
  • Windows：Java（TM）SEランタイム環境（ビルド1.6.0_24-b07）Java HotSpot（TM）64ビットサーバーVM（ビルド19.1-b02、混合モード）

すべてのコンピューターはH21.1.117を実行していました。このバージョンはかなり古いことは知っていますが、今はそれを使い続けたいと思いますが、この明らかにプラットフォーム固有のパフォーマンスの問題を解決する必要があります。バグレポートをグーグルで検索しましたが、関連するものは見つかりませんでした。

4

1 に答える 1

1

これがオペレーティングシステムに関連している可能性はほとんどありません。

CPUとディスクの両方の使用量がゼロの場合は、完全なスレッドダンプ（、、jps -lおよびjstack -l <pid>）を取得して、プロセスが何を行っているかを確認することをお勧めします。

ANALYZEを実行しましたか？ちなみに、H2（1.3.x）の新しいバージョンでは、これは不要になりました。

これが問題ではない場合は、データベースパフォーマンスチューニングのドキュメントを参照することをお勧めします。私は知っています、それの多くは一般的です、しかしそれはまだ役立つかもしれません。それでも問題が解決しない場合は、アプリケーションプロファイリングを参照し、見つかった結果で質問を更新してください。

于 2011-03-25T10:16:54.010 に答える