LucidWorks Search & Apache Solr

SMART/InSight® Partner Training
LucidWorks Search
－サイジングの考え方とパフォーマンス測定
2013 / May / 24
Uchida Spectrum, Inc.
Product Management Office (PMO)
©2013 Uchida Spectrum, Inc. All rights reserved.
Trademarks
Apache and the Apache feather logo are trademarks of The Apache Software Foundation.
The Apache Software Foundation, Licensed under the Apache License, Version 2.0 .
Apache Solr, Apache Lucene, ApacheCon and their respective logos are trademarks of The Apache Software Foundation.
No endorsement by The Apache Software Foundation is implied by the use of these marks.
All software produced by The Apache Software Foundation or any of its projects or subjects is licensed according to the terms of
the document Apache License, Version 2.0 .
Linux is a trademark of Linus Torvalds in the U.S. and other countries.
UNIX a registered trademark of The Open Group in the United States and other countries.
Red Hat is a registered trademark of Red Hat, Inc.
LucidWorks is a trademark of LucidWorks in the United States. Lucid Imagination is a trademark of Lucid Imagination in the United States.
Kuromoji and Keywords are product names from Atilika Inc.
Carrot2 : Copyright(C) 2002-2013, Dawid Weiss, Stanisław Osiński. All rights reserved.
Lingo3G is a trademark of Carrot Search s.c.
Intel and Itanium are registered trademarks and Intel386 is a trademarks of Intel Corporation.
Microsoft, Windows, SharePoint, FAST, SQL Server, and Office are either registered trademarks or trademarks of the Microsoft group of companies in
the United States and/or other countries.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
SMART / InSight Ⓡ はウチダスペクトラム株式会社および株式会社内田洋行の登録商標です。
All other trademarks and/or registered trademarks are property of their respective owners.
All other company, product, and service names are the property of their respective holders and may be registered trademarks or trademarks in the United States
and/or other countries.
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or any means, electronic or mechanical, including photocopying and recording,
for any purpose other than the purchaser’s use, without the written permission.
Unless otherwise specified, all information and screens appearing on this document, including design, text, graphics, logos, images and icons, as well as the selection
and arrangement thereof, are the sole property of Uchida Spectrum, Inc.
本書および本データの全体または部分に対する無断の引用・転載・複写・複製・翻訳，ならびに他目的用途への転用を禁じます。
本書はウチダスペクトラム株式会社の著作物であり，日本の著作権法や国際条約などに基づき保護されています。
Copyright © 2013 Uchida Spectrum, Inc.
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-2
1. 当セッションの狙い
本書の目的
このセッションでは，LucidWorks Search （以下，「LWS」と略記）の
キャパシティ推算における事前ベンチマーキングの重要性を理解することと，
パフォーマンス系統計情報を取得する為のツール群にどのようなものがあるか
を理解することを狙いとします。
本書の対象者
本書は，以下を対象の読者と仮定して記述されています：
 情報インフラストラクチャー担当者
 LWS 管理者
本書の目標
本書の内容を理解および実践することにより，読者は以下を達成できるようになることが
目標です：
 キャパシティ推算には事前ベンチマーキングが必須であることを説明できる。
 メモリ割当量の算出に必要となる基礎統計情報を取得することが出来る。
 パフォーマンス悪化防止の為に気を付けるべき点について説明できる。
前提条件
本書の読者には，以下を前提条件を満たしていることを仮定します：
 Windows または Linux の標準的なオペレーションや管理経験を有すること。
 Command Prompt または Shell の使用経験を有すること。
バージョン
本書記載内容は，以下のソフトウェアおよびバージョンに対応します：
 LucidWorks Search 2.5.1
本書の注意点
本書は，2013 年 04 月 01 日現在までに収集された情報に基づいて記述されています。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-3
2. キャパシティ推算は難しい

リレーショナル型データベース等と違って，データ各件でデータ量が大幅に異なるコンテンツを
扱う特性上，キャパシティ推算値が実測値と乖離することは珍しくありません。
あくまでもキャパシティ推算値は単なる目安の一つに過ぎず，その値が独り歩きしないように注意して
解釈する必要があります。

LWS の主たるデータは転置インデックスに基づくことから，データ量のみならずデータ値そのもの
にも大きく影響されます。
例えば，２件のデータのデータ長は同一であっても，そのデータ値を構成する語数と種類数が多ければ
消費データ容量は全く異なります。

本音で語ってしまえば，「計算上でのキャパシティ推算には然程の根拠はない」ということです。
最良なのは，実環境のデータの全体（または一部）を用いて実際にベンチマーキングのテスト実証を
行なうことです。言い換えれば，事前にベンチマーキング実施なくしてキャパシティのプラニングは
意味無し，ということでもあります。
推算評価に用いるデータは，本番データでありデータ量が多いほど好ましいと言えます。
是非，事前のベンチマーク評価を御実施ください。
“ 単語数とページ数
全部でどれだけあるか
答えられますか？ ”
©2012 Uchida Spectrum, Inc. All rights reserved.
“ これから作成しようと思いついたプログラム
ソースコードが何行に及ぶか
答えられますか？ ”
Page-4
2-1. リレーショナル型データベースの場合は余り難しくない...
RDBMS（Relational Database）において，ユーザが入出力対象とする実データは “Table” に保持されます。
テーブルは２次元平面構造を呈しており，０個以上の “Row” と１つ以上の “Column” で構成されます。
Row（行）は，Data Occurrence 各件個々を表します。つまり，データが n件あるならば，テーブルは n行を保持します。
Column（列）は，各データの属性値，すなわちある特定の側面から限定的に観察した際のデータ値を表します。
オカレンスが「社員」であれば，カラムは「社員番号」「氏名」「年齢」「生年月日」「所属部署名」などです。
一般的に RDBMS では，各カラムに対して “Data Type” を割り当てます。
Data Type（データ型）は様々なものが多種多様に用意されており，
一致しない（または互換がない）データ値が混入しないように，
非常に厳密な防止策が用意されています。
例えば，日付時刻を扱うべき「生年月日」カラムに datetimeデータ型を
定義しておくことにより，日付時刻以外の文字列や整数値実数値など
代入されようとしても，これを阻止して不適切情報が格納されることを
防ぎます。
提供されるデータ型は RDBMS や Version によって異なりますが，
代表的なデータ型には，例えば以下のものがあります：
文字列型
文字列を保持する
格納可能な最大文字長も定義される
整数型
整数値を保持する
値域（下限値と上限値）も定義される
浮動小数点数型
実数を保持する
精度（小数点以下桁数）も定義される
日付時刻型
日付や時刻を保持する
値域や精度も定義される
ブーレアン型
ブール値を保持する
True / False / Null の３種のみに限定
このように，各行各列のセル相当に代入される値はデータ型の縛りを受けている為，容量がほぼ一定であるか
可変であったとしても精度や上限値が有限固定値である為に，大きな変動要素には成りません。
従って，テーブル構造とデータ件数さえ判明すれば，凡そ容量を推定することが可能です。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-5
2-2. ファイルサーバの場合はやや難しくなってくる...
File Server の場合は，RDBMS と比較すると，消費容量のサイズ見積もりは難しくなります。
保存するファイルの個数はなんとか推定できるかもしれませんが，ファイル個々のサイズ（ Min / Max / Average ）を
事前に求めることは非常に困難です。
また，同じ文字列をファイルに保持するにしても，Plain Text File として保持するか Microsoft Office File として保持するかで
消費容量は異なります。これは後者がファイル保存時に，文字列情報を圧縮するからです。
同様に，画像ファイルにしても TIFF / BMP Format で保存すれば多量のストレージ空間を消費しますが，JPEG / PNG Format
であれば相対的に消費容量は小さくなります。
File Server を導入された時に，ストレージ領域が満杯になる迄に何年間もつか想像ついたでしょうか？
現状で何個のファイルが格納されていて，ファイルの平均サイズがどの程度か把握できていますか？
来年の時点でこの File Server の空き空間率がどの程度となるか，数年前に推算できていましたか？
File Server 導入時に，ディスクを何台搭載すればいいか，厳密な解をはじき出したうえで装備されましたか？
おそらく，殆どの方は答えをお持ちでなかった筈です。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-6
2-3. 事前予測は難しいものです...
例えば Zip Format の圧縮ファイル。
あるファイルやディレクトリ配下を圧縮する時，事前に「圧縮したらどの程度の大きさになるか」を
高い精度でサイズ予測するは可能でしょうか？
「そんなのデータ量や内容に依るでしょ」と答える方が殆どだと思います。
つまり，そういうことなのです。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-7
2-4. 検索エンジンの場合は更に難解です...
検索エンジンの場合は，RDBMS や File Server と比較して，容量推算は更に難しくなります。
その理由は複数ありますが，ここでは代表的なものを２つ説明します：
 データ型やデータ長の制限が緩い
 転置インデックスの生成ロジック
検索エンジンはそもそも，長大な文字列が与えられた時に，特定の語句を持つドキュメントを
迅速に探し出す為に作られたソフトウェアです。従って；
 データ長を厳格に束縛する「精度」や「最大長」について，制限が緩いまたは制限が無い。
 文字列をハンドリングすることが元来の狙いである為，用意されるデータ型の種類は多くない。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-8
