実稼働環境での推奨設定

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

• 最新のJava仮想マシンを使用する
• クロックの同期化
• TCP設定
• CPU周波数スケーリングを無効にする
• 再起動後も新しい設定が保持されていることを確認する
• SSDを最適化する
• SSDでRAIDに最適な--setra設定を使用する
• NUMAシステムでzone_reclaim_modeを無効にする
• ユーザー・リソースの制限を設定する
• スワップの無効化
• Java Hugepagesの設定を確認する
• DataStax Enterpriseで任意指定のJavaガーベージ・コレクションのヒープ・サイズを設定する
• DataStax Enterpriseでコンカレント・マーク・スイープ（CMS）ガーベージ・コレクションを使用する場合のヒープ・サイズを決定する
• 最適なJavaガーベージ・コレクションのヒープ・サイズを設定する
• 回転式ディスクのRAIDに最適なblockdev --setra設定を適用する

最新の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

sudo sysctl -p /etc/sysctl.conf

sudo sysctl -p /etc/sysctl.d/filename.conf

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

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

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

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の有効化/無効化が一貫していないことがあります。そのため、パフォーマンスに予期しない問題が生じることがあります。

$ echo 0 > /proc/sys/vm/zone_reclaim_mode

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

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

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

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

<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited

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

<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited

root - memlock unlimited
root - nofile 100000
root - nproc 32768
root - as unlimited

cassandra_user - nproc 32768

vm.max_map_count = 1048575

session    required   pam_limits.so

$ sudo sysctl -p

$ 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バグ・レポートを参照してください。

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

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

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

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

パフォーマンスが改善されない場合は、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