©2013 Uchida Spectrum, Inc. All rights reserved. SMART/InSight ® Partner Training LucidWorks Search － サイジングの考え方 と パフォーマンス測定 2013 / May / 24 Uchida Spectrum,

Presentation on theme: "©2013 Uchida Spectrum, Inc. All rights reserved. SMART/InSight ® Partner Training LucidWorks Search － サイジングの考え方 と パフォーマンス測定 2013 / May / 24 Uchida Spectrum,"— Presentation transcript:

1 ©2013 Uchida Spectrum, Inc. All rights reserved. SMART/InSight ® Partner Training LucidWorks Search － サイジングの考え方 と パフォーマンス測定 2013 / May / 24 Uchida Spectrum, Inc. Product Management Office (PMO)

2 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-2 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. Carrot 2 : 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.

3 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-3 1. 当セッションの狙い 本書の目的 このセッションでは， LucidWorks Search （以下，「 LWS 」 と略記） の キャパシティ推算における事前ベンチマーキングの重要性を理解することと， パフォーマンス系統計情報を取得する為のツール群に どのようなものがあるか を理解することを狙いとします。 本書の対象者 本書は，以下を対象の読者と仮定して記述されています： 情報インフラストラクチャー担当者 LWS 管理者 本書の目標 本書の内容を理解および実践することにより，読者は以下を達成できるようになるこ とが 目標です： キャパシティ推算には事前ベンチマーキングが必須であることを説明できる。 メモリ割当量の算出に必要となる基礎統計情報を取得することが出来る。 パフォーマンス悪化防止の為に気を付けるべき点について説明できる。 前提条件 本書の読者には，以下を前提条件を満たしていることを仮定します： Windows または Linux の標準的なオペレーションや管理経験を有すること。 Command Prompt または Shell の使用経験を有すること。 バージョン 本書記載内容は，以下のソフトウェアおよびバージョンに対応します： LucidWorks Search 2.5.1 本書の注意点 本書は， 2013 年 04 月 01 日 現在 までに収集された情報に基づいて 記述されています。

4 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-4 2. キャパシティ推算は難しい リレーショナル型データベース等と違って，データ各件でデータ量が大幅に異なるコンテンツを 扱う特性上，キャパシティ推算値が実測値と乖離することは珍しくありません。 あくまでもキャパシティ推算値は 単なる目安の一つに過ぎず，その値が独り歩きしないように注意して 解釈する必要があります。 LWS の主たるデータは 転置インデックスに基づくことから，データ量のみならず データ値そのもの にも 大きく影響されます。 例えば，２件のデータのデータ長は同一であっても，そのデータ値を構成する語数と種類数が多ければ 消費データ容量は全く異なります。 本音で語ってしまえば，「計算上でのキャパシティ推算には然程の根拠はない」 ということです。 最良なのは，実環境のデータの全体（または一部）を用いて 実際にベンチマーキングのテスト実証を 行なうことです。 言い換えれば，事前にベンチマーキング実施なくしてキャパシティのプラニングは 意味無し，ということでもあります。 推算評価に用いるデータは，本番データであり データ量が多いほど 好ましいと言えます。 是非，事前のベンチマーク評価を御実施ください。 “ 単語数とページ数 全部で どれだけあるか 答えられますか？ ” “ これから作成しようと思いついたプログラム ソースコードが何行に及ぶか 答えられますか？ ”

5 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-5 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 の３種のみに限定 このように，各行各列のセル相当に代入される値は データ型の縛りを受けている為，容量が ほぼ一定であるか 可変であったとしても 精度や上限値が有限固定値である為に，大きな変動要素には成りません。 従って，テーブル構造とデータ件数さえ判明すれば，凡そ容量を推定することが可能です。

6 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-6 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 導入時に，ディスクを何台搭載すればいいか，厳密な解をはじき出したうえで装備されましたか？ おそらく，殆どの方は 答えをお持ちでなかった筈です。

7 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-7 2-3. 事前予測は難しいものです... 例えば Zip Format の圧縮ファイル。 あるファイルやディレクトリ配下を圧縮する時，事前に「圧縮したら どの程度の大きさになるか」を 高い精度でサイズ予測するは可能でしょうか？ 「そんなのデータ量や内容に依るでしょ」と答える方が 殆どだと思います。 つまり，そういうことなのです。

8 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-8 2-4. 検索エンジンの場合は 更に難解です... 検索エンジンの場合は， RDBMS や File Server と比較して，容量推算は 更に難しくなります。 その理由は複数ありますが，ここでは代表的なものを２つ説明します： データ型やデータ長の制限が緩い 転置インデックスの生成ロジック 検索エンジンは そもそも，長大な文字列が与えられた時に，特定の語句を持つドキュメントを 迅速に探し出す為に作られたソフトウェアです。 従って； データ長を厳格に束縛する「精度」や「最大長」について，制限が緩い または 制限が無い。 文字列をハンドリングすることが元来の狙いである為，用意されるデータ型の種類は多くない。

9 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-9 形態素分解方式 n -gram 方式 2-5. 転置インデックス（ Part-1 ） 検索エンジンの役割は，与えられた文字列を オリジナル元データ として，これを材料として 一定文字列 に分断化し， その切り出された一定文字列の個々が，「どのドキュメントで」「何回」「どの箇所に」出現したか の索引を作り出すことです。 これを 「転置インデックス」（ Inverted Index ）と称します。 オリジナル元データの文字列から，一定文字列の断片に切り出す方法は 数種類ありますが，代表的な手法は 以下の２つです： Morphological Tokens 形態素解析を施して，言語的に意味を成す 最小の部分文字列 （一般的には 品詞レベルに細分化）へ分割する n -gram Subsequence n 文字から成る 部分文字列パターンを 全て求める 上記の「一定文字列」（ Token または Subsequence ）から，それが 「どのドキュメントで」「どの箇所に」存在するか の索引を生成します。 これが検索エンジンにおける「インデックス」の正体です。