2-5. 転置インデックス（Part-1）
検索エンジンの役割は，与えられた文字列をオリジナル元データとして，これを材料として一定文字列に分断化し，
その切り出された一定文字列の個々が，「どのドキュメントで」「何回」「どの箇所に」出現したかの索引を作り出すことです。
これを「転置インデックス」（Inverted Index）と称します。
オリジナル元データの文字列から，一定文字列の断片に切り出す方法は数種類ありますが，代表的な手法は以下の２つです：
Morphological Tokens
形態素解析を施して，言語的に意味を成す最小の部分文字列
（一般的には品詞レベルに細分化）へ分割する
n-gram Subsequence
n文字から成る部分文字列パターンを全て求める
上記の「一定文字列」（Token または Subsequence）から，それが「どのドキュメントで」「どの箇所に」存在するか
の索引を生成します。これが検索エンジンにおける「インデックス」の正体です。
形態素分解方式
©2012 Uchida Spectrum, Inc. All rights reserved.
n-gram 方式
Page-9
2-6. 転置インデックス（Part-2）
n-gram 方式
n文字毎に切り出した
Subsequence を Term とする
形態素分解方式
言語学的に意味のある最小の
品詞レベルである Token を
Term とする
転置インデックスの生成
©2012 Uchida Spectrum, Inc. All rights reserved.
検索エンジンで用いられる転置インデックスは，
RDBMS で数多く採用されている B-Tree Index や Hash Index 等とは
かなり構造や特性が異なるものです。
転置インデックスを採用することで，高速な検索が可能となっています。
身の回りにある例ですと，百科事典などの巻末にある「見出し語による索引」が
転置インデックスの考え方に似たものとして挙げられるでしょう。
Page-10
2-7. 転置インデックス（Part-3）
ある小説本で，「私」という語はどのページのどの箇所に合計何回出現するでしょうか？
また，「私」以外に何種類の単語が当小説には使用されていますか？
それら個々の単語の出現位置はどこでしょう？
おそらく小説家本人でさえ，そんなことは判らないでしょうし，それを意識して執筆していないでしょう。
コンテンツ内に
出現するトークンは
何種類？
コンテンツの
件数は？
理論上は計算できなくもないのでしょうが，
おそらくこのような作業を行なうだけの手間と時間を掛ける
間に，とっくにコンテンツはフィードできてしまっている
ことでしょう...。
コンテンツ内に
存在するトークンは
どの箇所にある？
各トークンの
登場回数と分布は？
このトークンが
登場する箇所を
全部洗い出すと？
各トークンを
圧縮すると何バイト？
Lucene におけるデータ
格納アルゴリズムは？
©2012 Uchida Spectrum, Inc. All rights reserved.
もうフィードが完了して
サイズも時間も測定
できちゃってるんですが？
このトークンは
全コンテンツからみて
平均出現回数と分散は？
各トークンの
長さは？
Page-11
2-8. 結局のところ...
キャパシティやパフォーマンスに影響を及ぼす因子が余りにも多岐に渡る為，
事前計算で推定することは実質的に不可能です。
実際にデータを流し込んでみて，どのような結果となるかを観察し
その考察結果から類推するしかないでしょう。
Lucene/Solr のコミッターでさえ，「どの程度のサーバ台数やディスク容量が必要になるでしょう？」
と質問されても「さぁ....」としか答えられないものです。
事前推算したいのであるならば
ベンチマーク測定は
絶対に欠かせません！
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-12
3. ベンチマーク測定結果を読み取るうえでの注意

単発の測定に終わらせない

単一条件の測定に終わらせない

測定シナリオに一貫性を持たせる

測定結果から類推するうえで無根拠な仮定を勝手に設けない
一回限りの測定では，偶然性や「たまたま」の可能性を排除し切れません。
同一条件下で複数回の測定を実施し，反復結果から平均およびムラやブレを読み取ることが必要です。
条件固定のまま複数回の測定を行なっても，どの因子がどのような影響を齎すかが見出せません。
特定ファクターを微かに変更してみて，相対的な比較を行なうことが必要です。
これにより，そのファクターの影響度合や波及内容を推定することが出来ます。
あれやこれやと無計画なパターン測定を何度も行なっても，有意ではありません。
複数回の測定は大切ですが，目標と仮定を確定したうえで測定を行なうことが重要です。
条件を変えた複数回の結果を材料として，「おそらくこうなるだろう」と類推する際に使うロジックは
それが妥当であると説明できる根拠が無ければなりません。
例えば「100万件をフィードするのに1時間を要した」から「1000万件のフィードは10時間だろう」
と考えがちですが，ここでは「プロポーショナルに比例である」という暗黙の仮定が潜在しています。
しかし，プロポーショナルに比例する，という根拠は何なのでしょうか？
本当に比例関係にあるのでしょうか？その裏付けは？
自分で勝手に「そうである」と自己催眠かけていませんか？
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-13
3-1. 測定を複数回実施したこと自体に満足しないこと
『条件k の時に統計量v が得られたのだから，条件が 10×k の時はきっと 10×v だろう ... 』
それは “適切” な考え方ですか？そのロジックに ”根拠” が有りますか？
インデックス容量
索引付け処理時間
O
CPU クロック
O
コンテンツ転送速度
コンテンツ件数
コンテンツ件数
検索レスポンス時間
O
サーバ台数
O
運用時間
何でも正比例する.. と仮定して考えることは危険です。
十分に複数回の測定を行ない観測ポイント数を増やすことで
線形なのか指数関数的か対数関数的かそれとも非規則的か
誤った類推を冒すリスクを減らすことが出来ます。
GC継続時間
※ ここに表される図は正解である保証はありません。
あくまでも「このようなケースがありうる」一例として
ここでは解釈してください。
O
フィード経過時間
O
運用時間
一回ポッキリの測定では，傾向については何も読み取ることができません。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-14
3-2. 測定対象とする実データ量は多いほど良い
ベンチマーキングする際に用いるデータは... ；




プロダクション環境で用いる実データの傾向や特性に類似すること，あるいは本番データそのもの
データ量が多ければ多いほど好ましい
測定回数は多ければ多いほど好ましい
条件を変えた測定を多く行なうほど好ましい
無意な測定例：




本番データと全く異質なデータセット（測定用に作為的に用意した人工データ）で測定してしまう
母集団に対して標本数が余りにも少ないデータセットで測定してしまう（本番データ特性の反映不足）
数回しか測定しない（代表値や平均値が読み取れない）
データ件数を変えて別の測定をしない（傾向やブレが読み取れない）
大数の法則
http://en.wikipedia.org/wiki/Law_of_large_numbers
中心極限定理
http://en.wikipedia.org/wiki/Central_limit_theorem
確率収束
http://en.wikipedia.org/wiki/Convergence_of_random_variables
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-15
4. どこにフォーカスするべきか？
これから実施する測定目的を，どの「主題」を実証あるいは推算するためのテーマとしますか？
Metrics
Example
Data Volume
 ３億件をインデクシングすることが目標である。
 与えられた環境で何件まで保持できるかを測定することが目標である。
Data Feed
 ３億件をフィードすることが目標である。
 幾つかのフィード手法を実証確認することが目標である。
Feed Rate
 ３億件を５日間でフィードすることが目標である。
 平均フィード速度を測定することが目標である。
Query Response Time
 ある特定のクエリーを発行した際に，結果セットが返送されるまでの
処理時間を測定することが目標である。
Concurrent Query
 ある特定クエリーを複数同時並行で投下した際に，どの程度の
同時クエリー数を処理することが出来るかを測定することが目標である。
Redundancy
 システムダウン時でも，予備の系統で可用性を持つことが出来る。
 主系統を切り離しても，別系統でサーチできることを示すのが目標である。



どこに/何を主題/狙いとしますか？
あれもこれも.. と多くを同時に望むことは出来ません。
Trade-Off 関係にある相反する目標を同時に追求しないこと。
“Capacity Planning” や “Performance Tuning” と一言で指し示すことは往々にありますが，
具体的にどのメトリクスをどの程度追求したいのでしょうか？
それが曖昧では，何のためにベンチマーキングを行なうのか，どのようなベンチマーク測定すべきか，
その結果をどの様に活かそうとしたいのか，テーマが漠然としていて有意義ではありません。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-16
4-1. 期待結果と実測結果
期待結果
実プロダクション環境が完成した暁における；
 最大コンテンツ件数
 最大コンテンツ容量
 同時並行クエリー数
 クエリー応答速度
 ... etc
実測結果
ベンチマーク環境における実測値：
 コンテンツの件数と容量
 並行クエリー数
 クエリー応答速度
 ... etc
ベンチマーク環境
ベンチマーキング時に使用した環境と構成：
 ハードウェア
 ソフトウェア
 各種設定
 サーバとシステムの全体像および構成（Farm , Toplogy）
 データソースとコンテンツ
 リソース使用状況
 処理時間
 ... etc
ベンチマーク結果
から導出される
課題や問題点
期待する改善点や希望する性能
実測値と期待値との乖離度合
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-17
4-2. 測定環境と本番環境とのギャップ
【測定精度】
以下は，どこまで追い込みますか？



