お世話になっております。
kibanaのDiscoverを表示したときにtimeoutが発生し表示できなくなりました。
サーバ構築当時はこのようなことがなかったのですが、
データが増えるにつれ頻発し、ここ最近では必ずtimeoutが発生しclusterのstatusがredになります。
チューニングしたら改善されるのか、そもそもハードスペックが足りないのか判断が難しいところではありますが、
まずは可能な限りチューニングを行い様子を見たいと考えています。
そこで有効と思われるチューニングの助言をいただければと思います。
よろしくお願いいたします。
● 現在の構成
■ハード(サーバにESXi導入)
CPU:Xeon E5540 2.53Ghz
mem:128GB ※別サーバが常時4台起動しメモリは約30GBほど占有
HDD:NAS 6TB
■node(ESXi上)
OS:CentOs7(64)
1nodeあたりメモリ:8GB
HDD:500GB (約5%使用済)
■elasticsearch
version:2.4.3
cluster:1
node:5(日中はlogstashからデータ受信。kibanaインストール済み。)
node:1(elasticsearch.ymlにnode.master:false、node.data:falseを設定。kibanaインストール済み)
shard:5
replica:2
■kibana
version:4.6.4
●現在の設定
/etc/sysconfig/elasticsearch
・es_heap_size=4g
・max_locked_memory=unlimited
●その他
・packetbeatで取得したhttpデータ
・kibanaのdiscoverでdefaultの15分以内のデータを検索
・packetbeat-*で日付ごとにIndex作成
・packetbeat-*のデータは2/2時点で丸2か月分
・packetbeat以外にも別indexでデータあり。
・total shardは2/2時点で1805
・1indexあたりsizeは50~300MB
・1indexあたりdocは50,000~300,000件
・検索自体は6台全てにkibanaがインストールされているが、どれを表示してもエラーとなる
・日中はlogstashから
johtani
(Jun Ohtani)
February 2, 2017, 6:35am
2
ありがとうございます。
資料を読むに原因は
・メモリが8GB未満はよろしくない
・NASを使用しているため
で、大きな原因はNASなのでしょうね。
それでもkibana検索時の下げたい場合、
不要なインデックスをCloseする
というのは有効なのでしょうか?
※今は一切closeしていない。
johtani
(Jun Ohtani)
February 2, 2017, 7:21am
4
不要なインデックスのcloseは有効ですね。
deleteの方がさらに有効だとは思いますが。
あとは、シャード数を減らしたり、インデックス数を減らすのも検討されてはどうでしょうか。
週1のインデックスなどでもいい気がします。
ありがとうございます。
まずは
・インデックスのclose又はバックアップ後にdelete
と提示いただいた
・シャード数減少(5->3程度)
・インデックス数減少(daily->weekly程度)
を変更しながら丁度いいバランスを探したいと思います。
ハードウェア周り(特にNAS)は上記で改善されなかったら検討します。
追記
色々検証した結果、表示することができました。
今までは
kibanaのsetting-indicesに
packetbeat-*を作成して直近15分のデータの表示に失敗していましたが
packetbeat-201701*を作成し、今は2月なので1月を表示するために
previous monthを指定してみたところ
時間はかかりますがtimeoutになることなく表示することができました。
追記2(17.02.02 20:00)
ノード5台の内、2台のメモリを16GB、残り3台のメモリは8GB
検索用のノード1台のメモリは8GB
2016年のインデックスをcloseしindex数が1085
この状態でpacketbeat-*に対してthis yearでの表示もできることを確認しました。
ただデータ受信が落ち着く時間帯が理由かもしれない。
system
(system)
Closed
March 2, 2017, 10:01am
7
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.