Usage Recommendations
このページは ClickHouse Cloud には適用されません。ここに記載された手順は、ClickHouse Cloud サービスで自動化されています。
CPU スケーリングガバナー
常に performance スケーリングガバナーを使用してください。on-demand スケーリングガバナーは、常に高い需要に対しては効果が薄くなります。
CPU 制限事項
プロセッサは過熱する可能性があります。dmesgを使用して、CPUのクロックレートが過熱のために制限されていたかどうかを確認してください。
この制限は、データセンターのレベルで外部的に設定されることもあります。ロード下での監視には turbostat を使用できます。
RAM
小規模なデータ（圧縮された状態で最大約200 GB）には、データのボリュームと同じだけのメモリを使用するのが最適です。 大規模なデータやインタラクティブ（オンライン）クエリを処理する際には、ホットデータのサブセットがページのキャッシュに収まるように、合理的な量のRAM（128 GB以上）を使用する必要があります。 1台のサーバーあたり約50 TBのデータボリュームでも、128 GBのRAMを使用することで、64 GBに比べてクエリパフォーマンスが大幅に向上します。
オーバーコミットは無効にしないでください。値 cat /proc/sys/vm/overcommit_memory は0または1にする必要があります。次のコマンドを実行してください。
perf topを使用して、メモリ管理にかかるカーネルでの時間を観察してください。
恒久的な巨大ページも割り当てる必要はありません。
16GB未満のRAMを使用する場合
推奨されるRAMの量は32 GB以上です。
システムのRAMが16 GB未満の場合、デフォルト設定がこのメモリ量に適合していないため、さまざまなメモリエラーが発生する可能性があります。RAMが少ない（最低2 GBまで）システムでClickHouseを使用できますが、これらのセットアップには追加の調整が必要で、低いレートでのみデータを取り込むことができます。
16GB未満のRAMでClickHouseを使用する場合、次の推奨事項があります：
config.xml内のマークキャッシュサイズを小さくします。最低500 MBに設定できますが、ゼロに設定することはできません。- クエリ処理スレッドの数を
1に減らします。 max_block_sizeを8192に低くします。1024のように小さくても、実用的な場合があります。max_download_threadsを1に低くします。input_format_parallel_parsingとoutput_format_parallel_formattingを0に設定します。
追加の注意事項：
- メモリアロケーターによってキャッシュされたメモリをフラッシュするには、
SYSTEM JEMALLOC PURGEコマンドを実行できます。 - メモリが少ないマシンでのS3またはKafka統合の使用は推奨されません。これらはバッファにかなりのメモリを必要とします。
ストレージサブシステム
予算が許すのであればSSDを使用してください。 そうでない場合はHDDを使用します。7200 RPMのSATA HDDで問題ありません。
接続されたディスクシェルフを持つ少数のサーバーよりも、ローカルハードドライブを持つ多数のサーバーを優先してください。 ただし、稀なクエリのためのアーカイブストレージには、ディスクシェルフが機能します。
RAID
HDDを使用する場合、RAID-10、RAID-5、RAID-6またはRAID-50を組み合わせることができます。
Linuxの場合、ソフトウェアRAID（mdadmを使用）がより良いです。
RAID-10を作成するときは、farレイアウトを選択してください。
予算が許すのであれば、RAID-10を選択してください。
LVM単体（RAIDやmdadmなし）は問題ありませんが、それを使ったRAIDを作成したり、mdadmと組み合わせたりする場合はあまり探索されていないオプションで、ミスの可能性が高まります
（不適切なチャンクサイズの選択、チャンクの不整合、間違ったRAIDタイプの選択、ディスクのクリーンアップを忘れるなど）。LVMの使用に自信がある場合は、使っても構いません。
4つ以上のディスクを持っている場合は、RAID-5の代わりにRAID-6（推奨）またはRAID-50を使用してください。 RAID-5、RAID-6またはRAID-50を使用する場合は、常にstripe_cache_sizeを増加させてください。デフォルト値は通常最良の選択ではありません。
デバイスの数とブロックサイズから正確な数を計算するには、次の式を使用します：2 * num_devices * chunk_size_in_bytes / 4096。
64 KBのブロックサイズは、ほとんどのRAID構成に十分です。平均的なclickhouse-serverの書き込みサイズは約1 MB（1024 KB）であり、したがって推奨されるstripeサイズも1 MBです。必要に応じてブロックサイズを最適化できます。RAIDアレイ内の冗長性のないディスクの数で割った1 MBに設定することで、各書き込みがすべての利用可能な冗長性のないディスクに並行して行われるようにします。 ブロックサイズを小さくしすぎたり大きくしすぎたりしないでください。
SSDでRAID-0を使用することができます。 RAIDを使用しても、常にデータのセキュリティのためにレプリケーションを使用してください。
長いキューでNCQを有効にします。HDDの場合、mq-deadlineまたはCFQスケジューラを選択し、SSDの場合はnoopを選択してください。 'readahead'設定を減少させないでください。 HDDの場合、書き込みキャッシュを有効にしてください。
OSでNVMEおよびSSDディスクに対して fstrim が有効になっていることを確認してください（通常はcronjobまたはsystemdサービスを使用して実装されています）。
ファイルシステム
Ext4は最も信頼性の高い選択肢です。マウントオプションとしてnoatimeを設定します。XFSも良好に機能します。
他のほとんどのファイルシステムも問題なく動作するはずです。
FAT-32およびexFATはハードリンクがサポートされていないため、使用できません。
ClickHouseは独自に圧縮を行うため、圧縮ファイルシステムは使用しないでください。また、ClickHouseでは組み込みの暗号化機能を使用できるため、暗号化ファイルシステムの使用は推奨されません。
ClickHouseはNFS経由で機能しますが、最良のアイデアではありません。
Linux カーネル
古いLinuxカーネルを使用しないでください。
ネットワーク
IPv6を使用している場合、ルートキャッシュのサイズを増やしてください。 3.2以前のLinuxカーネルは、IPv6の実装に多くの問題を抱えていました。
可能であれば、少なくとも10 GBのネットワークを使用してください。1 Gbも動作しますが、数十テラバイトのデータを持つレプリカのパッチ処理や、大量の中間データを処理する分散クエリには非常に劣るでしょう。
巨大ページ
古いLinuxカーネルを使用している場合は、透過的巨大ページを無効にしてください。これはメモリアロケーターに干渉し、パフォーマンスの著しい低下を引き起こします。 新しいLinuxカーネルでは透過的巨大ページは問題ありません。
透過的巨大ページ設定を永続的に変更する場合は、/etc/default/grubを編集してGRUB_CMDLINE_LINUX_DEFAULTオプションにtransparent_hugepage=madviseを追加します：
その後、sudo update-grubコマンドを実行し、効果を発揮させるために再起動してください。
ハイパーバイザ設定
OpenStackを使用している場合は、nova.confに次のように設定します。
libvirtを使用している場合は、XML設定内に次のように設定します。
これは、ClickHouseがcpuid命令で正確な情報を取得できるようにするために重要です。
そうでないと、古いCPUモデルでハイパーバイザーが実行されるとIllegal instructionのクラッシュが発生する可能性があります。
ClickHouse Keeper と ZooKeeper
ClickHouseのクラスタには、ZooKeeperの代わりにClickHouse Keeperを使用することが推奨されます。ClickHouse Keeperのドキュメントを参照してください。
ZooKeeperの継続使用を希望する場合は、最新のZooKeeperバージョン（3.4.9以降）を使用するのがベストです。安定したLinuxディストリビューションに含まれているバージョンは時代遅れである可能性があります。
異なるZooKeeperクラスタ間でデータを transferするために、手動で書かれたスクリプトを使用しないでください。結果が順序付きノードに対して正しくないためです。同じ理由で「zkcopy」ユーティリティも使用しないでください：https://github.com/ksprojects/zkcopy/issues/15
既存のZooKeeperクラスタを2つに分割したい場合、正しい方法はレプリカの数を増やし、その後それを2つの独立したクラスタとして再構成することです。
テスト環境や低い取り込みレートの環境では、ClickHouseと同じサーバーでClickHouse Keeperを実行できます。 本番環境では、ClickHouseとZooKeeper/Keeperのために別のサーバーを使用するか、ClickHouseファイルとKeeperファイルを別のディスクに配置することをお勧めします。なぜなら、ZooKeeper/Keeperはディスクのレイテンシに非常に敏感で、ClickHouseは利用可能なシステムリソースをすべて使用する可能性があるからです。
ZooKeeperのオブザーバーをアンサンブルに持つことはできますが、ClickHouseサーバーがオブザーバーとやりとりをするべきではありません。
minSessionTimeout設定を変更しないでください。大きな値はClickHouseの再起動安定性に影響を与える可能性があります。
デフォルト設定では、ZooKeeperはタイムボムです：
デフォルト設定では、ZooKeeperサーバーは古いスナップショットやログからファイルを削除しません（
autopurgeを参照）。これはオペレーターの責任です。
このボムを解体する必要があります。
以下は、大規模な本番環境で使用されるZooKeeper（3.5.1）の構成です：
zoo.cfg:
Javaバージョン：
JVMパラメータ：
Salt初期化：
ウイルス対策ソフトウェア
ウイルス対策ソフトウェアを使用する場合、ClickHouseのデータファイルフォルダ（/var/lib/clickhouse）をスキップするように設定してください。そうしないと、パフォーマンスが低下し、データの取り込みやバックグラウンドマージの際に予期しないエラーが発生する可能性があります。