測定回数
パラメータ固定のままで，反復測定（バラツキやムラを軽減し平均を採る）
パラメータを一つずつ変えて測定
（パラメータ変動特性を観察する）
一回二回程度の測定から確度の高い精緻な結果と傾向や特性を読み取ることは不可能です。
パフォーマンス追求やキャパシティ推算の目標目的に最適なベンチマーキングを複数回
何度も何度も実施したうえで，統計量や傾向分析を行なうべきです。
【測定環境】
以下は，どこまで同質に揃えられますか？




サーバ台数
サーバのスペック
トポロジー（InSight を LWE Server から追い出すかどうか）
データ
（件数や特性など，本番データそのものかどうか）
ベンチマーク環境と本番環境のシステム構成，トポロジー，リソーススペック等が余りに乖離し過ぎていると，
それらの乖離因子が測定結果の活用価値を打ち消してしまいます。
ベストなのは測定環境と本番環境が同一であり，測定に用いる対象データも実データそのもの自体であることですが，
それが難しい場合には極力近しい条件に揃えることが肝要です。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-18
4-3. 測定結果の本番環境へのフィードバック
測定結果からプロダクション実環境に対して「何をどうしておく必要があるか」が判明しても，
その助言内容を構築環境に対して反映できなければ，何の意味もありません。
追求目標とベンチマーク目的の策定
ベンチマーク環境と測定データの準備
必要条件を基準として
測定した結果，どうやら
サーバは少なくとも
10台は必要みたい
ですよ？
だから早い段階で
正しいベンチマーキングを
適切に実施されていれば
よかったのに...
ベンチマーキング（測定）
実験結果の可否
統計量の分析と結果導出
... 。
そうおっしゃられても
統計データの結果が結果ですし。
で，どうするんですか？
どうしたいんですか？
サーバは2台しかないんです。
もう変えられないんです。
でもデータは削れないし
開発期間は後2ヶ月しか...。
プロダクション実環境構築への助言
プロダクション実環境モデルの見直し
プロダクション実環境の手配と構築
©2012 Uchida Spectrum, Inc. All rights reserved.
分析結果を受けてプロダクション環境に対して
それを適切に反映させることが出来ないのであれば，
残された策は余り有りません。
不足や不適切な箇所を調整できないならば，言えることは
「出来るかもしれないし出来ないかもしれない。イエスかノーだけです。
出来なかったとしてもそれを受け入れるしかないですね...。
変えることは出来ないとおっしゃっている以上，どうしようも...。」
Page-19
4-4. 期待値
ベンチマーク結果が期待値に届かなかった場合
 何を変えることで期待値に漸近できうるのか
 何を「変えることは出来ない与件」「変えることが許容される」とするのか









コンテンツの件数
コンテンツの容量
サーバ台数
サーバのスペック
トポロジー
フィードの仕方
クエリーの仕方
構成ファイルと各種パラメータ
... etc
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-20
4-5. 測定例




どのような環境と状況下において
何を主体とした時に
いかなる処理を発行すると
どういった結果が得られたのか
【例】
CPU
Intel Xeon E5-2630 x 2
RAM
32 GB
HDD
1TB 7200rpm 2.5" SATA x 2 , No SDD used
OS
Microsoft Windows Server 2008 R2 (Standard , Japanese , x64)
LWE
LucidWorks Search 2.5.1
Number of Servers
2 Servers
Topology
2 Shards
VM
No
JDK
Sun/Oracle HotSpotVM JDK 7u11
Data Source
Relational Database
コンテンツ件数
フィード件数 n （Document）
コンテンツ容量
総コンテンツ容量 m （MByte）
評価対象
クエリー送信から結果セット受信までの処理時間
クエリー式
q=*:*
期待値
Query response Time : s (Sec)
テスト結果
Query response Time : t (Sec)
考察結果
期待する値より k (Sec) 長い
©2012 Uchida Spectrum, Inc. All rights reserved.
(Distributed Index/Search)
(Physical Dedicated Servers)
(x64 , Multilingual)
Page-21
5. コンテンツのフィードに関するベンチマーキング
Data Source
File
Database
Statistics
1.
平均サイズ（中央値サイズ）
2.
最大サイズ
3.
ファイル数
4.
File Format（MIME-Type）の種別と内訳
5.
代表的なサンプル例となるファイルそのもの（数十数百個）
6.
抽出する File Properties/Metadata と Shema Field Mapping
1.
結果セットのデータ行数（レコード件数）
2.
結果セットを構成するカラム（列）の個数
3.
結果セットの各カラムに関する属性定義情報（CREATE TABLE 文）
4.
文字列データ値カラムに含まれる実データの平均サイズ（中央値サイズ）
5.
文字列データ値カラムに含まれる実データの最大サイズ（最長データ）
6.
代表的なサンプル例（CSV/Excel Format で数百件程度を出力したもの）
7.
Resultset Columns と Schema Fields の Mapping
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-22
5-1. フィード期間中のリソース状況
Sequence
Timepoint
Status
#1
OSを起動し，未だ何れのアプリケーションを起動していない状態
Engine Stopped
#2
Solr/LWE/LWS を起動して安定状態を呈し，未だ何れのフィードもクエリーも実行してない状態
Engine Invoked
#3
コンテンツのフィードを開始した時点
Before Feeding
#4
コンテンツのフィードが継続中の期間
Feed In-Progress
#5
コンテンツのフィードが完了した時点
Feed Completed
#6
コンテンツのフィードが完了して暫く経過した後の時点
After Feeding
フィード期間中は，一定間隔で測定することが推奨されます：

RAM Free Space のサイズと変動

CPU Busy Rate の値と変動

フィードしたコンテンツのドキュメント件数

フィードの所要時間
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-23
5-2. データ変更
Insert
Update
Delete
実行タイミング（規則性，随時/定時）
実行頻度（何時間おき，何日毎）
推定データ件数（平均，推定）
フィード所要時間（平均，最大）
データ変更後に気になる点があれば，記録を残しておいてください：





ディスクの消費サイズ増大
RAM 消費容量の増加
クエリー応答速度の低下
同時並行クエリー数の低減
データの完全洗い替え（全データ丸ごと削除して投入しなおす）
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-24
6. クエリーに関するベンチマーキング







クエリー
結果セット（件数，フィールド数，出力サイズ）
クエリー応答時間（Query Response Time）
同時発行クエリー（Concurrent Query Connections）
フィードしたコンテンツのドキュメント件数と所要時間
RAM Free Space
CPU Busy Rate


クエリー開始前
フィード完了後
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-25
7. 代表的な構成ファイルとパラメータ（Configuration Files）
File Name
Full Path
master.conf
LwsInstalledRootDirectory\conf\master.conf
solr.xml
LwsInstalledRootDirectory\conf\solr\solr.xml
solrconfig.xml
LwsInstalledRootDirectory\conf\solr\cores\CollectionName\conf\solrconfig.xml
schema.xml
LwsInstalledRootDirectory\conf\solr\cores\CollectionName\conf\schema.xml
dataconfig_*.xml
LwsInstalledRootDirectory\conf\solr\cores\CollectionName\conf\dataconfig_*.xml
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-26
8. ベンチマーキング実施の準備
システムの作り込みをカッチリと完成させてからベンチマーキングすればよいでしょうが
このようなタスク直列化では工期が長大化してしまいます。
デザインや設計のフェーズを行なっている最中に，別スレッドでベンチマーキング過程に
着手してしまうことが検討されます。
データソースを
決定する
データソースを分析
プロトタイピング
ザックリ感はあるが
エイヤ！で決めて
ラフにベンチマーキング
コンテンツと
取得データの確定
構成のラフな
見積もり
フィーチャ策定
パラメータ設定
プロダクション環境
を意識した
ベンチマーキング
マシンと環境
の手配と準備
Lucene/Solr/LWE/LWS は Java Application として作られている為，
OS Process としての観点および JavaVM としての観点の２観点から
監視と測定を実施することになります。
従って，Java Application の Monitoring Tools および Performance Tuning Technique を
適用することになります。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-27
8-1. 留意点

JVM Heap は少なすぎても多すぎてもいけない

RAMを潤沢に搭載しておけばよいというものでもない

JVM Options Parameters を最初から駆使調整しない

