Datastax Opscenterが多すぎるCPUを食べるのはなぜですか？

環境：今Datastax Opscenterが多すぎるCPUを食べるのはなぜですか？

machines : 2.1 xeon, 128 GB ram, 32 cpu 
os : centos 7.2 15.11 
cassandra version : 2.1.15 
opscenter version : 5.2.5 
3 keyspaces : Opscenter (3 tables), OpsCenter (10 tables), application`s keyspace with (485 tables) 
2 Datacenters, 1 for cassandra (5 machines)and another one DCOPS to store up opscenter data (1 machine).

ノード上のエージェントは、（可能な3200のうちの）平均〜1300のCPU上で消費します。取引される唯一のデータは、アプリケーションキースペースで〜1500w/sです。

番号表とopscenterの間の関係はありますか？エージェントは多くのメトリクスからデータを書き込もうとしているか、何らかのバグですか？

以前のバージョンのopscenter 5.2.4と同じ動作です。このため、私はまずopscenterを最新のバージョンにアップしようとしました。 OpsCenterの5.2.5のリリースから

ノート：は、 "一部のクラスタ・トポロジ上のエージェントのCPU使用率が高いとの問題を修正しました（OPSC-6045）。" 感謝

すべてのヘルプ/意見。

ありがとうございます。

出典

2016-11-21 Mr' Black

実行中にhttps://github.com/patric-r/jvmtopまたはJavaフライトレコーダーを少し実行できますか？メトリックの数はテーブルの数に依存しますが、GCやその他のサービス（バックアップ/リストア、修復）からのものでもあります。あなたはバージョン6.0.5にアップグレードしようとしますか？ 5.2.5以降、多くの改善がなされています。 –

こんにちはクリス、すぐに応答していただきありがとうございます。 –

6.0.5へのアップデートについて私はaffraidです。私はcassandra 2.1.5を使用しています。もし私が正しく覚えていれば、サポートされていません。バックアップ/リストアについては、read_repairsを除いて、フライトでは修復しません。トップランニングでは、エージェントpidがそのような高いCPU需要に責任があることが分かった。 jpsを実行して、エージェントのpidを取得し、 "jstat -gcutil pid 1000 100"を実行すると、eden（12GbヒープのG1GCを持っています）のGCアクティビティがたくさん表示されます。私はあなたが提供したそのツールでもチェックしようとしています。詳細な情報とそれから撮った画像を取得しようとします。 –

Chrisに提供した素晴らしいツールを見て、特定のエージェントのPIDにヒープ使用率が90％を超えて一定であったことが気付きました。そしてGCアクティビティがトリガされ、ほぼ1秒の巨大なGC休止が発生しました。この時間に私はプールスレッドが待っていて、自分のCPUをブロックしなければならないと思っています。とにかく私はこの分野の専門家ではない。

エージェントのヒープをデフォルト128から512のより良い値に拡大することを決定しました.GCの圧力がすべて無くなり、スレッド割り当てがうまくいっていることがわかりました。

全体的に、CPU使用率はopscenterエージェントの40〜50％から1〜2％に低下しました。そして、CPUがjmx-metricsによって消費されていることがわかっているので、私は1〜2％で暮らすことができます。

だから私のアドバイスは、ファイルを編集することです：

datastax-agent-env.sh

をし、Xmxの

-Xmx512M

のデフォルト値は128、ファイルを保存するエージェントを再起動し、しばらくの間、監視変えます。

http://s000.tinyupload.com/?file_id=71546243887469218237

再びクリスありがとうございました。

これは他の人々に役立つことを願っています。

出典

2016-11-23 09:41:47

Datastax Opscenterが多すぎるCPUを食べるのはなぜですか？

答えて

関連する問題