10 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-10 n -gram 方式 n -gram 方式 n 文字毎に切り出した Subsequence を Term とする 形態素分解方式 言語学的に意味のある最小の 品詞レベルである Token を Term とする 2-6. 転置インデックス（ Part-2 ） 検索エンジンで用いられる転置インデックスは， RDBMS で数多く採用されている B-Tree Index や Hash Index 等とは かなり構造や特性が異なるものです。 転置インデックスを採用することで，高速な検索が可能となっています。 身の回りにある例ですと，百科事典などの巻末にある「見出し語による索引」が 転置インデックスの考え方に似たものとして挙げられるでしょう。 転置インデックスの生成

11 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-11 2-7. 転置インデックス（ Part-3 ） ある小説本で，「私」という語は どのページの どの箇所に 合計何回 出現するでしょうか？ また，「私」以外に 何種類の単語が 当小説には使用されていますか？ それら個々の単語の出現位置は どこでしょう？ おそらく小説家本人でさえ，そんなことは判らないでしょうし，それを意識して執筆していないでしょう。 コンテンツの 件数は？ コンテンツの 件数は？ コンテンツ内に 出現するトークンは 何種類？ コンテンツ内に 出現するトークンは 何種類？ コンテンツ内に 存在するトークンは どの箇所にある？ コンテンツ内に 存在するトークンは どの箇所にある？ このトークンが 登場する箇所を 全部洗い出すと？ このトークンが 登場する箇所を 全部洗い出すと？ 各トークンの 登場回数と分布は？ 各トークンの 登場回数と分布は？ 各トークンを 圧縮すると何バイト？ 各トークンを 圧縮すると何バイト？ Lucene におけるデータ 格納アルゴリズムは？ Lucene におけるデータ 格納アルゴリズムは？ このトークンは 全コンテンツからみて 平均出現回数と分散は？ このトークンは 全コンテンツからみて 平均出現回数と分散は？ 各トークンの 長さは？ 各トークンの 長さは？ 理論上は計算できなくもないのでしょうが， おそらく このような作業を行なうだけの手間と時間を掛ける 間に，とっくにコンテンツはフィードできてしまっている ことでしょう...。 もうフィードが完了して サイズも時間も測定 できちゃってるんですが？もうフィードが完了して できちゃってるんですが？

12 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-12 2-8. 結局のところ... キャパシティやパフォーマンスに影響を及ぼす因子が余りにも多岐に渡る為， 事前計算で推定することは実質的に不可能です。 実際にデータを流し込んでみて，どのような結果となるかを観察し その考察結果から類推するしかないでしょう。 Lucene/Solr のコミッターでさえ，「どの程度のサーバ台数やディスク容量が必要になるでしょう？」 と質問されても 「さぁ.... 」 としか答えられないものです。 事前推算したいのであるならば ベンチマーク測定は 絶対に欠かせません！

13 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-13 3. ベンチマーク測定結果を読み取るうえでの注意 単発の測定に終わらせない 単発の測定に終わらせない 一回限りの測定では，偶然性や 「たまたま」の可能性を排除し切れません。 同一条件下で複数回の測定を実施し，反復結果から平均およびムラやブレを読み取ることが必要です。 単一条件の測定に終わらせない 単一条件の測定に終わらせない 条件固定のまま複数回の測定を行なっても，どの因子が どのような影響を齎すかが 見出せません。 特定ファクターを微かに変更してみて，相対的な比較を行なうことが必要です。 これにより，そのファクターの影響度合や波及内容を推定することが出来ます。 測定シナリオに一貫性を持たせる 測定シナリオに一貫性を持たせる あれやこれや と 無計画なパターン測定を何度も行なっても，有意ではありません。 複数回の測定は大切ですが，目標と仮定を確定したうえで 測定を行なうことが重要です。 測定結果から類推するうえで 無根拠な仮定を勝手に設けない 測定結果から類推するうえで 無根拠な仮定を勝手に設けない 条件を変えた複数回の結果を材料として，「おそらくこうなるだろう」と類推する際に使うロジックは それが妥当であると説明できる根拠が無ければなりません。 例えば 「 100 万件をフィードするのに 1 時間を要した」 から 「 1000 万件のフィードは 10 時間だろう」 と考えがちですが，ここでは「プロポーショナルに比例である」という暗黙の仮定が潜在しています。 しかし，プロポーショナルに比例する，という根拠は何なのでしょうか？ 本当に比例関係にあるのでしょうか？ その裏付けは？ 自分で勝手に「そうである」と自己催眠かけていませんか？

14 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-14 3-1. 測定を複数回実施したこと自体に満足しないこと 『 条件 k の時に 統計量 v が得られたのだから，条件が 10× k の時は きっと 10× v だろう... 』 それは “ 適切 ” な考え方ですか？ そのロジックに ” 根拠 ” が有りますか？ O 索引付け処理時間 CPU クロック O インデックス容量 コンテンツ件数 O 検索レスポンス時間 サーバ台数 O コンテンツ転送速度 フィード経過時間 O GC 継続時間 運用時間 何でも正比例する.. と仮定して考えることは危険です。 十分に複数回の測定を行ない観測ポイント数を増やすことで 線形なのか 指数関数的か 対数関数的か それとも 非規則的か 誤った類推を冒すリスクを減らすことが出来ます。 ※ ※ ここに表される図は正解である保証はありません。 あくまでも 「このようなケースがありうる」一例として ここでは解釈してください。 一回ポッキリの測定では，傾向については 何も読み取ることができません。 O コンテンツ件数 運用時間

15 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-15 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