一発で「正解」が出るものではない
無論，ベンチマーキングしてみなければ適切量がどの程度かは判らないものですが，
凡その目安として，JVM Heap には 8～16GB 程度をスタートポイントとして開始してみてください。
少なすぎれば，OutOfMemory Error などメモリ不足によるエラーが発生します。
大きすぎてもいけません。 Operating System やその他のプロセスに影響が出るほど JVM で占有してはいけません。
搭載物理メモリ量のうち，数GB分は必ず OS用に残しておいてください。
-Xms は必要最小限に設定し，-Xmx は上記に留意しつつ大きな値を設定してみて，ここから試行錯誤していきます。
一般的に -Xmx の初期設定値は，搭載物理メモリ量の半分程度あたりでスタートしてみると良いでしょう。
JavaVM に沢山のメモリ空間を割り当てておくことで，メモリ不足エラーを回避できる確率は確かに高まるでしょう。
しかしながら，余りに巨大な空間をアサインすると，Garbage Collection（GC）発生タイミングでは
処理時間が長大化する（Java Objects の破棄や整理する容量と個数が多量化する）ため，かえってパフォーマンス低下
を招く可能性もあります。
JVM にアサインする空間は通常，多くても 32～64GB 程度でしょう。これよりも多くの空間を必要とする場合には，
マシンを超ハイエンド化するのではなく，サーバ台数の増強すなわち MultiShard構成を検討してください。
Solr コミュニティのコミッターや巨大システム管理熟練経験者も指摘していることですが，最初から JVMオプションを
アレヤコレヤと手を出して弄ることはしないでください。一般経験則として殆どの場合，デフォルトのままで使う
ことの方がマニアックな調整の果ての結果よりも素直で良かった，という声が寄せられています。
まずは Xms / Xmx / Xmn あたりからスタートしてみて，八方塞り的状況になってきた暁に初めてその他パラメータを
調整することを検討する... というスタンスで臨んでください。
既に解説済ではありますが，一発で正解が出るものではありません。そもそも「正解」というものはありません。
あるのは，実験した結果に基づく「妥当点」です。
メモリ割り当て量が不足していれば，途中でメモリ不足エラーが発生し，「やりなおし」が発生することでしょう。
かといって最初から大きすぎる値を設定していても，「より好ましいポイント」からは外れている可能性もあります。
Try-&-Error で何度も試行錯誤しながら，妥協点を探り出す努力が必要です。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-28
8-2. スタートポイント

搭載メモリ（RAM）はサーバあたり約24～32GB 程度をミニマム開始点とする

仮想環境は推奨しません

SAN/NAS は推奨しません

JDKによって挙動は異なる
コンテンツの特性や件数など多岐の要素に依存するので一概にメモリ量をドンピシャで算定することは出来ませんが，
LWS Server １台あたりの搭載RAM量は，24～32GB 程度を Start Point として開始してみて，不足するようであれば，
更にメモリ増強することを考えると良いでしょう。
RAM を 24～32GB 搭載しておくことで，LWS 用の JavaVM には 8～16GB 程度を割り当てることができます。
コンテンツがデータベース数百万行あるいはファイル何十万個も扱うようなヘビーな環境であれば，
RAM を 48～96GB 程度必要とするケースも出てくる可能性もあります。
フィードの途中で OutOfMemory Error が発生するようであれば，RAM増強および JVMメモリ空間拡大を実施し，
再度ベンチマーキングを実施しなおします。
Solr/LWE/LWS に代表される検索エンジンは，CPU-Bound であるよりも I/O-Bound な特性を持ちます。
つまり，Channel/Bandwidth を多量に必須とする Read/Write Access が過度なまでに継続的に発生します。
従って Channel/Bandwidth を複数インスタンスで共有するような仮想環境では，ここがボトルネックとなって
しまう懸念があります。大規模構成運用管理者やコミッターの多くも，仮想環境を積極的には推奨しておらず，
独立した物理サーバを複数台用意し構成することを実践しています。
仮想環境で動作しない訳ではありませんが，開発環境やテスティング用途に限定活用することが望まれます。
前項のように検索エンジンは著しい I/O-Bound な性向を有する為，一般的に推奨されません。
仮想環境同様，動作しない訳ではありませんが，弊社としては推奨しかねますので自己責任でお使いください。
SSD については耐久性が未知数要素ではありますが最近は改良されつつあり，バックアップを高頻度で取得する
運用実施が前提であるならば，パフォーマンス向上やボトルネック化回避のために検討してみてもよいでしょう。
最もよく採用されているのは，Oracle社（旧 Sun Microsystems 社）提供の HotSpot JVM ベースの JDK でしょう。
他には OpenJDK , Oracle JRocket , IBM JDK for Power 等々が提供されています。 Java は策定仕様上で
実装については任意とする点もありますので，必ずしもこれらで挙動やメカニズムが同一である訳ではありません。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-29
9. 監視の視点
LWS を監視する場合，以下の視点からウォッチする必要があります：
 Operating System 環境下
 Java VM で動作する Java Application として
 検索エンジンが用意する各種パラメータ指定での動作として
 コンテンツのフィード（登録，更新，削除，反映化）
 クエリー
 運用（ダウンタイム，メンテナンスの内容とスケジュール等）
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-30
10. Windows Platform における標準パフォーマンス測定ツール
Operating System の観点から CPU/RAM/Disk/Network 等を監視します：
 Task Manager （taskmgr）
 Performance Monitor （perfmon）
 typeperf ユーティリティ
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-31
10-1. 起動とともにメモリ空間は一定量が占有される
メモリ消費量の確認コマンド
Platform
Command
Windows
tasklist , typeperf 等
Linux
free , procinfo , ps , vmstat , dmesg 等
追加消費分の為の余剰空間
（OSが必要とする分も含む）
搭載物理メモリ量
LWEメモリ消費分
LWE起動中
OS
Services
Applications
LWE停止
Operating System それ自体の
作業空間の確保の為に，
常に数GB 程度（例えば約 8GB）
必ず未使用空間としてキープ
してください。
全メモリ空間が消費されるような
状況には追い込まないでください。
LWE起動開始
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-32
10-2. Task Manager （Microsoft Windows）
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-33
10-3. Performance Monitor （Microsoft Windows）
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-34
10-4. typeperf ユーティリティ
Microsoft Windows Performance Monitor と同様に Objects/Counters をモニタリングして統計情報を
収集しますが，Command Prompt から実行し，測定データを容易にファイル出力することが出来ます：
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-35
11. Java Application としての LWS
LWS は，Java 高級プログラミング言語の Source Code から製作された
ソフトウェアの一つに過ぎません。
従って Java Application を動作させる際の注意点の多くは，LWS にも当てはまります。
Java Application のチューニングやメモリ管理については，それを専門に扱った書籍
は余り見かけませんが，Web には断片的に情報が散らばっていますので
それらで学習されると宜しいでしょう。
【注意】
Oracle社では目下 “Java SE 8” を開発しており，そう遠くない将来に登場する予定です。
但し，現行の Solr/LWE/LWS が Java 8 環境で動作するかどうかは不明です。
また，Java 8 では JVM やメモリ管理の仕組みが大きく刷新されることから，
本書記載内容が適用できなくなる可能性があることは御了承ください。
（例えば，Java 8 からは Permanent Space が廃止され，別の空間が提供される予定です。）
本章は，Oracle HotSpot VM の JDK 6 および JDK 7 を対象として記載しています。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-36
11-1. JVM メモリ空間
JavaVM で使用するメモリ空間
単一のアドレス空間
JVM 固有領域
Operating System 固有領域
Java Heap
New / Nursery
DefNew
Eden
Tenured Permanent
C Heap
Stack
Stack
Eden と Survivor を併せた DefNew 領域は，
Young領域 / New領域 / Nursery領域
と呼ばれます。
Survivor
From
©2012 Uchida Spectrum, Inc. All rights reserved.
Old
To
Page-37
…
11-2. Java Application 運用時における考慮点
Java Application を安定的かつ良好なパフォーマンスを維持しながら継続実行を可能ならしめる為には，
以下のようなポイントに考慮して，リソース資源の割り当てやチューニングを意識しなければなりません：

ScavengeGC の発生が，過度に続かないこと。

FullGC の発生は，低頻度であること。

OutOfMemory Error が発生しないように，必要なメモリ空間を Java VM に割り当てること。

StackOverflow Error が発生しないように，Stack領域のサイズを適切な量にまで拡げておくこと。

不必要に大きなメモリ空間を Java VM に割り当てないこと。

Java VM にアサインするメモリ量は，少なすぎても多すぎても良くない。
ScavengeGC 自体は悪いことではなく恒常的に発生するメカニズムですが，余りに頻発化が連続するようであれば，
Eden領域が根本的に不足している可能性も疑うべきです。
FullGC 自体は Garbage Collection の一つとして Java で規定されたメカニズムですが，Stop-The-World 現象として
アプリケーションの無応答期間を生み出すことになる為，発生頻度が少ないに越したことはありません。
New領域（Eden領域＋Survivor領域）から Old領域（Tenured領域）への短命オブジェクトの移動の頻度と容量を
毎回抑えることが出来れば，Old領域のクリーンアップすなわち FullGC を軽減化できます。
つまり，Java Objects が Old領域から New領域へムーブされる前に，New領域内で早々に掃除してしまうことが望まれます。
参照期間が長い長寿オブジェクトが多い Java Application を走らせるのであれば，事前に Tenured領域を大きく確保しておきます。
OutOfMemory Error は，New / Old / Permanent / C Heap / Stack いずれかの領域における必要量に対する不足を起因
として発生している可能性があります。
New領域が大きすぎると，ScavengeGC 発生時の処理時間が長くなってしまい，パフォーマンスが低下します。
Old領域が大きすぎると，FullGC 発生時の処理時間が長くなってしまい，アプリケーションの凍結状態期間が長大化します。
Operating System や Paging を妨げるほどの JVM メモリ割り当て量は，本末転倒です。
Java VM へのメモリ割り当て量が小さすぎれば GC 頻発化や領域確保失敗を誘発するので問題ですが，多すぎても逆効果です。
リソースを潤沢に搭載したハイエンド機を用意すれば低リスクである，という考え方は根源的に間違っていることを裏付けます。
適切なメモリ量や JVM Options パラメータ設定を行なうには，ベンチマーキングによる実証値を根拠としなければなりません。
必要となる JavaVMメモリ量や搭載RAM量は，事前の十分なベンチマーク測定エビデンスの他からは算出できません！
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-38
11-3. LWS の JVMメモリ割り当て
文字コード
UTF-8
改行コード
LF-Only （CR-Only や CR+LF ではありません）
BOM
無し
©2012 Uchida Spectrum, Inc. All rights reserved.
（Shift-JIS や EUC-JP ではありません）
（Byte Order Mark は含めないでください）
Page-39
11-4. LWS の JVMメモリ割り当て（Continue）


