分析 MobileFirst 7.1.0.00.20170505-1403 を使用していますが、分析サーバーが heapdum.phd および core.dmp の GB 単位で巨大なファイルを出力していることに気付きました。
これにより、すべての San ストレージが使用されなくなります。この巨大なファイルのダンプをオフにするにはどうすればよいですか?
分析 MobileFirst 7.1.0.00.20170505-1403 を使用していますが、分析サーバーが heapdum.phd および core.dmp の GB 単位で巨大なファイルを出力していることに気付きました。
これにより、すべての San ストレージが使用されなくなります。この巨大なファイルのダンプをオフにするにはどうすればよいですか?
ヒープ ダンプが発生する可能性が最も高いのは、Analytics サーバーに割り当てられたすべてのヒープ スペースが使い果たされたためです。これは、十分なリソースがないシステムのサイズが小さいか、ほとんどの場合負荷が高いシステムを示している可能性があります。
覚えておくべきいくつかの簡単なこと:
a) Analytics サーバーと MFP サーバーを同じランタイムにインストールしないでください。
b) Analytics エントリの TTL 値を構成して、永久に保持されないようにします。一定間隔でデータをパージする
c) ほとんどの場合、すべてのデータを Analytics サーバーに送り込む必要はありません。Analytics へのデータの流れを制御できます。例: 本番環境での使用では、Analytics に送信される (クライアントからの) イベント データの量を制限し、Analytics に転送されるサーバー ログを制限します。
d) Analytics サーバーが大きすぎるデータ ブロックをロードしようとするのを防ぐために、サーキット ブレーカーを構成します。これは Elasticsearch の設定です。
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/index-modules-fielddata.html
サーキット ブレーカーやその他の ES プロパティを構成するには、elasticsearch yml 構成ファイルを作成します。たとえば、「elasticsearch.yml」
JNDI プロパティの下の環境エントリに、このファイルへのパスを追加します。
「分析/設定パス」
例えば:
<jndiEntry jndiName="analytics/settingspath" value="/home/system/elasticsearch.yml" />