16 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-16 “Capacity Planning” や “Performance Tuning” と 一言で指し示すことは往々にありますが， 具体的に どのメトリクスを どの程度 追求したいのでしょうか？ それが曖昧では，何のためにベンチマーキングを行なうのか，どのようなベンチマーク測定すべきか， その結果をどの様に活かそうとしたいのか，テーマが漠然としていて有意義ではありません。 4. どこにフォーカスするべきか？ MetricsExample Data Volume ３億件をインデクシングすることが目標である。 与えられた環境で何件まで保持できるかを測定することが目標である。 Data Feed ３億件をフィードすることが目標である。 幾つかのフィード手法を実証確認することが目標である。 Feed Rate ３億件を５日間でフィードすることが目標である。 平均フィード速度を測定することが目標である。 Query Response Time ある特定のクエリーを発行した際に，結果セットが返送されるまでの 処理時間を測定することが目標である。 Concurrent Query ある特定クエリーを複数同時並行で投下した際に，どの程度の 同時クエリー数を処理することが出来るかを測定することが目標である。 Redundancy システムダウン時でも，予備の系統で可用性を持つことが出来る。 主系統を切り離しても，別系統でサーチできることを示すのが目標である。 これから実施する測定目的を，どの「主題」を実証あるいは推算するためのテーマとしますか？  どこに / 何を 主題 / 狙い としますか？  あれもこれも.. と 多くを同時に望むことは出来ません。  Trade-Off 関係 にある相反する目標を 同時に追求しないこと。

17 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-17 4-1. 期待結果 と 実測結果 期待結果 実プロダクション環境が完成した暁における ； 最大コンテンツ件数 最大コンテンツ容量 同時並行クエリー数 クエリー応答速度... etc 実測結果 ベンチマーク環境における実測値 ： コンテンツの件数と容量 並行クエリー数 クエリー応答速度... etc ベンチマーク環境 ベンチマーキング時に使用した環境と構成： ハードウェア ソフトウェア 各種設定 サーバとシステムの全体像および構成 （ Farm, Toplogy ） データソースとコンテンツ リソース使用状況 処理時間... etc ベンチマーク結果 から導出される 課題や問題点 期待する改善点や希望する性能 実測値と期待値との乖離度合

18 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-18 4-2. 測定環境 と 本番環境 との ギャップ 【 測定環境 】 以下は，どこまで同質に揃えられますか？ サーバ台数 サーバのスペック トポロジー （ InSight を LWE Server から追い出すかどうか） データ （件数や特性など ， 本番データそのものかどうか） ベンチマーク環境 と 本番環境 の システム構成，トポロジー，リソーススペック等が 余りに乖離し過ぎていると， それらの乖離因子が 測定結果の活用価値を 打ち消してしまいます。 ベストなのは 測定環境と本番環境が同一であり，測定に用いる対象データも実データそのもの自体であることですが， それが難しい場合には 極力近しい条件に揃えることが肝要です。 【 測定精度 】 以下は，どこまで追い込みますか？ 測定回数 パラメータ固定のままで，反復測定 （バラツキやムラを軽減し平均を採る） パラメータを一つずつ変えて測定 （パラメータ変動特性を観察する） 一回二回程度の測定から 確度の高い精緻な結果と傾向や特性を 読み取ることは不可能です。 パフォーマンス追求やキャパシティ推算の目標目的に最適なベンチマーキングを 複数回 何度も何度も実施したうえで，統計量や傾向分析を行なうべきです。

19 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-19 4-3. 測定結果 の 本番環境 への フィードバック ベンチマーク環境と測定データの準備 ベンチマーキング （測定） 実験結果の可否 追求目標とベンチマーク目的の策定 統計量の分析と結果導出 プロダクション実環境 構築への助言 プロダクション実環境モデルの見直し プロダクション実環境の手配と構築 測定結果からプロダクション実環境に対して 「何をどうしておく必要があるか」が判明しても， その助言内容を構築環境に対して反映できなければ，何の意味もありません。 必要条件を基準として測定した結果，どうやらサーバは少なくとも 10台は必要みたい ですよ？必要条件を基準として測定した結果，どうやらサーバは少なくとも ですよ？... 。 そうおっしゃられても統計データの結果が結果ですし。で，どうするんですか？どうしたいんですか？ そうおっしゃられても統計データの結果が結果ですし。で，どうするんですか？どうしたいんですか？ サーバは2台しかないんです。 サーバは2台しかないんです。もう変えられないんです。でもデータは削れないし 開発期間は後2ヶ月しか...。 サーバは2台しかないんです。 サーバは2台しかないんです。もう変えられないんです。でもデータは削れないし 開発期間は後2ヶ月しか...。 分析結果を受けてプロダクション環境に対して それを適切に反映させることが出来ないのであれば， 残された策は余り有りません。 不足や不適切な箇所を調整できないならば，言えることは 「 出来るかもしれないし 出来ないかもしれない。 イエスかノーだけです。 出来なかったとしても それを受け入れるしかないですね... 。 変えることは出来ない と おっしゃっている以上，どうしようも... 。」 だから早い段階で正しいベンチマーキングを適切に実施されていれば よかったのに... だから早い段階で正しいベンチマーキングを適切に実施されていれば

20 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-20 4-4. 期待値 ベンチマーク結果 が 期待値 に届かなかった場合  何を変えることで 期待値に漸近できうるのか  何を「変えることは出来ない与件」「変えることが許容される」とするのか コンテンツの件数 コンテンツの容量 サーバ台数 サーバのスペック トポロジー フィードの仕方 クエリーの仕方 構成ファイルと各種パラメータ... etc

21 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-21 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 (Distributed Index/Search) VM No (Physical Dedicated Servers) JDK Sun/Oracle HotSpotVM JDK 7u11 (x64, Multilingual) Data Source Relational Database 【例】【例】 コンテンツ件数 フィード件数 n （ Document ） コンテンツ容量 総コンテンツ容量 m （ MByte ） 評価対象 クエリー送信から結果セット受信までの処理時間 クエリー式 q=*:* 期待値 Query response Time : s (Sec) テスト結果 Query response Time : t (Sec) 考察結果 期待する値より k (Sec) 長い どのような環境と状況下において 何を主体とした時に いかなる処理を発行すると どういった結果が得られたのか

22 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-22 5. コンテンツのフィードに関するベンチマーキング Data Source Statistics File 1. 平均サイズ （中央値サイズ） 2. 最大サイズ 3. ファイル数 4. File Format （ MIME-Type ）の種別と内訳 5. 代表的なサンプル例となるファイルそのもの（数十数百個） 6. 抽出する File Properties/Metadata と Shema Field Mapping Database 1. 結果セットのデータ行数（レコード件数） 2. 結果セットを構成するカラム（列）の個数 3. 結果セットの各カラムに関する属性定義情報（ CREATE TABLE 文） 4. 文字列データ値カラムに含まれる実データの平均サイズ（中央値サイズ） 5. 文字列データ値カラムに含まれる実データの最大サイズ（最長データ） 6. 代表的なサンプル例（ CSV/Excel Format で 数百件程度を出力したもの） 7. Resultset Columns と Schema Fields の Mapping

