関口宏司のLuceneブログ

OSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
<< StatsComponent の標準偏差について | main | テキストアノテーションツール brat がすごい件 >>
Heliosearch/Solrオフヒープフィルタ

筆者のYonikの許可を得て翻訳した。原文はこちら

Solrのパフォーマンスを一段高めるHeliosearchという新しいオープンソースプロジェクトに真っ先に追加された機能がオフヒープNativeフィルタだ。

大容量JVMヒープの潜在的問題

JVMは大きいヒープの処理が決してうまくなかった。ヒープが大きいとガーベッジコレクション作業が難しくなり、GCポーズによって長時間システムが停止し、ほかの処理が一切できなくなる場合も多い。そのためクエリ/リクエストタイムアウトが発生したり、SolrCloudモードでzookeeperセッションのタイムアウトまでも発生する可能性がある。

オフヒープフィルタ

非常に高度なフィルタキャッシング機能を用意しているHeliosearch/Solrだが、アプリケーションによっては膨大なメモリを使用する可能性がある。大きく存続期間の長いオブジェクトの方が、JVMヒープから取り出して明示的に管理するメリットを得られる。オフヒープメモリはガーベッジコレクタから見えないのだ。

Heliosearchフィルタ(Solr DocSetオブジェクト)はオフヒープでアロケートされるようになっており、不要になればすぐに解放できるよう参照がカウントされるようになった。また、JVM GCはこのようなメモリブロックのコピー処理で時間を無駄にする必要がなくなった。このことはGCの長時間ポーズを排除し、リクエストスループットを改善するのに役立っている。

テスト設定

各方面から報告のあった長時間のGCポーズを再現するにはかなりいろいろなことを試す必要があると考えていたが、何と1回目でいきなりこれが再現されてしまった。ヒープサイズは報告のように大きなものではなく現状は小さく収まっている。ヒープが大きいとGCポーズも延びるようだ。

テストの詳細

  • Ubuntu Linuxサーバ(RAM 8Gバイト、CPU 4コア、Java 1.7 64ビット)
  • クライアント:8スレッドそれぞれが1つのIDのクエリを任意のフィルタ(500種類)で処理
  • filterCache:size=1000(すべてのフィルタをエビクションせず保持するのに十分な大きさ)
  • インデックス:3.8Gバイト、5000万件

Apache Solrコマンドライン:

$ java -jar -Xmx4G start.jar
Heliosearch/Solrコマンドライン:
$ java -jar start.jar

Apache Solr実行時はOOM例外を回避するためにヒープサイズを4Gバイトに設定する必要があった。搭載可能なRAMは最大8Gだったため、残りのメモリはインデックスファイルのキャッシング用としてOSに残しておきたかった(そうしないと速度が大幅に落ちてしまう)。

GCの結果

2万クエリリクエストを行ったGCの実行結果を以下のグラフに示す。 グレーの棒はGCに要した時間、赤線はヒープの実サイズ、そして青線はヒープの実使用量を示している。

Solr

Solrでの長時間ポーズをテスト中に外から見るのはさらに容易だった。ログが有効になっていたためリクエストがすべてログメッセージを残し、ターミナルでは高速スクロールが発生した。そして、GCの大規模なコンパクションが発生するとターミナルのスクロールは突然停止した。 hs_140120-solr_gc.png

Heliosearch

ガーベッジコレクションの処理が短時間ですむためにHeliosearch GCグラフの方が完了は早い。長時間の完全なGCポーズがほとんど発生しておらず、ほかのGCポーズも大幅に減少していることに注目したい。 hs_140120-heliosearch_gc.png

クエリの待ち時間

このグラフは、2万クエリを実行したときの後半の1万クエリ(ホットスポットとキャッシュが落ち着いたタイミングを見計らうため)の待ち時間をパーセントで示している。
hs_140120-query_latency.png

Query Throughput

hs_140120-query_throughput.png
Query Throughputグラフはオフヒープデータ構造によって解放できるガーベッジコレクションに必要なCPU処理時間を示している。もちろん、これは極端な結果だ。大量のガーベッジコレクションが頻繁に発生している場合はデータ構造をオフヒープにすることで実現するスループット向上の方が適当だろう。

メモリ使用量

プロセス(トップ経由で外部から監視)の常駐メモリ最大使用量は5回にわたって計測した。

Apache SolrHeliosearch
最小3.8GB3.6GB
最大4.3GB3.7GB
オフヒープフィルタを用意するHeliosearchの方がメモリプロファイルが安定し、メモリ使用量も平均的に少なかった。そのため、OSがインデックスファイルをキャッシュするための空きメモリも増えるが、これは高いパフォーマンスを実現するためにきわめて重要なことだ。

結論

今回の簡単なテストにより、オフヒープフィルタが大きな異常値を減らして全体のクエリスループットを高め、長時間のGCポーズを排除してリクエストの予測を容易にすることが判明した。

ご自身でお試しいただきHeliosearchForumで感想をお聞かせいただきたい。



SolrMahoutのトレーニングコース、ただいま2月の受講者を募集中です!

| 関口宏司 | Solr | 12:42 | comments(0) | trackbacks(0) |









http://lucene.jugem.jp/trackback/477
+ Solrによるブログ内検索
+ PROFILE
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< April 2017 >>
+ LINKS
検索エンジン製品 - 比較のポイント
商用検索エンジンを購入した企業担当者は読まないでください。ショックを受けますから・・・
>>製品比較 10のポイント
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
Apache Solr入門 ―オープンソース全文検索エンジン
Apache Solr入門 ―オープンソース全文検索エンジン (JUGEMレビュー »)
関口 宏司,三部 靖夫,武田 光平,中野 猛,大谷 純
+ RECOMMEND
Lucene in Action
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless
FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
qrcode
+ SPONSORED LINKS