1

当社では、見込み客を獲得する方法がいくつかあり、扱う見込み客の種類もいくつかあります。リードの各タイプにはわずかな違いしかなく、情報の多くは 1 つまたは複数の他のタイプのリードと共有または関連しています。私と私のチームは、Solr を使用して、これらの各リード タイプとすべての共有データ (顧客データ、リゾート データ) を処理するインデックスを構築/構成しようとしています。など (全部で約 120 万件のレコード)。現在、Tomcat 6 と Solr 3.4 を実行する Ubuntu サーバー (12G RAM、8 コア Opteron) をホストしています。

顧客が当社の Web サイトでリード生成フォームを送信したとき (毎日約 1500 ～ 2000 回) にレコードを追加し、従業員がデータを追加または変更したときに (毎日約 2500 ～ 3000 回) インデックスにレコードを追加したいと考えています。 .

さらに、フィルター、ファセット、オートコンプリート、強調表示など、適切に記述された検索から期待されるすべてのものを使用して、このデータをすばやく検索できるように、Web サイトの顧客と社内の従業員が必要です。

このセットアップは現在機能していますが、ウェブサイトと内部アプリの両方でレコードの更新がハングすることがよくあります。コミットは 1000 ドキュメントまたは 5 秒ごとに行われ、1 日 1 回最適化します。このタイプのセットアップに最適な JVM、サーバー、または Solr 構成は何ですか? どんな助けでも大歓迎です。喜んで助けてくれる人には、必要なだけ多くの情報を提供できます。

4

1 に答える 1

4

まず、を最適化しないでください。

SolrでJVMヒープ・サイズを構成する場合、2つの一般的なエラーがあります。

  • JVMに過剰なメモリを与える（OSキャッシュはディスク操作をキャッシュできません）、
  • JVMに十分なメモリを与えていません（ガベージコレクタに大きなプレッシャーがかかり、頻繁にストップザワールドコレクションを実行する必要があります。JMXモニタリングを使用して、完全なGCがトリガーされるかどうかを確認してください）。

アプリケーションがハングする可能性があるもう1つの理由は、バックグラウンドマージです。Luceneはセグメントに基づいており、セグメントの数が、より多くなるmergeFactorと、マージがトリガーされます。の値が低いとmergeFactor、ハングが発生する可能性があります。

私たちがあなたを助けることができるように、あなたはあなたの現在のセットアップについてより多くの詳細を与えるべきです：

  • JVMサイズ、
  • 使用しているコレクター（G1、スループットコレクター、同時ローポーズコレクター、...）
  • インデックスサイズ（ドキュメントの数ではなく、ディスク上）、
  • mergeFactor、、ramBufferSizeMB..。
于 2012-06-12T23:22:59.930 に答える