Component.jvm.params = の式右辺に，パラメータを記載します。
例えば，-Xms -Xmx -Xss -Xmn -XX -D パラメータ群などを登録します。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-40
11-5. LWS の統計情報取得
LWS の起動時に，パラメータ “-Dcom.sun.management.jmxremote” を “master.conf” に
追加指定しておくことで，起動後のパフォーマンス関連情報を Probe 出来るようになります。
本書で後述する jconsole や jvisualvm 等の Instrument Utility で監視する場合に必要となります。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-41
12. jps ユーティリティ
jps ユーティリティは，稼働している Java VM の Virtual Machine Identifier（VMID）の一覧を返します。
VMID は必ずしも OS 側の Process ID（PID）と同じではないので，
tasklistコマンド（Windows）や psコマンド（Linux）で VMID を調べることは出来ません。
Java Application の Java Process ID を調べたい場合は，必ず jps コマンドを使ってください。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-42
13.
jconsole による LWS のモニタリング
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-43
13-1. jconsole の実行例（Part-1）
これらについては，然るべき理由が無いにも関わらず
グラフが右肩上がりの傾向を持続するようであれば，
何らかの課題を抱えている可能性を疑うべきです。
 クラス
 スレッド
 Code Cache
 PS Perm Gen
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-44
13-2. jconsole の実行例（Part-2）
フィード中の監視
:
:
:
:
:
:
:
:
Tenured領域
ScavengeGC の頻発化が
観察される
チューニング前
Eden Committed
Eden Maximum
Old Committed
Old Maximum
YoungGC Time
YoungGC Count
FullGC Time
FullGC Count
Eden領域
12288
12352
28672
28672
2.342
314
0.666
3
KByte
KByte
KByte
KByte
Sec
Collection
Sec
Collection
短時間（20min）の間に FullGC が
３回も発生を許してしまっている
Tenured(Old)領域の高充満率と充満回数
が原因で高コストな FullGC を誘発している
Heap領域が
常に充満化している
右肩上がり傾向が持続したことが心配であったが
上昇率が対数曲線状態を呈したことで懸念は低下した
チューニング後
Eden Committed
Eden Maximum
Old Committed
Old Maximum
YoungGC Time
YoungGC Count
FullGC Time
FullGC Count
: 152704 KByte
: 327488 KByte
: 11328 KByte
: 11328 KByte
: 1.570 Sec
:
28 Collection
: 0.000 Sec
:
0 Collection
ScavengeGC の
発生回数と発生間隔が
緩慢化された
Heap領域の占有率
が低下している
ここには示していませんが，同一コンテンツのフィード時間が若干短縮されたことも確認されています。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-45
14. Oracle/Sun JDK におけるその他の標準ツール
パフォーマンス関連の統計取得ツールとしては，jconsole ユーティリティ以外にも
例えば以下のものが用意されています：




jcmd ユーティリティ
jinfo ユーティリティ
jmap ユーティリティ
jstat ユーティリティ
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-46
14-1. 各ツールの機能概略
jconsole
JVM で実行されているとき Java Application に関する詳細な情報を提供するツール。
Memory と CPU のプロファイリング， Heap Dump 解析や Memory Leak 検出などを行なう。
jvisualvm
JVM を監視するための JMX準拠のツール。
Local VM , Remote VM , Appplication の監視を行なうことができる。
jps
JVM Instances の一覧を表示する，Process Status 提示ツール。
jinfo
指定された Process , Core File , Remote Debug Sever の構成情報を出力する，構成情報提示ツール。
jmap
共用 Object Memory Map または Java Heap Memory の詳細を出力する，メモリーマップ情報
提示ツール。
jstat
JVM に接続して，コマンド行オプションの指定に従ってパフォーマンス統計データを
収集および記録する，JVM 統計データ監視ツール。
jhat
Heap Dump をブラウズできるようにするツール。
jstack
Thread Stack Trace を出力するツール。
jcmd
JVM に対する診断コマンドを発行するツール。
【注意】
Oracle（旧 Sun Microsystems）社が提供する Java Development kit（JDK）に同梱される
これらのツールは，サポート対象外であり，且つ将来バージョンでも同様に提供される保証は
確約されていません。
将来の特定バージョン以降では，提供されなくなる可能性は否定できません。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-47
14-2.
jmap ユーティリティ
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-48
14-3.
jstat ユーティリティ
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-49
15. GCViewer
GCViewer は，tagtraum industries incorporated 社の Hendrik Schreiber 氏によって開発された
JVM Garbage Collection 状況を観察する為の無償ツールです。
現在では氏による改良は停止していますが，Jörg Wüthrich 氏を中心とする一部有志による Fork Project
としてオリジナルとは別に引き継がれています。
jconsole や jvisualvm は，リアルタイムに目視確認するには適したツールですが，
長期に渡って GC統計情報を取得し続けることには難点がありますし，
オンライン状態で使うことに重きが置かれています。
GCViewer は予め取得しておいた GC Log File から解析およびグラフ化を行ないますので，
オフライン状態でジックリと分析する場合や長期間測定していたログの分析に便利です。
GCViewer は，若干の不具合や挙動を含んでいますが，無償ツールであることを踏まえて利用してください。
GNU Lesser General Public License ライセンス形態にて提供されています。
本章では，JDK 1.7 に対応した GCViewer Version 1.32 を例に示します。
旧バージョン（オリジナル）
http://www.tagtraum.com/gcviewer-download.html
新バージョン（フォーク）
https://github.com/chewiebug/GCViewer/wiki/Changelog
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-50
15-1. GCViewer （Part-1）
LWS のケースを，以下に示します：
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-51
15-2. GCViewer （Part-2）
ヒープメモリの最大サイズ（赤色）
ヒープメモリの現使用量（濃青色）
FullGC発生タイミング（灰色）
Throughput
JVM実行期間中における，GC時間を除外した
JVM非ポーズ時間の割合です。
GCによるポーズ時間（緑色）
©2012 Uchida Spectrum, Inc. All rights reserved.
Throughput < 85～90% の場合は，
Garbage Collection 発生がボトルネック
と判断される可能性が高い為，
Heap Size チューニングを検討します。
Page-52
16. Query Log
クライアントが LWE/LWS/Solr に対してどのような検索クエリーを発行したのか確認するには，
Query Log File を参照することによって，それらクエリー内容を確認することが出来ます。
LWS の場合は，下記のロケーションにログが生成されます：
 LwsInstalledRootDirectory\data\logs\core.request.YYYY_MM_DD.log
LWS に発行されたクエリー群は，以下のキーワードで Find することにより確認が可能です：
 /select?q=…
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-53
17. Cache
検索エンジンは大量のデータを探索したり読み書きするという点で，従来のデータベース管理システムに
似ています。つまり，I/O が著しく高い傾向を呈する性質があります。
この為，低速な Physical Disk I/O は回避できるならば極力避けることが望まれます。
LWS ならびに Apache Lucene には専用のキャッシュが組み込まれており，必要とするデータが
Cache つまり RAM に在れば Physical I/O アクセスを誘起してまで Disk Access を行なわずとも
用件を満たすことが出来ます。
つまり，データの探索や求めるドキュメントがキャッシュにあれば，Disk Access を回避し
パフォーマンス低下を軽減できることになります。
用意されるキャッシュは，以下の通りです：
Management
Lucene
Solr
Configuration
Lucene Cache
Solr Caches
ユーザ定義（任意）
※１：
※２：
Cache Name
Cache Type
Field Cache
FieldCache
Filter Cache
filterCache
Field Value Cache
fieldValueCache
Query Result Cache
queryResultCache
Document Cache
documentCache
－（User Cache）
－（Generic Object Cache）
Lucene のキャッシュである Field Cache については，管理者による制御は出来ません。
User Cache は LWS や Solr における標準キャッシュではありません。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-54
17-1. LWS管理コンソールからのキャッシュ指定
LWS 2.x の管理コンソールからは，Solr Caches 各々のキャッシュ設定を指定することが出来ます。
設定後は，LWS を再起動してください。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-55
17-2. HTTPアクセスによるキャッシュ現況確認

