0

Cassandra 1.2.3 を 10GB の RAM で実行すると、キーの数が増えるにつれてヒープの使用量が増え続けます。現在は約 8.3G であり、ノードはタイムアウトにつながるヒープ プレッシャーを経験しています。

cfstats 出力:

Keyspace: profiles
    Read Count: 33775531
    Read Latency: 11.160335890411316 ms.
    Write Count: 146030154
    Write Latency: 0.03436538754180866 ms.
    Pending Tasks: 0
        Column Family: profiles
        SSTable count: 12
        Space used (live): 161353987766
        Space used (total): 161604490499
        Number of Keys (estimate): 162628352
        Memtable Columns Count: 69256
        Memtable Data Size: 58138189
        Memtable Switch Count: 6844
        Read Count: 33775532
        Read Latency: 13.964 ms.
        Write Count: 146030157
        Write Latency: 0.032 ms.
        Pending Tasks: 0
        Bloom Filter False Positives: 2498002
        Bloom Filter False Ratio: 0.31157
        Bloom Filter Space Used: 110145928
        Compacted row minimum size: 30
        Compacted row maximum size: 73457
        Compacted row mean size: 3508

これがヒープダンプです。

それを分析しても、ほとんど空の配列とマップがたくさんあるので、メモリ リークがあるという仮説以外にはつながりませんでした。

アイデアをいただければ幸いです。

4

2 に答える 2

0

明示的な gc が呼び出された後、ヒープは削除されますか?

于 2013-10-29T18:57:30.737 に答える
0

データをキャッシュしているように聞こえますが、JNA (Java Native Access) を使用していません。JNA を使用すると、Cassandra は O(n) 個のデータ構造 (データ セットのサイズに応じて大きくなるもの) をキャッシュを含めてヒープ外に格納できます。 このドキュメントでは、JNA のセットアップ方法について説明します。キャッシュ設定は、スキーマを定義するときにテーブル/CF ごとに構成されます。

于 2013-10-29T17:45:40.917 に答える