Linux実稼働環境での推奨設定 

DataStax EnterpriseとApache Cassandra™でのLinuxプラットフォームの推奨設定。

以下のセクションでは、LinuxでのCassandraのインストールを最適化するための推奨事項について説明します。

最新版のJava Virtual Machineを使用する 

最新の64ビット・バージョンのOracle Java Platform, Standard Edition 8(JDK)またはOpenJDK 7を使用します。

クロックの同期化 

NTP(ネットワーク・タイム・プロトコル)またはその他の方法を使用して、すべてのノードのクロックを同期します。

これが必要なのは、タイムスタンプがより新しい別のバージョンがある場合にのみ、Cassandraによってカラムが上書きされるためです。

再起動後に新しい設定が保持されていることを確認する 

注意:
環境によっては、再起動の後に以下の設定の一部が保持されない場合があります。システム管理者に問い合わせて、お使いの環境で設定が保持されるかどうかを確認してください。

SSDを最適化する 

ほとんどのLinuxディストリビューションのデフォルトのSSD構成は最適ではありません。これらの手順に従って、SSDに最適な設定にしてください。

  1. SysFS回転フラグがfalse(ゼロ)に設定されていることを確認します。

    この設定によって、オペレーティング・システムによるあらゆる検知がオーバーライドされてドライブがSSDと見なされます。

  2. SSDストレージから作成されたすべてのブロック・デバイス(mdarraysなど)に対して同じ回転フラグ設定を適用します。
  3. IOスケジューラーをdeadlineまたはnoopに設定します。
    • 対象となるブロック・デバイスがIOの最適化を実行する高度なIOコントローラーよりも下位のSSDアレイである場合は、noopスケジューラーが適切な選択肢です。
    • deadlineスケジューラーはIOレイテンシーを最小化する要求を最適化します。確信が得られない場合はdeadlineスケジューラーを使用します。
  4. ブロック・デバイスのreadahead値を8 KBに設定します。

    この設定によって余分なバイトを読み込まないようにオペレーティング・システムに通知が行われ、IO時間が増加して、ユーザーが要求しなかったバイトによってキャッシュが汚染される可能性があります。

    たとえば、SSDが/etc/rc.local内の/dev/sdaである場合は、以下のように設定します。

    $ echo deadline > /sys/block/sda/queue/scheduler
    #OR...
    #echo noop > /sys/block/sda/queue/scheduler
    touch /var/lock/subsys/local
    echo 0 > /sys/class/block/sda/queue/rotational
    echo 8 > /sys/class/block/sda/queue/read_ahead_kb

SSDでのRAIDに最適な--setra設定を使用する 

SSDでのRAIDに最適なreadahead設定(Amazon EC2の場合)は、RAID以外のSSDと同じ8KBです。詳細については、「SSDの最適化」を参照してください。

NUMAシステムでzone_reclaim_modeを無効にする 

Linuxカーネルは、zone_reclaim_modeの有効化/無効化が一貫していないことがあります。この結果、パフォーマンスに予期しない問題が生じることがあります。.
zone_reclaim_modeを確実に無効にするには以下のようにします。
$ echo 0 > /proc/sys/vm/zone_reclaim_mode

詳細については、「NUMAシステムにおけるLinuxカーネル独特のパフォーマンスの問題」を参照してください。

ユーザー・リソース制限を設定する 

現在の制限値を表示するには、ulimit -aコマンドを使用します。このコマンドを使用して一時的に制限値を設定することもできますが、以下のように変更を永続化することを推奨します。