http://SolrServerFqdn:PortNumber/solr/CollectionName/admin/mbeans?stats=true&cat=CACHE
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-56
18. SolrMeter
SolrMeter は，Apache Solr を対象とした Stress Tool の一つであり，Open Source Freeware です。
Apache Solr を対象としていますが，LWS を対象に利用することも勿論可能です。
SolrMeter は，主に以下２つの目的で活用することが出来ます：
 検索負荷（クエリー）および更新負荷（索引データ変更）を掛けてパフォーマンス測定を行なう。
 Solr Cache の利用状況をモニタリングする。
SolrMeter の欠点としては，以下が挙げられます：
 挙動不審あるいは動作不安定なことがあり，バグもある。
 長時間の継続稼働で動作不安定となることが見受けられる。
 改良やメンテナンスなど，Open Source Project としては活発ではない。
Apache JMeter を使うことも検討されえますが汎用的な Java Web Application パフォーマンス測定ツール
である為，Solr/LWS に特化していないという欠点があります。
本章では，SolrMeter 0.3.0 を例に示します。
SolrMeter Homepage
http://code.google.com/p/solrmeter/
SolrMeter Download
http://code.google.com/p/solrmeter/downloads/list
SolrMeter Usage
http://code.google.com/p/solrmeter/w/list
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-57
18-1. SolrMeter （Part-1）
まず準備ステップとして，負荷掛けに利用するクエリーや更新内容を登録します：
デフォルトでは Apache Solr に標準同梱されているお試し用の “example” を対象としたサンプル値
になっていますので，これをテスト環境に適合するように全面的に書き直します。
文字コード UTF-8 ，改行コード LF-Only ，BOM 無しでファイル保存してください。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-58
18-2. SolrMeter （Part-2）
クエリー性能
アップデート性能
ファイルへの書き込み
単位時間あたり，どれだけのクエリーを
処理することが出来たか（QPS）
を表示します。
単位時間あたり，どれだけの
更新オペレーションを達成できたか
を表示します。
Commit および Optimize 処理
に関する統計情報が表示されます。
Query History
クエリーの Response Time を示します。
右側は，クエリー応答時間が長大であった
遅いクエリーの件数を示しています。
©2012 Uchida Spectrum, Inc. All rights reserved.
Operation Time Line
時間フレームあたりの処理所要時間を示します。
高いポイントは処理時間が長く掛かったことを示しています。
Page-59
19. Optimize に関する誤解
Optimize オペレーションを行なえばクエリー性能が改善される，という件はよく Internet で見掛けますが
実際には Optimize そのものにクエリー性能を改善する役割も機能も有りません。
“Optimize” というコマンド名そのものが誤解を招きやすく改名すべきだ，という声すら Solr Community で
聞かれるほどです。
Optimize は，以下の目的で提供されます：
 Update および Delete オペレーションによって発生した，データ領域内の「穴」を埋め潰す。
 多セグメントによる大量発生した Data Files を，単一セグメントに纏め上げてファイル数を減らす。
 Linux環境では File Handler の上限設定を意識する必要があるので，Solr Data Files のファイル数が
少ないことは，ハンドラ多量消費を軽減するのに役立ちます。
従って Contents Feed を行なっていない状態が持続してきたシチュエーションにおいては，Optimize を実施
する必要性（意義）が有りません。 Optimize を行なってクエリー性能が改善することは有り得ない話という
訳ではありませんが，直接的な理由ではありません。もし仮に Optimize オペレーションを実施しないと
クエリー性能が改善しないようであるならば，むしろ MergeFactor および Solr Cache が不適切設定状態で
あることを疑うべきです。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-60
20. Wrap-Up
ここまでで学習してきた内容を復習します：











©2012 Uchida Spectrum, Inc. All rights reserved.
CPU
RAM
JavaVM
ディスク（Storage）
MergeFactor パラメータ
コンテンツのフィード
クエリー
Commit
Solr キャッシュ
シャード
スキーマ
Page-61
20-1. CPU

一般的な通常クエリーであれば，超ハイエンドなスペック（多数の CPU cores や高速な Clock）が
要求されるケースは多くはありません。

SMART/InSight® は内部的に非常に複雑で長いクエリーを多量に発行する為，一般的な LWS 活用モデル
に比べると，CPU パワーを多く必要とするかもしれません。

CPU Cores を十個も必要とするようなゴージャスなサーバ機は概して不要と言えるものであり，
中庸なサーバ機に採用される 2 ～ 4 Cores で充分であると思われます。

どれだけの CPU パワーが要求されるか，妥当であるか，についてはベンチマーキング計測中における
CPU Busy Rate 等の統計量を観察したうえで決定する必要があります。

Windows OS 環境であれば，Task Manager や Perfmon/Typeperf で確認できますので，
ベンチマーキング時に活用すると良いでしょう。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-62
20-2. RAM

LWS のパフォーマンスは，搭載 RAM とメモリ割り当てに多大な影響を受けます。

LWS Server は Dedicated Server として用意することが望ましいと言えます。
つまり，LWS 以外の Applications や Services 等を同居させず，そのサーバでは LWS（とOS）だけに
全リソースを占有させるということです。
LWS Server に SMART/InSight® 等を同居させることは不可能ではありませんが，
パフォーマンスや運用といった観点から観察した場合に適切とは判断できないかもしれません。

LWS にメモリ割り当てする際，Operating System が必要とする空間分を食い潰さないようにする
必要があります。最低でも 4 ～ 8GB 程度の RAM Space は，Operating System が消費できるように
常にリザーブしておき，残りを LWS およびその他で使うよう配慮してください。

索引付け対象コンテンツの件数や容量に関わらず，LWS には最低でも 16 ～ 24 GB のメモリ空間量を
アサインする必要があります。
コンテンツの件数や容量，コンテンツ内に含まれるテキスチュアル情報の複雑さや語種類数などが
多くなれば，より多量の RAM が必要になります。

ある特定時点において LWS がメモリ空間量をどのように消費しているかは，OS 側が提供する
Commands/Tools からでは観察できないことが殆どです。
Java Application のメモリ消費を観察する専用のコマンドあるいはツールを用いて計測してください。

LWS に割り当てるメモリ空間量は，大きくし過ぎないことが賢明です。
余りに空間量が大きくなると，Full GC が発生した際に Compact-Mark-Sweep 処理が内部で発生し，
何もかもが停止する Stop-The-World 現象を誘起します。これにより，フィードもクエリーも全てが
まるでハングしてしまったかのようにストールしてしまいます。
LWS Server は最大でも 64 ～ 128 GB 程度の RAM 搭載に留めておくのが良いでしょう。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-63
20-3. RAM（Continue）

LWS Server に潤沢な RAM を搭載すればよい，というものではないことは前項で紹介した通りであり，
Full GC が発生した際の Stop-The-World 現象による負のインパクトが大きく表れることになります。
とはいえ，大量データを索引付けしなければならず LWS がメモリ空間サイズを多量に要求するような
モデルも有り得る話です。このような時は，一台のサーバに詰め抑え込むのではなく，複数の
LWS Servers への分散化つまり MutliShard （Distributed Indexing/Search）モデルを採用することを
検討してください。

Stop-The-World 現象の継続時間は，場合によっては数秒から数十秒に至ることも考えられます。
発生頻度や継続時間については各環境依存の固有問題ですので，ここでは何とも言えません。
但し，Stop-The-World 現象が実際に発生した際，それを余り大きなダメージとは感じない
というユーザや管理者が居るかもしれません。
そのような場合には，LWS Server に対してより多くの RAM を搭載し，広大なメモリ空間を
LWS に与えることを検討してみても良いでしょう。

Java Application である性質上，GC を抑制することは出来ませんし，またそれを悪であると
断定することは無意味かつ誤りですが， ScavengeGC にせよ Full GC にせよ，Garbage Collection の
発生頻度や発生回数は少ないに越したことはありません。

どの程度のメモリ空間量を LWS にアサインすべきか，はベンチマークする以外に解は有りません。
多すぎてもムダですし，且つ FullGC 発生時のインパクトが大きくなってしまう懸念もあります。
少なすぎれば GC が多発してしまい，パフォーマンスが発揮できません。
最悪時には，Out-Of-Memory-Error （OOME）となり，クラッシュしてしまいます。
新システム運用開始の初期段階のみならず，管理者は定常的にメモリ空間利用状況を監視すべきです。

Eden , Survivor（From と To） , Tenured の各領域のサイズと比率を，慎重に選定すべきです。
公式や方程式で即答できるようなものではありませんから，日頃から挙動や統計量を観察する習慣が
必要となるでしょう。ヒープ領域サイズは，パフォーマンスに多大な影響を与えます。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-64
20-4. JavaVM

JDK には，jconsole や jstat 等の便利なユーティリティ（コマンド）が用意されていますので併せて
インストールしておくと便利でしょう。これらのツールは，JRE インストールでは提供されません。

最も多くに採用され多数の実績を誇る JVM は，Oracle（元 Sun Microsystems Inc）が提供する
HotSpot JVM でしょう。 JDK6 または JDK7 のいずれかを採用することが出来ますが，
JDK7 を避ける理由が無いならば，これを採用すれば良いでしょう。
なお，最近 Oracle HotSpotJVM で脆弱性が指摘されている為，新アップデート版を採用してください。