23 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-23 5-1. フィード期間中のリソース状況 SequenceTimepoint 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 の 値 と 変動 フィードしたコンテンツの ドキュメント件数 フィードの 所要時間

24 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-24 5-2. データ変更 InsertUpdateDelete 実行タイミング（規則性，随時 / 定時） 実行頻度 （何時間おき，何日毎） 推定データ件数（平均，推定） フィード所要時間（平均，最大） データ変更後に気になる点があれば，記録を残しておいてください： ディスクの消費サイズ増大 RAM 消費容量の増加 クエリー応答速度の低下 同時並行クエリー数の低減 データの完全洗い替え （全データ丸ごと削除して投入しなおす）

25 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-25 6. クエリーに関するベンチマーキング クエリー 結果セット （件数，フィールド数，出力サイズ） クエリー応答時間 （ Query Response Time ） 同時発行クエリー （ Concurrent Query Connections ） フィードしたコンテンツの ドキュメント件数 と 所要時間 RAM Free Space CPU Busy Rate  クエリー開始前  フィード完了後

26 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-26 7. 代表的な構成ファイルとパラメータ（ Configuration Files ） File NameFull 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

27 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-27 8. ベンチマーキング実施の準備 データソースを決定するデータソースを決定する データソースを 分析 ザックリ感はあるがエイヤ！で決めてラフにベンチマーキングザックリ感はあるがエイヤ！で決めてラフにベンチマーキング 構成のラフな見積もり構成のラフな見積もり プロダクション環境を意識したベンチマーキングプロダクション環境を意識したベンチマーキング プロトタイピングプロトタイピングコンテンツと取得データの確定コンテンツと取得データの確定フィーチャ策定パラメータ設定フィーチャ策定パラメータ設定マシンと環境の手配と準備マシンと環境の手配と準備 システムの作り込みをカッチリと完成させてからベンチマーキングすればよいでしょうが このようなタスク直列化では 工期が長大化してしまいます。 デザインや設計のフェーズを行なっている最中に，別スレッドでベンチマーキング過程に 着手してしまうことが 検討されます。 Lucene/Solr/LWE/LWS は Java Application として作られている為， OS Process としての観点 および JavaVM としての観点 の２観点から 監視と測定を実施することになります。 従って， Java Application の Monitoring Tools および Performance Tuning Technique を 適用することになります。

28 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-28 8-1. 留意点 JVM Heap は 少なすぎても 多すぎても いけない JVM Heap は 少なすぎても 多すぎても いけない 無論，ベンチマーキングしてみなければ 適切量が どの程度かは判らないものですが， 凡その目安として， JVM Heap には 8 ～ 16GB 程度をスタートポイントとして開始してみてください。 少なすぎれば， OutOfMemory Error などメモリ不足によるエラーが発生します。 大きすぎてもいけません。 Operating System や その他のプロセス に影響が出るほど JVM で占有してはいけません。 搭載物理メモリ量のうち，数 GB 分 は 必ず OS 用 に残しておいてください。 -Xms は必要最小限に設定し， -Xmx は上記に留意しつつ 大きな値を設定してみて，ここから試行錯誤していきます。 一般的に -Xmx の初期設定値は，搭載物理メモリ量の半分程度あたりでスタートしてみると良いでしょう。 RAM を潤沢に搭載しておけばよい というものでもない RAM を潤沢に搭載しておけばよい というものでもない JavaVM に沢山のメモリ空間を割り当てておくことで，メモリ不足エラーを回避できる確率は 確かに高まるでしょう。 しかしながら，余りに巨大な空間をアサインすると， Garbage Collection （ GC ）発生タイミングでは 処理時間が長大化する（ Java Objects の破棄や整理する容量と個数が多量化する）ため，かえってパフォーマンス低下 を招く可能性もあります。 JVM にアサインする空間は通常，多くても 32 ～ 64GB 程度 でしょう。 これよりも多くの空間を必要とする場合には， マシンを超ハイエンド化するのではなく，サーバ台数の増強 すなわち MultiShard 構成 を検討してください。 JVM Options Parameters を 最初から駆使調整しない JVM Options Parameters を 最初から駆使調整しない Solr コミュニティの コミッターや巨大システム管理熟練経験者も指摘していることですが，最初から JVM オプションを アレヤコレヤと手を出して弄ることはしないでください。 一般経験則として 殆どの場合，デフォルトのままで使う ことの方が マニアックな調整の果ての結果よりも 素直で良かった，という声が寄せられています。 まずは Xms / Xmx / Xmn あたりからスタートしてみて，八方塞り的状況になってきた暁に 初めて その他パラメータを 調整することを検討する... というスタンスで臨んでください。 一発で「正解」が出るものではない 一発で「正解」が出るものではない 既に解説済ではありますが，一発で正解が出るものではありません。 そもそも「正解」というものは ありません。 あるのは，実験した結果に基づく「妥当点」です。 メモリ割り当て量が不足していれば，途中でメモリ不足エラーが発生し，「やりなおし」が発生することでしょう。 かといって最初から大きすぎる値を設定していても，「より好ましいポイント」からは外れている可能性もあります。 Try-&-Error で 何度も試行錯誤しながら，妥協点を探り出す努力が必要です。

