Mercurial > hg > Papers > 2014 > nobuyasu-master

comparison paper/chapter5.tex @ 70:26bfd74c4c41

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Added some files
author Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp>
date Sat, 01 Feb 2014 22:49:54 +0900
parents
children 4e8bfd65768f
comparison
equal deleted inserted replaced
69:4f31182c8244 70:26bfd74c4c41
1 \chapter{分散木構造データーベース Jungle の評価}
2 前章ではJungleにおける分散データベースの詳細な実装について述べた.
3 本章では実装を行ったJungleに対してCassandraとの性能比較を行い評価をする.
4 性能比較の為に簡易な掲示板プログラムをJungleとCassandra それぞれに作成した.
5 複数のノードに繋がっている状態においても性能を測りたいため, 学科が提供する
6 VMWareの並列環境を利用する. また, 我々の研究室が利用しているブレードサーバ
7 上で動いているKVMもクライアントとして利用する.
8 Jungleは永続性はなく分散だけ実装で測定を行っている.
9
10 \section{実験方法}
11 実験は同じ機能を提供している簡易掲示板プログラムをJungleとCassandraそれぞれで
12 動かし, HTTPリクエストにより負荷をかけて行う.
13 レスポンスが返ってくるまでの時間をはかり, 平均時間と標準偏差を求めグラフに出力する.
14
15 また, 実験は2つ行う.
16 まず行う実験は, 複数のクライアントから1つのノードに負荷をかける方法である.
17
18 \begin{figure}[htpb]
19 \begin{center}
20 \includegraphics[scale=0.70]{figures/cluster_request_server.pdf}
21 \caption{実験1 複数のクライアントからサーバ1台への負荷}
22 \label{fig:clients_singleserver}
23 \end{center}
24 \end{figure}
25
26
27
28 次に行う実験は複数のノードに対し複数のクライアントから負荷をかける方法である.
29 それぞれ大量のHTTPリクエストをだし, 全てのリクエストの処理にかかる時間を測定する.
30
31 クライアントの数に比例してノードを増やすことでレスポンスを維持できるか
32 スケーラビリティを調べるためである.
33 \begin{figure}[htpb]
34 \begin{center}
35 \includegraphics[scale=0.70]{figures/clients_request_servers.pdf}
36 \caption{実験2 複数のクライアントから複数のノードへの負荷}
37 \label{fig:clients_servers}
38 \end{center}
39 \end{figure}
40
41 \subsection{Torque Resource Manager}
42 並列環境下にあるマシン全てに命令を出し, タスクを実行させることは非常に大変である.
43 そのため, 今回の実験において並列環境のマシンに同時にタスクを実行させるために
44 Torque Resrouce Managerを利用する.
45 Torque はQueueによりタスクの実行順序を制御する.
46 Queueにタスクをいれる際には, そのタスクをいくつのノードで
47 実行するか, いくつのコア数を使用するかといったリソースの設定も行うことができる.
48
49
50 \subsection{weighttp}
51 最初の実験で1つのノードに負荷をかけるプログラムはウェブサーバの測定ツールであるweighttpを使用する.
52 weighttpは総リクエスト数, 同時接続数, ネイティブスレッド数をオプションとして指定することができるC言語
53 でかかれたプログラムである.
54
55
56 \subsection{掲示板プログラム}
57 今回使用する掲示板プログラムは組み込み用ウェブサーバであるJettyをフロントエンドとして利用し, バックエンド
58 に Jungle と Cassandra を利用している.
59
60 \begin{table}[!htbp]
61 \caption{簡易掲示板システムで利用したJettyとCassandraのバージョン}
62 \label{tab:bulletinboard_components}
63 \begin{center}
64 \begin{tabular}{|c||c|} \hline
65 名前 & バージョン \\ \hline \hline
66 Jetty & 6.1.26 \\ \hline
67 Cassandra & 2.0.4 \\ \hline
68 \end{tabular}
69 \end{center}
70 \end{table}
71
72
73
74 \subsection{実験環境}
75
76 \subsubsection{サーバノードとクライアントを実行させるサーバの仕様}
77 使用するVMWareとKVMのクラスタの使用を以下に示す.
78 クラスタは仕様を表\ref{tab:cluster_spec_vmware}と表\ref{tab:cluster_spec_kvm}に示す.
79
80 \begin{table}[!htbp]
81 \caption{掲示板プログラムを実行させるVMWareクラスタの仕様（クライアントにも利用）}
82 \label{tab:cluster_spec_vmware}
83 \begin{center}
84 \begin{tabular}{|c||c|} \hline
85 名前 & 概要 \\ \hline \hline
86 CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
87 Memory & 8GB \\ \hline
88 OS & CentOS 5.8 \\ \hline
89 HyperVisor & VMWare ESXi \\ \hline
90 JavaVM & Java(TM) SE Runtime Environment (build 1.7.0-b147) \\ \hline
91 \end{tabular}
92 \end{center}
93 \end{table}
94
95 \begin{table}[!htbp]
96 \caption{クライアントを実行させるKVMクラスタの仕様}
97 \label{tab:cluster_spec_kvm}
98 \begin{center}
99 \begin{tabular}{|c||c|} \hline
100 名前 & 概要 \\ \hline \hline
101 CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
102 Memory & 8GB \\ \hline
103 OS & CentOS 5.8 \\ \hline
104 HyperVisor & KVM \\ \hline
105 JavaVM & Java(TM) SE Runtime Environment (build 1.7.0-b147) \\ \hline
106 \end{tabular}
107 \end{center}
108 \end{table}
109
110 \subsubsection{ブレードサーバの仕様}
111 最初の実験ではブレードサーバ1台で掲示板プログラムを動かし, 並列環境から複数のクライアント
112 で負荷をかける.
113 ブレードサーバの仕様を表\ref{tab:server_spec_1}に示す
114 \begin{table}[!htbp]
115 \caption{サーバノードとして利用するブレードサーバの使用}
116 \label{tab:server_spec_1}
117 \begin{center}
118 \begin{tabular}{|c||c|} \hline
119 名前 & 概要 \\ \hline \hline
120 CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
121 物理コア数 & 12 \\ \hline
122 論理コア数 & 24 \\ \hline
123 Memory & 132GB \\ \hline
124 OS & Fedora 16 \\ \hline
125 JavaVM & Java(TM) SE Runtime Environment (build 1.7.0\_51-b13) \\ \hline
126 \end{tabular}
127 \end{center}
128 \end{table}
129
130 \subsubsection{Jungle実行時のJavaVMのオプションの設定}
131 サーバでJungleを実行するときは, JavaVMがデフォルトで設定しているHeapサイズの容量を
132 大きくする.
133 Jungleでは非破壊でデータを保持するため, データで使用するメモリの量が大きい.
134 JavaのHeapサイズをデフォルトのままでベンチマークプログラムを走らせると,
135 エラーの\verb|java.lang.OutOfMemoryError: GC overhead limit exceeded|が出力されてプログラムが終了してしまう.
136 このエラーはFull GCにかかる回数が多いか, プログラムの98\%以上GCに使用されていると出力されるエラーである.
137 そのため, ブレードサーバでは\verb|-Xmx20g -Xms10g|をつけ, VM側では\verb|-Xmx6g -Xms4g|のオプションを付けて行う.
138
139 \subsubsection{サーバの環境}
140 HTTPによりノードに負荷を掛ける場合気をつけることがある.
141 それはサーバの設定により最大コネクション数や開くことのできるファイル記述子の数に制限がかかっていることである.
142 この2つの値はデフォルトでは小さなものとなっており, そのままではカーネル
143 の設定がネックとなったベンチマーク結果がでる可能性がある.
144 そこで次のようにコマンドを実行することでコネクション数の制限を増やすことができる.
145 \begin{lstlisting}[frame=lrbt,label=src:maxconn_up,caption=コネクション数を増やす,numbers=left]
146 % sudo sysctl -w net.core.somaxconn=10000
147 \end{lstlisting}
148 ファイル記述子の制限を増やす場合は次のコマンドを実行する
149 \begin{lstlisting}[frame=lrbt,label=src:max_up_filedisc,caption=ファイル記述子の制限を増やす,numbers=left]
150 % ulimit -n 10000
151 \end{lstlisting}
152
153
154
155 \section{実験結果1}
156 複数のクライアントからサーバノード一台に対して負荷をかける実験を行った.
157 クライアントの数は10台から始まり5台ずつ増やしていき, 最大45台まで増える.
158 各クライアント以下のオプションをつけたweighttpプログラムが実行される.
159 \begin{lstlisting}[frame=lrbt,label=src:distributed_weighttp_op,caption=weighttpのオプション（実験1）,numbers=left]
160 weighttp -n 20000 -c 20 -t 2 -k "http://url"
161 \end{lstlisting}
162 このオプションは2つのネイティブスレッドを使用し, 同時に20のコネクションを張り, 通信の間コネクションを切らずに2万件の
163 HTTP requestを送信することを表している.
164 Cassandraはサーバノードが一台の為, Replication factor 1でConsistency LevelはONEとなる.
165
166
167 実験の結果はグラフ\ref{fig:singlenode_read_bench}, \ref{fig:singlenode_write_bench}となる.
168 横軸はクライアントノードの数を表しており, 値が増えるほどリクエストの数も増え負荷が高まる.
169 縦軸は2万件のリクエスト全てにレスポンスを返し終えた時間を表している（単位：秒）.
170
171 \begin{figure}[htpb]
172 \begin{center}
173 \includegraphics[scale=1.0]{figures/bldsv12_read_bench.pdf}
174 \caption{複数のクライアントから一台への負荷}
175 \label{fig:singlenode_read_bench}
176 \end{center}
177 \end{figure}
178
179 \begin{figure}[htpb]
180 \begin{center}
181 \includegraphics[scale=1.0]{figures/bldsv12_write_bench.pdf}
182 \caption{複数のクライアントから一台への負荷}
183 \label{fig:singlenode_write_bench}
184 \end{center}
185 \end{figure}
186 \newpage
187
188 \subsection{実験結果1の考察}
189 読み込み, 書き込みともにJungleのほうが良い結果となっている.
190 書き込みの差が大きく開いていることに関しては, Cassandraはディスクへと書きだすとき
191 もあるのも原因の1つと考えられる.
192 Jungleはオンメモリであることから, やはり差はでてしまう.
193 しかしディスクに書き出していないこととは別の要因も考えられる.
194 Jungleは非破壊的木構造なため, ロックをほとんど必要としない.
195 書き込み時においてもロックが必要なときは木のコピーをとりおえて, ルートノード
196 を更新するときのみである.
197 書き込みの速度が早いことはJungleのロックが少ないことも要因の1つとしてあげられる.
198
199
200 \newpage
201 \section{実験結果2}
202 学科の並列環境クラスタを用いて分散環境下での実験を行う
203 学科の提供するVMは48台だが, ブレードサーバ上で動くKVMから12台を利用し, 合計60台を使用する.
204 JungleとCassandraをそれぞれサーバノード10台, 20台, 30台で動かし, クライアントも10台, 20台, 30台
205 と増やして負荷をかける.
206 クライアントとサーバノードの数は1:1となるため, 横軸の値の数が増えると総リクエストは増えても
207 1台に与えるリクエスト数は変わらない.
208 縦軸はリクエストに全てに対してレスポンスを返しきった時間を表す（単位：秒）
209 KVM側はクライアント側だけに利用する.
210 weighttpに付ける引数は実験1と同じとする.
211 各クライアントから2万のリクエストを送る.
212 CassandraはConsistency Level ONEとQUORUMの両方を計測する.
213 QUORUMのReplication factorは5で設定してある.
214
215 測定は読み込みと書き込みの両方を行う.
216 測定の結果をグラフにしたのを図\ref{fig:distributed_read_bench}, \ref{fig:distributed_write_bench}に示す.
217 横軸はクライアントとサーバノードの数を表す.
218
219
220 \begin{figure}[htpb]
221 \begin{center}
222 \includegraphics[scale=1.0]{figures/distributed_read_bench.pdf}
223 \caption{分散環境下における読み込みベンチマーク結果}
224 \label{fig:distributed_read_bench}
225 \end{center}
226 \end{figure}
227
228 \newpage
229
230 \begin{figure}[htpb]
231 \begin{center}
232 \includegraphics[scale=1.0]{figures/distributed_write_bench.pdf}
233 \caption{分散環境下における書き込みベンチマーク結果}
234 \label{fig:distributed_write_bench}
235 \end{center}
236 \end{figure}
237
238
239 \subsection{実験結果2の考察}
240 こちらも, JungleのほうがCassandraにくらべて良い結果となっている.
241 %実験1の結果と比べると全体的にデータのあばれが少なくなっている.
242 %これはクライアントの数が増加してもサーバノードの数も増加するため, サーバノード一台に対する
243 %HTTPからの負荷が変わらないためだと考えられる.
244 特に読み込みに関してはConsistentcy Level QUORUMの場合と比べると3倍以上離れている場合もある.
245 実験1に比べてJungleとCassandraの差が開いているのはCassandraのConsisteyncy Level
246 がQUORUMに設定されていることが要因の1つとしてあげられる.
247 今回CassandraのReplication factorは5と設定している.
248 そのため, Consistency LevelがQUORUMの場合は, 書き込みは3つのノードに書き込まれたことを確認
249 し, 読み込みは3つのノードからデータを取得して最新のデータを返す為である.
250 Jungleの結果が横軸の値が増えても横ばいになっていることにも注目したい.
251 これはJungleの場合, リクエストが来た際に, それぞれのノードがローカルにある木の情報をすぐに
252 返すためである.
253 そのため, クライアントが増え, 総リクエスト数が増加しても一台に対する負荷が増えない限りは
254 同じレスポンス速度を維持できる.
255 %1つ気になる点としては, Cassandraは横軸の値が30のときの結果が25の時に比べて下がっている点である.
256
257
258