Java では，ひとたびメモリ空間に占有すると，その空間内が実質的には不要オブジェクトで充満していた
としても，これから発生する新規オブジェクトによって空間内空き領域が要求されない限りは，
現行空間を解放しません。従ってある特定の処理が完了しても，その処理を開始する前の消費量
前後にまでメモリ空き空間が復活するか，というと，そうならないケースが多々あります。
従って，多量にメモリ空間を消費する処理が完了した後に，もしメモリ空間が不必要に解放されないまま
の状態に陥った場合には，いったん LWS を停止し再起動しなおすと良いでしょう。

Java では，新規オブジェクトが生成されると，まず Eden 領域に配置されます。
Eden 領域内でそれが不要オブジェクトとして消滅するなら構わないのですが，より長く必要である
とマークされると Survivor 空間を経由し，長期間の参照がある長命オブジェクトは最終的に
Tenured（Old）領域へと送られます。この Tenured 領域がオブジェクト群で充満してしまい，且つ
参照が皆無となった不要オブジェクトが発見されなければ，近々に Out-Of-Memory Error が発生し，
クラッシュします。生成されたオブジェクトが必要な処理を達成した後に早々に消滅するのなら
良いですが，長寿命なオブジェクトが増加するに従い，OOME の危険性が増すことになります。
LWS を停止し再起動するタイミングを設けることが出来るなら，それの実施は好ましいことです。

JVM の種類により，内部処理メカニズムは異なります。 OpenJDK や JRocket は，HotSpotVM と
挙動や仕組みが同じではありません。また，チューニング用パラメータも同一ではありません。
なお，JVM の種類差によりパフォーマンス差が観察されることがあります。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-65
20-5. Storage

ベンチマーキングによる事前検証なくして，搭載ディスクサイズについては何も言及できません。

ファイルやデータベース行の件数個数だけで決まる訳では，ありません。
例えば，「１万ファイル」といっても，技術論文ファイル１万個と見積書ファイル１万個では
比較することがナンセンスです。
また，「１０ページ分の Microsoft Word ファイル」といっても，登場する単語バリエーション数が
少ないＩＴ関連文書と，大量の単語種類数をもつ純文学小説とでは，インデックス特性は
全く相異なるものとなるでしょう。

ディスク空き空間サイズは，現行消費量の３倍以上は残されていることを常に担保してください。
LWS を稼働している最中に，ピーク時には瞬間的とはいえ，2.5 ～ 3.x 倍に消費量が増えることが
あります。中間ファイルは一時的な処理期間中にて生成されますので，最終的には元サイズ程度へと
落ち着くのですが，とはいえピーク時に要求された空間量が確保できなければ，その処理はエラーとなり
実行失敗となってしまいます。

最近は，SSD （Solid State Disk）が安価になり，サーバ用のものも入手容易となりつつます。
Solr Committers の一部の方からは，少し以前までは安定性に欠けていたことや，実績が乏しいことから
まだ様子見の意見も無くはないのですが，従来の磁気ディスクと比較すると著しく優れたパフォーマンス
を叩き出すことから，利点欠点を天秤に掛けたうえで採用してみるのも，悪くはないでしょう。

SSD にせよ磁気ディスクにしろ，永続的にデータが安全に保全できることを保証するものでは
ありません。バックアップ運用ストラテジの策定と実践は，絶対に必要です。

ディスクへの書き込み回数の削減化には，一回あたりの書き込みバッファ量を増やすことを検討します：
 LwsInstalledRootDirectory/conf/solr/cores/CollectionName/conf/solrconfig.xml
•
デフォルト設定は， <ramBufferSizeMB> 64 </ramBufferSizeMB> です。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-66
20-6. MergeFactor

LWS は，ドキュメント更新処理によって発生するセグメント増加に連動して，発生したセグメント群を
単一セグメントに纏め上げる処理をバックグラウンドで行ないます。セグメントは複数個のファイルの
セットとして定義されており，各セグメントは論理的にインデックスの一部分を形成します。
これら複数セグメントを単一セグメントに纏め上げることにより，LWS のデータファイル数を
減らすことが出来ます。

クエリー処理を担当する IndexerSearcher は，セグメント単位でロードします。従って，
クエリー観点からすると，インデックス構造体を構成するセグメント数は，少ない方が有利となります。
一方，特定セグメントが参照されている最中にドキュメント更新処理が発生すると，その更新データは
別の新規セグメントに保持されることになります。従って，コンテンツフィード観点からすれば，
セグメント数を多く保持できるほうがブロックさずに済むことになります。

セグメントのマージ処理は，セグメントを構成するファイル内のデータ群を新規ワンセット分の
セグメントに整理したうえで書き戻すようなものなので，Disk Access（物理I/O）が多発します。
つまり，マージ処理が行なわれている最中は，ディスクへの負荷が極めて高くなります。

MergeFactor値は，以下のファイルで設定します：
 LwsInstalledRootDirectory/conf/solr/cores/CollectionName/conf/solrconfig.xml
•
デフォルト設定は， <mergeFactor> 10 </mergeFactor> です。

Index Optimize は，MergeFactor=1 にセットして，インデックス構造体を単一セグメント（または
最少数セグメント群）へとその時点において纏め上げることと同等である，と考えることが出来ます。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-67
20-7. MergeFactor（Continue）
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-68
20-8. Contents Feed

LWS が単位時間あたりにインデクシング処理できる能力は有限である為，更新速度や更新処理時間を
短縮する決め技は有りません。

IndexerWriter によってインデックス更新（Insert/Update/Delete）が行なわれている最中に
クエリー要求が受け付けられると，新規の IndexSearcher インスタンスが起動されてしまい，
メモリ消費量が一気に増加します。また，IndexerSearcher への Warm-Up も行なわれる為，
クエリーの初回レスポンスは低下します。
従って，コンテンツ更新を行なっている期間中は，クエリーが発行されることを抑止できると良い
でしょう。更新期間と検索期間が重ならないように出来ることが好ましい，と言えます。

MultiShard 構成の場合，各シャード単位でコンテンツ更新を行なうことは可能です。
従って，各シャードへのフィードを全シャード同時並行的に進めても構いません。
但し，どのコンテンツをどのシャードに送り届けるかは，作業者側が決定しなければなりません。
また，コンテンツを一意に特定する識別子フィールドの値は，コンテンツ間で重複しないように
一意かつ非空な値をセットしておくことも，作業者側の責任となります。
 一回あたりのフィードでインデクシングするコンテンツ量は，少ないことが好まれます。
また，一回あたりのフィードで掛かるインデクシング所要時間は，短いことが好まれます。
大量データフィードや長時間フィードを行なう場合には，これを複数回フィードに分割してください。
一回のフィードで転送するデータの件数やサイズが多いと，著しいメモリ消費量とメモリ非解放が
発生しまいます。

フィード継続期間中にコミット処理を発行すると，フィード中とコミット分の IndexerWriter が
同時発生してしまい，著しいメモリ消費が発生してしまいます。
インデックス更新処理期間中のコミットは抑制するか最小限度に留め，フィード完了時に纏めて
コミットすることを検討してください。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-69
20-9. Query

IndexerWriter によってインデックス更新（Insert/Update/Delete）が行なわれている最中に
クエリー要求が受け付けられると，新規の IndexSearcher インスタンスが起動されてしまい，
メモリ消費量が一気に増加します。また，IndexerSearcher への Warm-Up も行なわれる為，
クエリーの初回レスポンスは低下します。
従って，コンテンツ更新を行なっている期間中は，クエリーが発行されることを抑止できると良い
でしょう。更新期間と検索期間が重ならないように出来ることが好ましい，と言えます。

MultiShard 構成の場合，各シャード単位でクエリー発行を行なうことは可能です。
例えば，年度別にシャードが区分化されている場合（例えば，第nシャードは 201n年のデータを保持）
特定年度のデータだけに対してクエリーを発行したいならば，全シャードにではなく
その年度シャードのみへクエリーを発行する，といった効率的利用が考えられます。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-70
20-10. Commit

コミット処理を行なう最適なタイミングは，フィードもクエリーも発行されていない時です。
コミット処理とフィードがバッティングすると，別の新規 IndexerWriter インスタンスが
発生しまいます。
コミット処理とクエリーがバッティングすると，別の新規 IndexSearcher インスタンスが発生します。
これらのインスタンス生成では多量のメモリ消費が発生し，JavaVM のヒープ領域を一気に圧迫します。

NRT（Near Real-Time）フィーチャの Soft Commit を発行することで，以降のクエリーでは
当コミット分の変化が観察可能となります。
この時の変更分データはメモリに置かれているだけであり，データファイルに保存されていませんので
非永続的状態に過ぎません。但し実際には，トランザクションログ tlog に変更アクティビティ情報は
書きこまれている為，ディスクアクセスが発生しない訳ではありません。

データファイルに永続的に更新内容を書き込むには，Hard Commit を発行します。

更新内容がクエリークライアントに対して本当にすぐに観察可能として提供しなければならないのか
よく考えてください。その必要性が少ない場合には，Soft Commit の不使用を検討してください。

