Javaリソースの調整

パフォーマンスが低下した場合やメモリー使用率が高くなった場合は、Javaリソースを調整することを検討してください。

パフォーマンスが低下した場合やメモリー使用率が高くなった場合は、Javaリソースを調整することを検討してください。

cassandra-env.shcassandra-env.ps1は、Java Virtual Machine(JVM)構成設定などのCassandraの環境設定を制御します。

ヒープ・サイズの変更オプション

Javaヒープ・サイズを変更する場合は、MAX_HEAP_SIZEとHEAP_NEWSIZEの両方をcassandra-env.shに設定します。

  • MAX_HEAP_SIZE

    JVMに最大のヒープ・サイズを設定します。最小ヒープ・サイズにも同じ値を使用します。これにより、プロセス開始時にヒープがメモリーにロックされ、OSによるスワップアウトを防げます。

  • HEAP_NEWSIZE

    若い世代(NEW)のサイズ。これが大きいほど、GCの一時停止時間が長くなります。これが短いほど、GCの負荷が大きくなります(通常)。適切な目安は、CPUコアあたり100MBです。

Javaヒープの調整

Cassandraはオペレーティング・システムのI/OインフラストラクチャとJVMを介して対話するのにかなりの時間を費やします。このため、Javaヒープ・サイズを適切に調整することが重要です。Cassandraのデフォルトの構成は、システム・メモリーの総量に基づいたヒープ・サイズのJVMを起動します。

システム・メモリー ヒープ・サイズ
2GB未満 システム・メモリーの1/2
2GB〜4GB 1GB
4GB超 システム・メモリーの1/4(ただし、8GB以下)

Cassandraを初めて使用する人の多くは、Javaヒープ・サイズを調整して大きくしがちですが、そうするとシステムのRAMのほとんどを消費することになります。多くの場合、Javaヒープ・サイズを大きくするのは、実際に、以下の理由により有害です。

  • Javaがガーベージ・コレクションを安定して処理する能力は8GBを超えるとすぐに低下します。
  • 最新のオペレーティング・システムは、頻繁にアクセスするデータのOSページのキャッシュを保持し、このデータをメモリーに非常に適切に維持します。しかし、Javaのヒープ・サイズが大きいと、その仕事が妨げられる可能性があります。

2GBを超えるシステム・メモリーがある場合、より多くのメモリーをページのキャッシュに使用できるよう、Javaヒープのサイズを比較的小さくしておきます。

一部のSolrユーザーの報告によると、スタックのサイズを大きくすると、Tomcatのパフォーマンスが向上します。スタックのサイズを大きくするには、cassandra-env.shファイルで、デフォルトの設定のコメントを解除し、変更します。また、memtable空間を小さくしてSolrのキャッシュに空き領域を与えると、パフォーマンスが向上する可能性があります。cassandra.yamlファイルのmemtable_total_space_in_mbプロパティを使用して、memtable空間を変更します。

MapReduceはJVMの外で実行するため、JVMの変更はAnalytics/Hadoopの動作に直接影響しません。

Cassandraのメモリーの使い方

通常、ガーベージ・コレクションの一時停止時間が問題となり始めるに至るまでに、ヒープに約8GBのメモリーを割り当てることができます。最新のマシンには、それより多くのメモリーが搭載されており、Cassandraは、ディスク上のファイルがアクセスされたときに、追加メモリーをページのキャッシュとして利用します。ディスク上のデータに関するCassandraメタデータの量のため、8GBを超えるメモリーをヒープに割り当てると、問題が生じます。Cassandraメタデータは、メモリーに常駐し、データの合計に比例します。一部のコンポーネントは、メモリーの合計サイズに比例して大きくなります

Cassandra 1.2以降では、ブルーム・フィルターとこのメタデータを格納する圧縮オフセット・マップはオフヒープに置かれます。これにより、Cassandraが効率的に処理できるデータのノードあたりの容量が非常に増えます。パーティションのサマリーもオフヒープに置かれます。

オフヒープの行キャッシュについて

Cassandraは、キャッシュされた行をネイティブのメモリー、Javaヒープ外に格納します。これにより、行あたりのメモリー使用量と、JVMヒープに対する要求がともに小さくなります。これは、JVMガーベージ・コレクションのパフォーマンスにとって最適なヒープ・サイズを保つのに役立ちます。

Javaガーベージ・コレクションの調整

Cassandra 2.2以降では、デフォルトのJVMガーベージ・コレクションはコンカレント・マーク・スイープ(CMS)ガーベージ・コレクターです。G1ガーベージ・コレクターを構成できます。ヒープ・サイズが4GB以上の場合、G1ガーベージ・コレクターが、コンカレント・マーク・スイープ(CMS)ガーベージ・コレクターよりパフォーマンスの点で優れています。今後、Java 9でG1ガーベージ・コレクターがデフォルトのガーベージ・コレクターになる予定です。G1は最初に、最も大きいガーベージ・オブジェクトを含むヒープの範囲をスキャンします。また、常にヒープのコンパクションも行います。一方、CMSガーベージ・コレクターは、完全なストップ・ザ・ワールド・ガーベージ・コレクションの実行時にのみコンパクションを行います。G1を構成するには、$CASSANDRA_HOME/conf/cassandra-env.shからすべてのCMSパラメーターを削除し、次のコードを追加します。
JVM_OPTS="$env:JVM_OPTS -XX:+UseG1GC" JVM_OPTS="$env:JVM_OPTS -XX:G1RSetUpdatingPauseTimePercent=5"

CassandraのGCInspectorクラスは、ガーベージ・コレクションに要した時間が200ミリ秒を超えると、ガーベージ・コレクションに関する情報をログに記録します。ガーベージ・コレクションが頻繁に発生し、完了までにある程度の時間を要する(ConcurrentMarkSweepに数秒を要するなど)場合、JVMに対するガーベージ・コレクションの圧力が大きいことを示します。解決策としては、ノードの追加、キャッシュ・サイズの縮小、またはガーベージ・コレクションに関するJVMオプションの調整があります。

JMXのオプション

Cassandraは、Java Management Extensions(JMX)を介して、多数の統計と管理操作を公開しています。JMXは、Javaアプリケーションおよびサービスを管理および監視するツールを提供するJavaテクノロジーです。JavaアプリケーションがMBeanとして公開した統計情報または操作はすべて、JMXを使用して監視したり、制御したりすることができます。JConsolenodetoolユーティリティ、およびDataStax OpsCenterは、JMX対応の管理ツールの例です。

デフォルトで、cassandra-env.shファイルの以下のプロパティを変更して、認証なしにJMXがポート7199をリッスンするよう構成できます。

  • com.sun.management.jmxremote.port

    CassandraがJMX接続をリッスンするポート。

  • com.sun.management.jmxremote.ssl

    JMXのためにSSLを有効/無効にします。

  • com.sun.management.jmxremote.authenticate

    JMXのためにリモート認証を有効/無効にします。

  • -Djava.rmi.server.hostname

    JMXが接続に使用するインターフェイスのホスト名またはIPアドレスを設定します。接続に問題がある場合は、コメントを解除して設定します。

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/cassandra/cassandra.yaml
tarボール・インストール install_location/resources/cassandra/conf/cassandra.yaml
Windowsインストール C:\Program Files\DataStax Community\apache-cassandra\conf\cassandra.yaml
cassandra-env.shファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/cassandra/cassandra-env.sh
tarボール・インストール install_location/conf/cassandra-env.sh
cassandra-env.ps1の場所:
Windowsインストール C:\Program Files\DataStax Community\apache-cassandra\conf\cassandra-env.ps1