実稼働環境での推奨設定

Linuxプラットフォーム用のDataStax Enterpriseの推奨設定。

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

最新のJava仮想マシンを使用する 

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

クロックの同期化 

すべてのノードとアプリケーション・サーバーでクロックを同期します。NTP(Network Time Protocol)などの方法を使用します。

クロックの同期が必要な理由は、DataStaX Enterprise(DSE)ではタイムスタンプが新しい別のバージョンがある場合にのみカラムが上書きされるためです。この状況は、マシンがさまざまな場所にある場合に生じる可能性があります。

DSEタイムスタンプは、タイムゾーン情報を持たないUNIXエポック以来の経過マイクロ秒数としてエンコードされます。DSEのすべての書き込みのタイムスタンプは、UTC(協定世界時)です。DataStaxでは、人間が読む出力を生成する場合にのみローカル・タイムに変換することを推奨します。

TCP設定 

トラフィックの少ない期間に、アイドル接続タイムアウトが構成されているファイアウォールにより、ローカルのノードおよび他のデータ・センターのノードとの接続が終了する可能性があります。ノード間の接続がタイムアウトになるのを回避するには、以下のネットワーク・カーネル設定を設定します。

sudo sysctl -w \ net.ipv4.tcp_keepalive_time=60 \ net.ipv4.tcp_keepalive_probes=3 \ net.ipv4.tcp_keepalive_intvl=10

これらの値は、TCP keepaliveタイムアウトを60秒に設定して、10秒間隔でプローブを3回出します。この設定では、90秒経過後(60 + 10 + 10 + 10)、切断されたTCP接続が検出されます。追加のトラフィックは無視できるため、考慮する必要はありません。恒久的にこれらの設定を変えずにそのままにしても特に問題はありません。「Linuxでファイアウォール・アイドル接続タイムアウトにより、トラフィックの少ない期間にノードの通信が切断される」を参照してください。

データベースで使用されている数千の同時接続を処理するには、以下のLinuxカーネル設定を変更します。

sudo sysctl -w \ net.core.rmem_max=16777216 \ net.core.wmem_max=16777216 \ net.core.rmem_default=16777216 \ net.core.wmem_default=16777216 \ net.core.optmem_max=40960 \ net.ipv4.tcp_rmem=4096 87380 16777216 \ net.ipv4.tcp_wmem=4096 65536 16777216
TCP設定を保持するには:
  1. 以下を/etc/sysctl.confファイルに追加します。
    net.ipv4.tcp_keepalive_time=60
    net.ipv4.tcp_keepalive_probes=3
    net.ipv4.tcp_keepalive_intvl=10
    net.core.rmem_max=16777216
    net.core.wmem_max=16777216
    net.core.rmem_default=16777216
    net.core.wmem_default=16777216
    net.core.optmem_max=40960
    net.ipv4.tcp_rmem=4096 87380 16777216
    net.ipv4.tcp_wmem=4096 65536 16777216
  2. 以下のいずれかのコマンドを使用して設定を読み込みます。
sudo sysctl -p /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.d/filename.conf

CPU周波数スケーリングを無効にする 

最新のLinuxシステムには、CPU周波数スケーリングまたはCPU速度スケーリングと呼ばれる機能があります。この機能により、サーバーのクロック速度を動的に調整して、要求や負荷が低いときはサーバーを低いクロック速度で実行できます。これにより、サーバーの消費電力と発熱量(冷却コストに大きな影響を与える)が低減されます。残念ながら、スループットが低速で上限に達する可能性があるため、この動作はDataStax Enterpriseを実行しているサーバーに悪影響を及ぼします。

ほとんどのLinuxシステムでは、定義された規則に基づいてCPUfreqガバナーが周波数のスケーリングを管理し、デフォルトのondemandガバナーは要求が多いときクロック周波数を最大に切り替え、システムがアイドル状態のときに最小の周波数に切り替えます。

CPU周波数を低下させるガバナーを使用しないでください。最適なパフォーマンスを確保するには、performanceガバナーを使用するようにすべてのCPUを再構成します。これにより、周波数が最大でロックされます。このガバナーは周波数を切り替えません。つまり、消費電力は低減されませんが、サーバーは常に最大スループットで稼働します。ほとんどのシステムで、ガバナーを以下のように設定してください。
for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
    [ -f $CPUFREQ ] || continue
    echo -n performance > $CPUFREQ