29 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-29 8-2. スタートポイント 搭載メモリ（ RAM ）は サーバあたり 約 24 ～ 32GB 程度をミニマム開始点とする 搭載メモリ（ RAM ）は サーバあたり 約 24 ～ 32GB 程度をミニマム開始点とする コンテンツの特性や件数など多岐の要素に依存するので 一概にメモリ量をドンピシャで算定することは出来ませんが， 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 を複数インスタンスで共有するような仮想環境では，ここがボトルネックとなって しまう懸念があります。 大規模構成運用管理者やコミッターの多くも，仮想環境を積極的には推奨しておらず， 独立した物理サーバを複数台用意し構成することを実践しています。 仮想環境で動作しない訳ではありませんが，開発環境やテスティング用途に限定活用することが望まれます。 SAN/NAS は推奨しません SAN/NAS は推奨しません 前項のように 検索エンジンは 著しい I/O-Bound な性向を有する為，一般的に推奨されません。 仮想環境同様，動作しない訳ではありませんが，弊社としては推奨しかねますので 自己責任でお使いください。 SSD については 耐久性が未知数要素ではありますが 最近は改良されつつあり，バックアップを高頻度で取得する 運用実施が前提であるならば，パフォーマンス向上やボトルネック化回避のために 検討してみてもよいでしょう。 JDK によって挙動は異なる JDK によって挙動は異なる 最もよく採用されているのは， Oracle 社（旧 Sun Microsystems 社） 提供の HotSpot JVM ベースの JDK でしょう。 他には OpenJDK, Oracle JRocket, IBM JDK for Power 等々 が 提供されています。 Java は策定仕様上で 実装については任意とする点もありますので，必ずしも これらで挙動やメカニズムが同一である訳ではありません。

30 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-30 9. 監視の視点 LWS を監視する場合，以下の視点からウォッチする必要があります： Operating System 環境下 Java VM で動作する Java Application として 検索エンジンが用意する各種パラメータ指定での動作として コンテンツのフィード（登録，更新，削除，反映化） クエリー 運用 （ダウンタイム，メンテナンスの内容とスケジュール等）

31 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-31 10. Windows Platform における標準パフォーマンス測定ツール Operating System の観点から CPU/RAM/Disk/Network 等を監視します： Task Manager （ taskmgr ） Performance Monitor （ perfmon ） typeperf ユーティリティ

32 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-32 10-1. 起動とともにメモリ空間は一定量が占有される 搭載物理メモリ量 OS Services Applications LWE 起動開始 LWE 起動中 LWE メモリ消費分 LWE 停止 追加消費分の為の余剰空間 （ OS が必要とする分も含む） メモリ消費量の確認コマンド PlatformCommand Windows Windows tasklist, typeperf 等 Linux Linux free, procinfo, ps, vmstat, dmesg 等 Operating System それ自体の 作業空間の確保の為に， 常に 数 GB 程度 （例えば 約 8GB ） 必ず未使用空間としてキープ してください。 全メモリ空間が消費されるような 状況には追い込まないでください。

33 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-33 10-2. Task Manager （ Microsoft Windows ）

34 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-34 10-3. Performance Monitor （ Microsoft Windows ）

35 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-35 10-4. typeperf ユーティリティ Microsoft Windows Performance Monitor と同様に Objects/Counters をモニタリングして統計情報を 収集しますが， Command Prompt から実行し，測定データを容易にファイル出力することが出来ます：

36 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-36 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 を対象として 記載しています。

37 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-37 11-1. JVM メモリ空間 JavaVM で使用する メモリ空間 JVM 固有領域 Operating System 固有領域 DefNewTenured PermanentC HeapStack … EdenSurvivorFromTo Java Heap / New / Nursery Old 単一のアドレス空間 Eden と Survivor を併せた DefNew 領域は， Young 領域 New 領域 Nursery 領域 Young 領域 / New 領域 / Nursery 領域 と呼ばれます。

38 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-38 11-2. Java Application 運用時 における 考慮点 Java Application を 安定的 かつ 良好なパフォーマンス を維持しながら継続実行を可能ならしめる為には， 以下のようなポイントに考慮して，リソース資源の割り当て や チューニング を意識しなければなりません： ScavengeGC の発生が，過度に続かないこと。 ScavengeGC の発生が，過度に続かないこと。 ScavengeGC 自体は悪いことではなく 恒常的に発生するメカニズムですが，余りに頻発化が連続するようであれば， Eden 領域 が根本的に不足している可能性も疑うべきです。 FullGC の発生は，低頻度であること。 FullGC の発生は，低頻度であること。 FullGC 自体は Garbage Collection の一つとして Java で規定されたメカニズムですが， Stop-The-World 現象 として アプリケーションの無応答期間を生み出すことになる為，発生頻度が少ないに越したことはありません。 New 領域（ Eden 領域＋ Survivor 領域） から Old 領域（ Tenured 領域） への 短命オブジェクトの移動 の 頻度と容量 を 毎回抑えることが出来れば， Old 領域のクリーンアップ すなわち FullGC を軽減化できます。 つまり， Java Objects が Old 領域 から New 領域 へムーブされる前に， New 領域内で 早々に掃除してしまうことが望まれます。 参照期間が長い長寿オブジェクトが多い Java Application を走らせるのであれば，事前に Tenured 領域 を大きく確保しておきます。 OutOfMemory Error が発生しないように，必要なメモリ空間を Java VM に割り当てること。 OutOfMemory Error が発生しないように，必要なメモリ空間を Java VM に割り当てること。 OutOfMemory Error は， New / Old / Permanent / C Heap / Stack いずれかの領域 における 必要量に対する不足 を起因 として発生している可能性があります。 StackOverflow Error が発生しないように， Stack 領域 のサイズを適切な量にまで拡げておくこと。 StackOverflow Error が発生しないように， Stack 領域 のサイズを適切な量にまで拡げておくこと。 不必要に大きなメモリ空間を Java VM に割り当てないこと。 不必要に大きなメモリ空間を Java VM に割り当てないこと。 New 領域 が大きすぎると， ScavengeGC 発生時の処理時間が 長くなってしまい，パフォーマンスが低下します。 Old 領域 が大きすぎると， FullGC 発生時の処理時間が 長くなってしまい，アプリケーションの凍結状態期間が長大化します。 Operating System や Paging を妨げるほどの JVM メモリ割り当て量 は，本末転倒です。 Java VM へのメモリ割り当て量が 小さすぎれば GC 頻発化 や 領域確保失敗 を誘発するので問題ですが，多すぎても逆効果です。 Java VM にアサインするメモリ量は，少なすぎても 多すぎても 良くない。 Java VM にアサインするメモリ量は，少なすぎても 多すぎても 良くない。 リソースを潤沢に搭載したハイエンド機を用意すれば低リスクである，という考え方は 根源的に間違っていることを 裏付けます。 適切なメモリ量 や JVM Options パラメータ設定 を行なうには，ベンチマーキングによる実証値を根拠としなければ なりません。 必要となる JavaVM メモリ量 や 搭載 RAM 量 は，事前の十分なベンチマーク測定エビデンス の他からは 算出できません！