DSE Servicesまたはパッケージのインストール: /etc/security/limits.d/cassandra.confファイルに以下の設定が含まれていることを確認してください。
<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited
DSE No-Servicesまたはtarボールのインストール: RHELバージョン6.xでは、/etc/security/limits.confファイルに以下の設定が含まれていることを確認してください。
<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited
rootとしてCassandraを起動する場合、UbuntuなどのLinuxディストリビューションでは、cassandra_userを使用せずに、rootの制限を明示的に設定する必要があります。
root - memlock unlimited
root - nofile 100000
root - nproc 32768
root - as unlimited
RHEL 6.xベースのシステムでは、/etc/security/limits.d/90-nproc.confnproc制限も設定します。
cassandra_user - nproc 32768
すべてのインストールで、以下の行を/etc/sysctl.confに追加してください。
vm.max_map_count = 1048575
Debianオペレーティング・システムとUbuntuオペレーティング・システムのインストールでは、pam_limits.soモジュールがデフォルトで有効になっていません。/etc/pam.d/suファイルを編集し、次の行をコメント解除します。
session    required   pam_limits.so
このようにPAM構成ファイルに変更を加えることで、システムが確実に/etc/security/limits.dディレクトリ内のファイルを読み取るようにすることができます。
変更内容を有効にするには、サーバーを再起動するか、以下のコマンドを実行します。
$ sudo sysctl -p
Cassandraプロセスに制限が適用されたかどうかを確認するには、以下のコマンドを実行します。ここで、pidはCassandraを現在実行中のプロセスのIDです。
$ cat /proc/pid/limits

詳細は、「Insufficient user resource limits errors」を参照してください。

スワップの無効化 

スワップを完全に無効化しないと、パフォーマンスが大幅に低下する可能性があります。 Cassandraには、複数のレプリカと透過的なフェイルオーバー機能が備わっているため、メモリー不足になったときはレプリカをスワップするよりもすぐに強制終了した方が望ましいとされています。こうすると、スワップのためにレイテンシーが高くなっているレプリカを引き続き使用するのではなく、機能しているレプリカにすぐにトラフィックをリダイレクトすることができます。システムのDRAMが多くても、OSはディスクのキャッシングに使用可能なDRAMを増やすために実行可能なコードをスワップアウトするため、やはりスワップによってパフォーマンスが大幅に低下します。

それでもスワップを使用する場合は、vm.swappiness=1を設定します。こうすると、カーネルは、最も使われていない部分をスワップアウトします。

$ sudo swapoff --all

この変更を永続化するために、すべてのスワップ・ファイル・エントリーを/etc/fstabから削除します。

詳細については、「ある程度の時間が経過すると、ノードがフリーズしたように見える」を参照してください。

Java Hugepages設定を確認する

最新の多くのLinuxディストリビューションは、デフォルトでTransparent Hugepagesが有効になっています。LinuxでTransparent Hugepagesを使用するとき、カーネルは4Kではなく、通常2MBなどの大きなチャンクでメモリーを割り当てようとします。これにより、CPUが追跡しなければならないページ数が減るため、パフォーマンスが向上する可能性があります。ただし、一部のアプリケーションは引き続き4Kページに基づいてメモリーを割り当てます。この結果、Linuxが2MBのページをデフラグしようとすると、パフォーマンスに著しい問題が生じることがあります。詳細については、「Cassandra Java Huge Pages」およびこの「RedHatバグ・レポート」を参照してください。

この問題を解決するには、hugepagesのdefragを無効にします。次のように入力します。
$ echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

一時的な解決策を含む詳細については、「Cassandraの処理が行われていないのにCPU使用率が高い」を参照してください。

最適なJavaガーベージ・コレクションが得られるようにJVMを調整する 

DataStaxノードとCassandraノードは、JVMがより多くのメモリーを使用するように構成されている方が、機能性が高まります。ただし、このプロパティの設定が高すぎると、JVMガーベージ・コレクション(GC)プロセスが過負荷になる可能性があります。最適なJVMヒープ・サイズは、使用されているGCの種類によって異なります。最善の設定を構成およびテストして、ヒープ・サイズとGCの最適なバランスを見つけてください。

