Javaリソースの調整

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

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を起動します。

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ガーベージ・コレクションの調整 

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を使用して監視したり、制御したりすることができます。JConsole、nodetoolユーティリティ、および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アドレスを設定します。接続に問題がある場合は、コメントを解除して設定します。