39 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-39 11-3. LWS の JVM メモリ割り当て 文字コード UTF-8 （ Shift-JIS や EUC-JP では ありません） 改行コード LF-Only （ CR-Only や CR+LF では ありません） BOM 無し （ Byte Order Mark は 含めないでください）

40 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-40 11-4. LWS の JVM メモリ割り当て（ Continue ） Component.jvm.params = Component.jvm.params = の 式右辺 に，パラメータを記載します。 例えば， -Xms -Xmx -Xss -Xmn -XX -D パラメータ群 などを登録します。

41 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-41 11-5. LWS の 統計情報取得 LWS の起動時に，パラメータ “ -Dcom.sun.management.jmxremote ” を “ master.conf ” に 追加指定しておくことで，起動後のパフォーマンス関連情報を Probe 出来るようになります。 本書で後述する jconsole や jvisualvm 等の Instrument Utility で監視する場合に 必要となります。

42 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-42 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 コマンド を使ってください。

43 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-43 13. jconsole による LWS の モニタリング

44 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-44 13-1. jconsole の 実行例 （ Part-1 ） これらについては，然るべき理由が無いにも関わらず グラフが右肩上がりの傾向を持続するようであれば， 何らかの課題を抱えている可能性を疑うべきです。 クラス スレッド Code Cache PS Perm Gen

45 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-45 13-2. jconsole の 実行例 （ Part-2 ）フィード中の監視Eden領域Tenured領域 チューニング前 Eden Committed : 12288 KByte Eden Maximum : 12352 KByte Old Committed : 28672 KByte Old Maximum : 28672 KByte YoungGC Time : 2.342 Sec YoungGC Count : 314 Collection FullGC Time : 0.666 Sec FullGC Count : 3 Collection チューニング後 Eden Committed : 152704 KByte Eden Maximum : 327488 KByte Old Committed : 11328 KByte Old Maximum : 11328 KByte YoungGC Time : 1.570 Sec YoungGC Count : 28 Collection FullGC Time : 0.000 Sec FullGC Count : 0 Collection ScavengeGC の頻発化が 観察される ScavengeGC の 発生回数と発生間隔が緩慢化された Heap領域が 常に充満化している 短時間（20min）の間に FullGC が ３回も発生を許してしまっている Tenured(Old)領域 の 高充満率と充満回数 が原因で 高コストな FullGC を誘発している 右肩上がり傾向が持続したことが心配であったが上昇率が対数曲線状態を呈したことで懸念は低下した Heap領域 の 占有率 が低下している ここには示していませんが，同一コンテンツのフィード時間が若干短縮されたことも確認されています。

46 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-46 14. Oracle/Sun JDK における その他の標準ツール パフォーマンス関連の統計取得ツールとしては， jconsole ユーティリティ 以外にも 例えば以下のものが用意されています： jcmd ユーティリティ jinfo ユーティリティ jmap ユーティリティ jstat ユーティリティ

47 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-47 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）に同梱される これらのツールは，サポート対象外であり，且つ 将来バージョンでも 同様に提供される保証は 確約されていません。 将来の特定バージョン以降では，提供されなくなる可能性は 否定できません。

48 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-48 14-2. jmap ユーティリティ

49 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-49 14-3. jstat ユーティリティ

50 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-50 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

51 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-51 15-1. GCViewer （ Part-1 ） LWS のケースを，以下に示します：

52 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-52 15-2. GCViewer （ Part-2 ） ヒープメモリの最大サイズ（赤色） ヒープメモリの現使用量（濃青色） GCによるポーズ時間（緑色） FullGC発生タイミング（灰色） Throughput JVM 実行期間中における， GC 時間を除外した JVM 非ポーズ時間の割合です。 Throughput < 85 ～ 90% の場合は， Garbage Collection 発生がボトルネック と判断される可能性が高い為， Heap Size チューニング を検討します。

53 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-53 16. Query Log クライアントが LWE/LWS/Solr に対して どのような検索クエリーを発行したのか確認するには， Query Log File を参照することによって，それらクエリー内容を確認することが出来ます。 LWS の場合は，下記のロケーションにログが生成されます：  LwsInstalledRootDirectory \data\logs\core.request. YYYY _ MM _ DD.log LWS に発行されたクエリー群は，以下のキーワードで Find することにより 確認が可能です：  /select?q= …

54 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-54 17. Cache 検索エンジンは 大量のデータを探索したり読み書きする という点で，従来のデータベース管理システムに 似ています。 つまり， I/O が著しく高い傾向を呈する性質があります。 この為，低速な Physical Disk I/O は 回避できるならば極力避けることが望まれます。 LWS ならびに Apache Lucene には専用のキャッシュが組み込まれており，必要とするデータが Cache つまり RAM に在れば Physical I/O アクセスを誘起してまで Disk Access を行なわずとも 用件を満たすことが出来ます。 つまり，データの探索や求めるドキュメントがキャッシュにあれば， Disk Access を回避し パフォーマンス低下を軽減できることになります。 用意されるキャッシュは，以下の通りです： ManagementConfiguration Cache Name Cache Type Lucene Lucene Cache Field Cache Solr Solr Caches 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 における標準キャッシュでは ありません。

55 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-55 17-1. LWS 管理コンソール からの キャッシュ指定 LWS 2. x の管理コンソールからは， Solr Caches 各々の キャッシュ設定を 指定することが出来ます。 設定後は， LWS を再起動してください。

56 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-56 17-2. HTTP アクセス による キャッシュ現況確認  http:// SolrServerFqdn : PortNumber /solr/ CollectionName /admin/mbeans?stats=true&cat=CACHE