古いコンピューターでは、通常、ガーベージ・コレクションの一時停止時間が問題となり始めるに至るまでに、ヒープに約8 GBのメモリーを割り当てることができます。新しいコンピューターでは、最大256 GBのメモリーを割り当てることができます。さらに新しいコンピューターでは、より多くのメモリーをヒープに割り当てることができますが、ガーベージ・コレクション機能で扱うヒープ・メモリーのCassandraメタデータの量が増えるため、パフォーマンスが低下する可能性があります。ただし、ガーベージ・コレクションは、Javaの以降のリリースで改善が見られています。

Cassandra 2.2以降のデフォルトのガーベージ・コレクションは、コンカレント・マーク・スイープ(CMS)ガーベージ・コレクターです。また、G1ガーベージ・コレクターを使用するようにノードを構成することもできます。こうすると、これがJava 9のデフォルトのガーベージ・コレクターになります。G1は、4 GB以上のヒープではCMSより高いパフォーマンスを発揮します。G1は最初に、最も大きいガーベージ・オブジェクトを含むヒープの範囲をスキャンします。また、常にヒープのコンパクションも行います。一方、CMSガーベージ・コレクターは、完全なストップ・ザ・ワールド・ガーベージ・コレクションの実行時にのみコンパクションを行います。

最新のコンピューターで推奨されるMAX_HEAPサイズ(使用されるGCサービスによって異なる):
ハードウェア・セットアップ 推奨されるMAX_HEAP_SIZE
最大256 GB RAM、CMSガーベージ・コレクション 最大16 GB
最大256 GB RAM、G1ガーベージ・コレクション 最大64 GB

G1を使用するようにCassandraを構成します。 

Cassandraのデフォルトのガーベージ・コレクション・サービスはCMSです。G1を使用するようにノードを構成するには、次のようにします。
  1. $CASSANDRA_HOME/conf/jvm.optionsを開きます。
  2. ### CMS Settingsセクションのすべての行をコメント・アウトします。
  3. ### G1 Settingsセクションで該当するG1設定のコメントを解除します。

HEAP_NEWSIZEを調整する 

HEAP_NEWSIZEも調整が可能です。HEAP_NEWSIZEを大きくすると、GCの一時停止時間が長くなります。ただし、HEAP_NEWSIZEが小さい場合、GCの一時停止時間は短くなりますが、通常は負担が大きくなります。DataStaxでは、MAX_HEAP_SIZEの25%〜50%の範囲を推奨します。

ガーベージ・コレクションとヒープ・サイズを調整してテストする 

Javaヒープ・サイズとガーベージ・コレクションを最適化するための最も良い方法は、設定を徐々に変えて、各構成をテストすることです。ヒントは以下のとおりです。
  • GCを調整する際は、GCログを必ず有効にしてください。
  • 特にDSE Searchを使用している場合は、GCの並列処理を有効にしてください。
  • G1に切り替えるときは、-Xmn行をコメント・アウトしてください。
  • G1を使用するノードの場合、Cassandraコミュニティでは、MAX_HEAP_SIZEを最大64GBまで、できるだけ大きくすることを推奨しています。
  • CassandraのGCInspectorクラスは、200 msよりも時間がかかるすべてのガーベージ・コレクションに関する情報をログ記録します。頻繁に行われ、完了までの時間が短いもの(ConcurrentMarkSweepに数秒かかる場合など)は、JVMにガーベージ・コレクションによる過度な圧力がかかっていることを示します。解決策としては、ノードの追加、キャッシュ・サイズの縮小、またはガーベージ・コレクションに関するJVMオプションの調整があります。

  • 調整に関するその他のヒントについては、「Secret HotSpot option improving GC pauses on large heaps」を参照してください。

回転式ディスクでのRAIDに最適なblockdev --setra設定を適用する 

通常、readaheadを128に設定することが推奨されます。

setraが65536に設定されていないことを確認してください。

$ sudo blockdev --report /dev/spinning_disk

setraを設定するには:

$ sudo blockdev --setra 128 /dev/spinning_disk
注: SSDでのRAIDの推奨設定は、RAIDのインストールに使用されていないSSDと同じです。詳細については、「SSDの最適化」を参照してください。