Hard Commit は，データファイルに書き込みを行なう為 Physical I/O の発生は免れません。
更新情報は纏めてデータファイルに反映するよう，緩やかな頻度で行なってください。
なお，余りに間隔が空き過ぎていると，障害発生時に最新最後の Hard Commit タイミング以降の
更新内容がデータファイルに反映されないままになってしまいます。
但し実際には，tlog に更新アクティビティ情報が残存していれば，その記録を用いて復旧されます。

一般的には，Hard Commit は最速で数分から数十分の間隔，Soft Commit は最速で数十秒に一回
の間隔をとります。実際には，より緩慢なペースで動作させることを検討してください。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-71
20-11. Solr Cache

Solr の優れたクエリー性能は，キャッシュの効果的活用を前提としている面もあります。
キャッシュを有効に利用するようクエリー構文やクエリー発行順序を意識できると良いでしょう。

非決定的関数（例えば NOW関数）をクエリー構文内に含めると，キャッシュ活用が出来なくなります。
NOW関数の場合は，刻一刻とマイクロ秒単位で変化する日時時刻値を返す為，前クエリーと後クエリー
では NOW関数の戻り値が同じになりません。但し，戻り値を日単位や時単位に丸めるのであれば
クエリーを活用できる確率が高まります。

キャッシュ空間は，JavaVM ヒープ領域内の一部として確保されます。
従って，キャッシュ空間サイズを大きくすればヒープ空間を圧迫します。
キャッシュ空間を拡張する場合には，ヒープ空間も併せて領域拡張すべきかどうか
慎重に検討してください。

キャッシュの Eviction Rate が高いということは，キャッシュ内に残存していたオブジェクトが
後発で流入してきたオブジェクトに追い出されて破棄されてしまう頻度や回数が高いということです。
キャッシュに残存し続けることが好ましいと単純化できるものではありませんが，レートが常に高め
である場合には，キャッシュ空間サイズを広げるべきではないかということを考えてみてください。
但し，キャッシュに残存している価値がない為に追い出された，という理由で Evict しているケースも
ありますので，この場合はキャッシュに留める意義が小さいということでむしろキャッシュ空間を
小さくした方が良いことになります。

キャッシュに対する Lookup や Hit Ratio が低いということは，キャッシュが有効活用されていない
可能性を物語っています。領域を小さくすることを検討してみてください。あるいは利用率が低いなら
いっそのことサイズを０にセットして使わせないことも検討できます。
キャッシュ空間を廃止すれば，その分だけヒープ領域を解放することができます。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-72
20-12. MultiShard

一台の LWS Server に全コンテンツをフィードして巨大なインデックス構造体を構成することは
理論的には可能ですが，潤沢な RAM メモリ空間の割り当てが必要になります。
その為，複数台の LWS Servers を用意し，インデックスを例えば 1/n ずつに折半して保持させることで
一台あたりの負荷度合を軽減化することが考えられます。

LWS で Distributed Indexing 構成を組んだ場合，フィードしたコンテンツから作られるインデックスは
round-robin に Shards へ書き込まれて行きます。

シャード台数を一台構成から複数台構成へと増やしていくと，当初は負荷分散の効果により
パフォーマンス向上が見込まれますが，台数が多数になると，今度は逆に低減する傾向を呈することが
知られています。実際にはデータ特性やフィードとクエリーの傾向など多岐因子に影響されますので，
実環境で計測されることが重要です。

Distributed Indexing および Distributed Search では，トポロジー（ファーム）を構成する LWS Servers
のうち特定一台が Main Coordinator Shard となり，残りは従属シャード Paired Shards になります。
Main Coordinator Shard は Paired Shards よりも若干負荷が高くなる為，Main Server の
リソースやスペックはやや高めのもので用意すると良いでしょう。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-73
20-13. Schema

定義するスキーマ内容が複雑あるいは多量であるほど，パフォーマンスに悪い影響を与えます。

以下に該当するようなケースでは，その機能の使用を回避し捨て去るように英断することも大切です：
 使うかどうか判らない...
 今は不要だけど，もしかしたら将来時には必要になるかもしれない...
 使うことはあるのかもしれないけど，日常的ではないし，利用といってもマイノリティーだろう...
恒常的に大多数のユーザが必要する機能以外は，奇麗サッパリと捨て去る勇気は必要です。

以下の Features は極力採用を抑制し，使用を回避してください：
 ソート（並び替え）
 ファセット（ドリルダウン）
欲張りすぎれば
 ジョイン（結合）
早々に破綻します
 STATS （集計統計量算出）
 ハイライト（ヒット箇所の特定化）
 ベクトル（スコアリング）
 Geo-Spatial（緯度経度情報に基づく距離空間クエリー）
上記はリソース消費や演算処理にパフォーマンス観点でネガティブな影響を与えますので，なるべく
使わずに済むなら使わないように工夫してください。
使う可能性が捨て切れないから盛り込んでおこう，という発想は好ましいものではありません。

小さいことは良いことです：
 定義するフィールドの数は，極力少なくする。
 冗長あるいは予備のフィールドを持たせない。
 データソースにアクセスできるならば，LWS 側に値を持たせない（Store Fields を作らない）
 フィールド値を別フィールドにコピーしない（Copy Fields を作らない）
 フィールドに格納する値は，極力小容量のコンパクトな値とする（長い文字列を保持しない）
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-74
20-14. 検索エンジンの使命と役割

検索エンジンや LWS で「出来ること/出来ないこと」「長所/短所」を理解したうえで，
既存技術や従来システムおよび検索エンジン以外の新技術と，うまく分担しあい
総合的に意義あるシステムに纏め上げることが重要です。
同じような機能を複数システムで実装することは不要であり，既存システムが実装済の機能については
検索エンジン系システムで被ってまで持つ必然性はなく，既存機能へ引き渡しすればいいだけです。

検索エンジンは，長大で多量のテキスチュアル（文字列）情報をハンドリングすることに長けています。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-75
20-15. ベンチマーキング

必要なハードウェアスペックや搭載リソース量は，ベンチマーキング無くして推算することは
不可能です。

負荷テストやメモリ割当量算出は，「うまくいった」か「エラーになった」かの二者択一結果でしか
現れません。エラーになれば，条件を変えて再度テストしなおしが必要です。
従って，一回や数回のテストで最適値が求まることは有り得ません。

ベンチマーキングは長時間の計測と分析を要するものです。
また，実際にエンドユーザが使い始めてからの状況は，事前の評価時とは予想もしない挙動や特性を
示すことも多々あります。従って，運用開始後のベンチマーキングも必要です。

ベンチマークフェーズは信頼できる精度ある結果を求める為に，試行錯誤や反復測定など発生します。
故に，プロジェクトの早期段階から，アプリケーション設計とは別工程で着手開始することが
望まれます。
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-76
21. 知っておくと便利なアクセス方法（参考）
Optimize


curl http://LwsServerFqdn:8888/solr/CollectionName/update --form-string optimize=true
curl http://LwsServerFqdn:8888/solr/CollectionName/update?optimize=true
Commit


curl http://LwsServerFqdn:8888/solr/CollectionName/update?commit=true
curl http://LwsServerFqdn:8888/solr/CollectionName/update -H
"Content-Type:text/xml; charset=CharacterSetName" --data-binary "<commit/>"
Rollback


curl http://LwsServerFqdn:8888/solr/CollectionName/update?rollback=true
curl http://LwsServerFqdn:8888/solr/CollectionName/update -H
"Content-Type:text/xml; charset=CharacterSetName" --data-binary "<rollback/>"
Status Check

http://LwsServerFqdn:8888/solr/admin/cores?action=status
Statistics

http:/LwsServerFqdn:8888/solr/CollectionName/admin/system
Update Handler Stats

http://LwsServerFqdn:8888/solr/CollectionName/admin/stats.jsp#update
Solr Luke

http://LwsServerFqdn:8888/solr/CollectionName/admin/luke?wt=xslt&tr=luke.xsl
Solr Backup

curl http://LwsServerFqdn:8888/solr/CollectionName/replication?command=backup
cd LwsInstalledRootDirectory/data/solr/cores/CollectionName/data/snapshot.DateTime/
Delete By Query

curl http://LwsServerFqdn:8888/solr/CollectionName/update -H "Content-Type:text/xml; charset=CharacterSetName"
--data-binary "<delete><query>QueryConditionForDelete</query></delete>"
Delete By ID

curl http://LwsServerFqdn:8888/solr/CollectionName/update -H "Content-Type:text/xml; charset=CharacterSetName"
--data-binary "<delete><id>DocumentIdentifierValue</id></delete>"
件数確認

curl http://LwsServerFqdn:8888/solr/CollectionName/select/?indent=on&q=*:*+&start=0&rows=0
&qt=standard&wt=xml&debugQuery=on&explainOther=&hl=on&hl.fl=body
ログ確認


http://LwsServerFqdn:8989/collections/CollectionName/log
http://LwsServerFqdn:8888/logs
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-77
22. Question-&-Answer
Capacity Planning および Performance Tuning の２トピックに関して
何か御質問は御座いますか？
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-78
XXX
御清聴ありがとうございました
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-79
©2012 Uchida Spectrum, Inc. All rights reserved.
Page-80

Download Report