57 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-57 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

58 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-58 18-1. SolrMeter （ Part-1 ） まず準備ステップとして，負荷掛けに利用するクエリーや更新内容を登録します： デフォルトでは Apache Solr に標準同梱されている お試し用の “example” を対象としたサンプル値 になっていますので，これをテスト環境に適合するように 全面的に書き直します。 文字コード UTF-8 ，改行コード LF-Only ， BOM 無し で ファイル保存してください。

59 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-59 18-2. SolrMeter （ Part-2 ） クエリー性能 単位時間あたり，どれだけのクエリーを 処理することが出来たか （ QPS ） を表示します。アップデート性能 単位時間あたり，どれだけの 更新オペレーションを達成できたか を表示します。ファイルへの書き込み Commit および Optimize 処理 に関する統計情報が表示されます。 Query History クエリーの Response Time を示します。 右側は，クエリー応答時間が長大であった 遅いクエリーの件数を示しています。 Operation Time Line 時間フレームあたりの処理所要時間を示します。 高いポイントは処理時間が長く掛かったことを示しています。

60 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-60 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 が不適切設定状態で あることを疑うべきです。

61 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-61 20. Wrap-Up ここまでで学習してきた内容を復習します： CPU RAM JavaVM ディスク（ Storage ） MergeFactor パラメータ コンテンツのフィード クエリー Commit Solr キャッシュ シャード スキーマ

62 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-62 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 で 確認できますので， ベンチマーキング時に活用すると良いでしょう。

63 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-63 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 搭載 に留めておくのが 良いでしょう。

64 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-64 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 の 各領域 の サイズと比率 を，慎重に選定すべきです。 公式や方程式で即答できるようなものでは ありませんから，日頃から挙動や統計量を観察する習慣が 必要となるでしょう。 ヒープ領域サイズは，パフォーマンスに多大な影響を与えます。

65 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-65 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 の種類差によりパフォーマンス差が観察されることがあります。

66 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-66 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 デフォルト設定は， 64 です。

67 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-67 20-6. MergeFactor LWS は，ドキュメント更新処理 によって発生するセグメント増加に連動して，発生したセグメント群を 単一セグメントに纏め上げる処理をバックグラウンドで行ないます。 セグメントは複数個のファイルの セットとして定義されており，各セグメントは論理的にインデックスの一部分を形成します。 これら複数セグメントを単一セグメントに纏め上げることにより， LWS のデータファイル数を 減らすことが出来ます。 クエリー処理を担当する IndexerSearcher は，セグメント単位でロードします。 従って， クエリー観点からすると，インデックス構造体を構成するセグメント数は，少ない方が有利 となります。 一方，特定セグメントが参照されている最中に ドキュメント更新処理が発生すると，その更新データは 別の新規セグメントに保持されることになります。 従って，コンテンツフィード観点からすれば， セグメント数を多く保持できるほうがブロックさずに済むことになります。 セグメントのマージ処理は，セグメントを構成するファイル内のデータ群を 新規ワンセット分の セグメントに整理したうえで書き戻すようなものなので， Disk Access （物理 I/O ）が多発します。 つまり，マージ処理が行なわれている最中は，ディスクへの負荷が極めて高くなります。 MergeFactor 値 は，以下のファイルで設定します：  LwsInstalledRootDirectory /conf/solr/cores/ CollectionName /conf/solrconfig.xml デフォルト設定は， 10 です。 Index Optimize は， MergeFactor=1 にセットして，インデックス構造体を 単一セグメント（または 最少数セグメント群）へとその時点において 纏め上げる ことと同等である，と考えることが出来ます。

68 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-68 20-7. MergeFactor （ Continue ）

69 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-69 20-8. Contents Feed LWS が単位時間あたりにインデクシング処理できる能力は有限である為，更新速度や更新処理時間を 短縮する決め技は有りません。 IndexerWriter によってインデックス更新（ Insert/Update/Delete ）が行なわれている最中に クエリー要求が受け付けられると，新規の IndexSearcher インスタンスが起動されてしまい， メモリ消費量が一気に増加します。 また， IndexerSearcher への Warm-Up も行なわれる為， クエリーの初回レスポンスは低下します。 従って，コンテンツ更新を行なっている期間中は，クエリーが発行されることを抑止できると良い でしょう。 更新期間と検索期間が重ならないように出来ることが好ましい，と言えます。 MultiShard 構成 の場合，各シャード単位でコンテンツ更新を行なうことは可能です。 従って，各シャードへのフィードを全シャード同時並行的に進めても構いません。 但し，どのコンテンツを どのシャードに送り届けるかは，作業者側が決定しなければなりません。 また，コンテンツを一意に特定する識別子フィールドの値は，コンテンツ間で重複しないように 一意かつ非空な値をセットしておくことも，作業者側の責任となります。 一回あたりのフィードでインデクシングするコンテンツ量は，少ないことが好まれます。 また，一回あたりのフィードで掛かるインデクシング所要時間は，短いことが好まれます。 大量データフィードや長時間フィードを行なう場合には，これを複数回フィードに分割してください。 一回のフィードで転送するデータの件数やサイズが多いと，著しいメモリ消費量とメモリ非解放が 発生しまいます。 フィード継続期間中にコミット処理を発行すると，フィード中 と コミット分の IndexerWriter が 同時発生してしまい，著しいメモリ消費が発生してしまいます。 インデックス更新処理期間中のコミットは抑制するか最小限度に留め，フィード完了時に纏めて コミットすることを 検討してください。

70 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-70 20-9. Query IndexerWriter によってインデックス更新（ Insert/Update/Delete ）が行なわれている最中に クエリー要求が受け付けられると，新規の IndexSearcher インスタンスが起動されてしまい， メモリ消費量が一気に増加します。 また， IndexerSearcher への Warm-Up も行なわれる為， クエリーの初回レスポンスは低下します。 従って，コンテンツ更新を行なっている期間中は，クエリーが発行されることを抑止できると良い でしょう。 更新期間と検索期間が重ならないように出来ることが好ましい，と言えます。 MultiShard 構成 の場合，各シャード単位でクエリー発行を行なうことは可能です。 例えば，年度別にシャードが区分化されている場合（例えば，第 n シャード は 201 n 年 のデータを保持） 特定年度のデータだけに対してクエリーを発行したいならば，全シャードにではなく その年度シャードのみへクエリーを発行する，といった効率的利用が考えられます。

