1

Solr 4 インスタンスが遅く、その理由がわかりません。パフォーマンスを最適化するために、JVM、Tomcat6、および Solr 4 の構成を変更して、1 秒あたりのクエリ数を主要なメトリックとして使用しようとしています。現在、Debian スクイーズを使用して EC2small層で実行していますが、必要に応じて Ubuntu に切り替える準備ができています。

私のユースケースについて特別なことは何もありません。インデックスは小さいです。クエリには適度な数 (たとえば 10) のユニオンとファセットが含まれますが、それは珍しいことではないと思います。

私の理解では、これらの領域は微調整が必​​要になる可能性があります。

  • JVM ガベージ コレクションのスケジュールとメモリ割り当ての構成 ( 「GC チューニングは正確な芸術形式です」、参照)
  • その他の JVM 設定
  • Solr のクエリ結果キャッシュ、フィルター キャッシュ、ドキュメント キャッシュの設定
  • Solr の自動ウォーミング設定

Solr のパフォーマンスを監視するには、いくつかの方法があります。

しかし、これらの方法のいずれも、どの設定を調整する必要があるかを示すものではなく、パフォーマンスを向上させる可能性のある設定の完全なリストを順を追って説明するガイドはありません. 次のページ ( one、two、three、four ) をレビューし、これまでに試行錯誤を繰り返しましたが、改善されていません。

質問:

  • 小さな EC2 インスタンスで 2 GB のメモリをすべて使用するように JVM に指示するにはどうすればよいですか?
  • JVM ガベージ コレクションをデバッグおよび最適化する方法は?
  • 新しい EBS IOPS 料金などの I/O スロットリングがいつ問題になるかを知るにはどうすればよいですか?
  • 以下の NewRelic の例のような図を使用して、問題のある動作を検出する方法と、解決策にアプローチする方法を説明します。

答え:

  • DevOps またはサーバー管理者の観点から (インデックスやアプリケーションの設計ではなく)、Solr 4 のセットアップと最適化に関する適切なドキュメントへのリンクを探しています。
  • 問題の原因である可能性が最も高い catalina.sh、solrconfig.xml、solr.xml (その他?) の上位の問題点を探しています。
  • または、質問に対処すると思われるヒント。

ここに画像の説明を入力 ここに画像の説明を入力

4

1 に答える 1

5

まず、Linux ディストリビューションの切り替えに集中すべきではありません。別のディストリビューションではいくつかの変更が生じる可能性がありますが、提供された情報を考慮すると、これらの変更が重要である可能性があることを証明するものは何もありません.

あなたは最適化のための多くの可能性について言及していますが、これは圧倒される可能性があります. 問題がスタックの特定の部分にあることが証明された場合にのみ、微調整領域を検討する必要があります。

JVM ヒープのサイジング

パラメータ-mx1700mを使用して、最大 1.7GB の RAM を JVM に割り当てることができます。ホットスポットはそれを必要としないかもしれないので、ヒープ容量がその数に達しなくても驚かないでください。

Hotspot がメモリ使用量を最適化できるように、最小ヒープ サイズを低い値に設定する必要があります。たとえば、最小ヒープ サイズを 128MB に設定するには、-mx128m.

ガベージコレクター

あなたの言うことから、ハードウェアは限られています (最大 1.2GHz で 1 コア、このページを参照してください) 。

M1 スモール インスタンス

  • 1.7 GiB メモリ
  • 1 EC2 コンピューティング ユニット (1 つの EC2 コンピューティング ユニットを備えた 1 つの仮想コア)
  • ...

1 つの EC2 コンピューティング ユニットは、1.0 ～ 1.2 GHz の 2007 Opteron または 2007 Xeon プロセッサと同等の CPU 容量を提供します。

したがって、その低レイテンシ GC (CMS) を使用しても、何の役にも立ちません。コアが 1 つしかないため、アプリケーションと同時に実行することはできません。を使用してスループット GC に切り替える必要があり-XX:+UseParallelGC -XX:+UseParallelOldGCます。

GC は本当に問題ですか?

その質問に答えるには、GC ログを有効にする必要があります。これは、GC の一時停止がアプリケーションの応答時間の原因であるかどうかを確認する唯一の方法です。でこれらをオンにする必要があり-Xloggc:gc.log -XX:+PrintGCDetailsます。

しかし、問題はここにあるとは思いません。

ハードウェアの問題ですか？

この質問に答えるには、リソースの使用率 (ディスク I/O、ネットワーク I/O、メモリ使用率、CPU 使用率) を監視する必要があります。、、、、、 ...などtop、それを行うためのツールがたくさんあります。freevmstatiostatmpstatifstat

これらのリソースの一部が飽和していることが判明した場合は、より大きな EC2 インスタンスが必要です。

ソフトウェアの問題ですか？

統計では、ドキュメント キャッシュのヒット率とフィルター キャッシュのヒット率は正常です。ただ、クエリ結果キャッシュのヒット率はかなり低いと思います。これは、多くのクエリ操作を意味します。

クエリの実行時間を監視する必要があります。その値に応じて、キャッシュ サイズを増やすか、クエリを調整して時間がかからないようにすることができます。

その他のリンク

それが役立つことを願っています!

于 2013-05-14T15:10:19.727 に答える