1

現在、ツールを使用していくつかのストレス テストを行っていabます。カサンドラでは、単一の挿入はうまくいっています。ただし、バッチ挿入に関しては、現在 Java のメモリ不足エラー: Java Heap Space に対処しています。

2Gのメモリを搭載したUbuntuサーバー13.04がインストールされた仮想ボックスマシンがあります

Cassandraの内部構成についてはよくわかりません。

サイズ100のバッチ挿入を作成しています（ に100挿入BATCH）。

このエラーが表示された後、cqlshアクセスできなくなりましnodetoolた。ほぼ 1 時間アクセスできません。

高負荷でこのエラーを修正するにはどうすればよいですか?

HTTP POST注 :リクエストによる単一の挿入では発生しません。

注: 私の列ファミリーには、TimeUUIDType のキーがあり、列の値はints とvarcharsです。

更新: テスト結果によると、6000 リクエストの前に何も問題がなかったことが示されています。ただし、7000 になると、php コードは次のようにスローします。

Error connecting to 127.0.0.1: Thrift\Exception\TTransportException: TSocket: timed out reading 4 bytes from 127.0.0.1:9160

さらに、cassandra は高負荷時に次のログを記録します。

WARN [ScheduledTasks:1] 2013-06-28 03:43:07,931 GCInspector.java (line 142) 
Heap is 0.9231763795560355 full.  You may need to reduce memtable and/or cache sizes.
Cassandra will now flush up to the two largest memtables to free up memory.  Adjust
flush_largest_memtables_at threshold in cassandra.yaml if you don't want Cassandra to 
do this automatically
4

1 に答える 1

2

バッチは、メモリの問題を引き起こすのに十分な大きさのデータセットではないように思われるため、仮想マシン上の JVM に問題があるように思えます。どのくらいのメモリを割り当てましたか?

JConsole を起動し (ターミナル/プロンプトで jconsole と入力するだけ)、「メモリ」タブ、具体的には以下の値を表示することで確認できますMax。

JVM メモリ統計


C*のスタートアップ スクリプトに含まれるXX:+HeapDumpOnOutOfMemoryErrorパラメータ のおかげで、クラッシュの原因に関する確実な詳細を取得することもできます。これは基本的に、メモリの問題を引き起こしたスタック トレースを格納するログ ファイルです。

通常、ヒープ サイズは のcalculate_heap_sizes()関数によって自動的に計算されcassandra-env.shます。ただし、MAX_HEAP_SIZE を別の値に設定することで、関数が生成した数値をオーバーライドできます。同じ変数が cassandra-env.sh の 174 行目と 175 行目で使用されJVM_OPTS="$JVM_OPTS -Xmx${MAX_HEAP_SIZE}"、最小および最大ヒープ サイズを設定します。

于 2013-06-27T14:37:54.410 に答える