71 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-71 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 は最速で数十秒に一回 の間隔をとります。 実際には，より緩慢なペースで動作させることを検討してください。

72 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-72 20-11. Solr Cache Solr の優れたクエリー性能は，キャッシュの効果的活用を前提としている面もあります。 キャッシュを有効に利用するようクエリー構文やクエリー発行順序を意識できると良いでしょう。 非決定的関数（例えば NOW 関数）をクエリー構文内に含めると，キャッシュ活用が出来なくなります。 NOW 関数の場合は，刻一刻とマイクロ秒単位で変化する日時時刻値を返す為， 前クエリーと後クエリー では NOW 関数の戻り値が同じになりません。 但し，戻り値を日単位や時単位に丸めるのであれば クエリーを活用できる確率が高まります。 キャッシュ空間は， JavaVM ヒープ領域内の一部として確保されます。 従って，キャッシュ空間サイズを大きくすれば ヒープ空間を圧迫します。 キャッシュ空間を拡張する場合には，ヒープ空間も併せて領域拡張すべきかどうか 慎重に検討してください。 キャッシュの Eviction Rate が高い ということは，キャッシュ内に残存していたオブジェクトが 後発で流入してきたオブジェクトに追い出されて破棄されてしまう頻度や回数が高い ということです。 キャッシュに残存し続けることが好ましいと単純化できるものではありませんが，レートが常に高め である場合には，キャッシュ空間サイズを広げるべきではないか ということを考えてみてください。 但し，キャッシュに残存している価値がない為に追い出された，という理由で Evict しているケースも ありますので，この場合はキャッシュに留める意義が小さいということで むしろ キャッシュ空間を 小さくした方が良いことになります。 キャッシュに対する Lookup や Hit Ratio が低い ということは，キャッシュが有効活用されていない 可能性を物語っています。 領域を小さくすることを検討してみてください。 あるいは利用率が低いなら いっそのことサイズを０にセットして使わせないことも検討できます。 キャッシュ空間を廃止すれば，その分だけヒープ領域を解放することができます。

73 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-73 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 の リソースやスペックは やや高めのもので用意すると良いでしょう。

74 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-74 20-13. Schema 定義するスキーマ内容が複雑あるいは多量であるほど，パフォーマンスに悪い影響を与えます。 以下に該当するようなケースでは，その機能の使用を回避し 捨て去るように英断することも大切です：  使うかどうか判らない...  今は不要だけど，もしかしたら将来時には必要になるかもしれない...  使うことはあるのかもしれないけど，日常的ではないし，利用といってもマイノリティーだろう... 恒常的に大多数のユーザが必要する機能以外は，奇麗サッパリと捨て去る勇気は必要です。 以下の Features は 極力採用を抑制し，使用を回避してください：  ソート（並び替え）  ファセット（ドリルダウン）  ジョイン（結合）  STATS （集計統計量算出）  ハイライト（ヒット箇所の特定化）  ベクトル（スコアリング）  Geo-Spatial （緯度経度情報に基づく距離空間クエリー） 上記はリソース消費や演算処理にパフォーマンス観点でネガティブな影響を与えますので，なるべく 使わずに済むなら使わないように工夫してください。 使う可能性が捨て切れないから 盛り込んでおこう，という発想は好ましいものではありません。 小さいことは良いことです：  定義するフィールドの数は，極力少なくする。  冗長あるいは予備のフィールドを持たせない。  データソースにアクセスできるならば， LWS 側に値を持たせない （ Store Fields を作らない）  フィールド値を別フィールドにコピーしない （ Copy Fields を作らない）  フィールドに格納する値は，極力 小容量のコンパクトな値とする （長い文字列を保持しない） 欲張りすぎれば 早々に破綻します

75 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-75 20-14. 検索エンジンの使命と役割 検索エンジンや LWS で「出来ること / 出来ないこと」「長所 / 短所」を理解したうえで， 既存技術や従来システム および 検索エンジン以外の新技術 と，うまく分担しあい 総合的に意義あるシステムに纏め上げることが重要です。 同じような機能を複数システムで実装することは不要であり，既存システムが実装済の機能については 検索エンジン系システムで被ってまで持つ必然性はなく，既存機能へ引き渡しすればいいだけです。 検索エンジンは，長大で多量のテキスチュアル（文字列）情報をハンドリングすることに長けています。

76 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-76 20-15. ベンチマーキング 必要なハードウェアスペックや搭載リソース量は，ベンチマーキング無くして 推算することは 不可能です。 負荷テストやメモリ割当量算出は，「うまくいった」か「エラーになった」か の 二者択一結果でしか 現れません。 エラーになれば，条件を変えて再度テストしなおしが必要です。 従って，一回や数回のテストで最適値が求まることは 有り得ません。 ベンチマーキングは長時間の計測と分析を要するものです。 また，実際にエンドユーザが使い始めてからの状況は，事前の評価時とは 予想もしない挙動や特性を 示すことも 多々あります。 従って，運用開始後のベンチマーキングも必要です。 ベンチマークフェーズは信頼できる精度ある結果を求める為に，試行錯誤や反復測定など発生します。 故に，プロジェクトの早期段階から，アプリケーション設計とは別工程で 着手開始することが 望まれます。

77 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-77 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 " " 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 " " 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 " QueryConditionForDelete " Delete By ID  curl http:// LwsServerFqdn :8888/solr/ CollectionName /update -H "Content-Type:text/xml; charset= CharacterSetName " --data-binary " DocumentIdentifierValue " 件数確認  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

78 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-78 22. Question-&-Answer Capacity Planning および Performance Tuning の２トピックに関して 何か御質問は御座いますか？

79 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-79 XXX 御清聴ありがとうございました

80 ©2012 Uchida Spectrum, Inc. All rights reserved. Page-80