done

詳細については、DataStaxヘルプ・センターの「CPU周波数スケーリングが有効な場合の高いサーバー負荷とレイテンシー」を参照してください。

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

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

SSDを最適化する 

ほとんどのLinuxディストリビューションにおいて、デフォルトのSSD構成は適切ではありません。SSDの最適な設定を確認するには、以下の手順を実行します。

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

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

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

    この設定によって余分なバイトを読み込まないようにオペレーティング・システムに通知が行われ、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(Amazon EC2)に最適なreadahead設定は、非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コマンドを使用します。このコマンドを使用して一時的に制限値を設定することもできますが、以下のように変更を永続化することを推奨します。

パッケージおよびInstaller-Servicesのインストール:

/etc/security/limits.d/cassandra.confファイルに以下の設定が含まれていることを確認してください。
<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited

tarボールおよびInstaller-No Servicesのインストール:

:RHELバージョン6.xでは、/etc/security/limits.confファイルに以下の設定が含まれていることを確認してください。
<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited
DataStax Entepriseをルートとして実行する場合、Ubuntuなど一部のLinuxディストリビューションでは、cassandra_userを使用するのではなく、ルート用に明示的に制限を設定する必要があります。
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
DataStax Enterpriseプロセスに制限が適用されたかどうかを確認するには、以下のコマンドを実行します。ここで、pidはDataStax Enterpriseプロセスを現在実行中のプロセスIDです。
$ cat /proc/pid/limits

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

スワップの無効化 

スワップを無効にしないと、パフォーマンスが大幅に低下する可能性があります。データベースには、複数のレプリカと透過的なフェイルオーバー機能が備わっているため、メモリー不足になったときはレプリカをスワップするよりもすぐに強制終了した方が望ましいとされています。こうすると、スワップのためにレイテンシーが高くなっているレプリカを引き続き使用するのではなく、機能しているレプリカにすぐにトラフィックをリダイレクトすることができます。システムの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

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

DataStax Enterpriseで任意指定のJavaガーベージ・コレクションのヒープ・サイズを設定する 

DataStax Enterprise 5.1のデフォルトのJVMガーベージ・コレクション(GC)はG1です。
注: Java 7を使用している場合、DataStaxではG1の使用を推奨しません。これは、G1にクラスが読み込まれない問題が発生するためです。Java 7では、完全なGCが実行されるまで、PermGenが無期限で満杯になります。

ヒープ・サイズは、通常、システム・メモリーの¼~½です。オフヒープ・キャッシュとファイル・システム・キャッシュにも使用されるため、すべてのメモリーをヒープに割り当てないでください。

環境に合ったヒープ・サイズを簡単に決定するには、以下の手順を実行します。
  1. cassandra-env.shファイルのMAX_HEAP_SIZEを単一のノードの任意の高い値に設定します。
  2. そのノードで使用されるヒープを表示します。
    • GCロギングを有効にし、ログで傾向を確認します。
    • OpsCenterのリスト・ビューを使用します。
  3. そのクラスターのヒープ・サイズ設定の値を使用します。
注: この方法を使用すると、テスト・ノードのパフォーマンスが低下しますが、一般的にクラスターのパフォーマンスが大幅に低下することはありません。

パフォーマンスが改善されない場合は、JVMの調整についてDataStaxサービス・チームにお問い合わせください。

DataStax Enterpriseでコンカレント・マーク・スイープ(CMS)ガーベージ・コレクションを使用する場合のヒープ・サイズを決定する 

CMSの調整は非常に繊細な作業です。最良の結果を得るには、時間と専門知識、テストの繰り返しが必要です。DataStaxでは、代わりにDataStaxサービス・チームにご相談いただくことを推奨しています。 Javaリソースの調整 には、作業を開始する際の基本的な情報が記載されています。

最適なJavaガーベージ・コレクションのヒープ・サイズを設定する 

Javaリソースの調整」を参照してください。

回転式ディスクの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を最適化する」を参照してください。
cassandra-env.shファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストールInstaller-Servicesインストール

/etc/dse/cassandra/cassandra-env.sh

tarボール・インストールInstaller-No Servicesインストール

installation_location/resources/cassandra/conf/cassandra-env.sh