メインコンテンツまでスキップ
メインコンテンツまでスキップ

使用推奨

Not supported in ClickHouse Cloud
注記

このページは ClickHouse Cloud には適用されません。ここに記載されている手順は、ClickHouse Cloud サービスで自動化されています。

CPU スケーリングガバナー

常に performance スケーリングガバナーを使用してください。on-demand スケーリングガバナーは、常に高い需要に対してはかなり劣ります。

CPU 制限

プロセッサは過熱する可能性があります。dmesg を使用して、CPU のクロックレートが過熱により制限されていたかどうかを確認してください。 制限は、データセンターのレベルでも外部から設定できます。負荷の下で turbostat を使用してそれを監視できます。

RAM

小規模なデータ(最大約200 GB圧縮)の場合、データのボリュームと同じだけのメモリを使用するのが最適です。 大量のデータを処理し、対話型(オンライン)クエリを実行する場合は、合理的な量のRAM(128 GB以上)を使用して、ホットデータサブセットがページのキャッシュに収まるようにするべきです。 サーバーあたり約50 TBのデータボリュームであっても、128 GBのRAMを使用すると、64 GBと比べてクエリ性能が大幅に向上します。

オーバーコミットを無効にしないでください。cat /proc/sys/vm/overcommit_memory の値は 0 または 1 であるべきです。次のコマンドを実行します。

perf top を使用して、メモリ管理のためにカーネルで費やされた時間を監視します。 恒久的な大きなページも割り当てる必要はありません。

16GB未満のRAMを使用している場合

推奨RAM量は32 GB以上です。

システムに16 GB未満のRAMがある場合、デフォルト設定がこのメモリ量に一致しないため、さまざまなメモリエクセプションが発生する可能性があります。RAMが少ない(最低2 GB)システムでもClickHouseを使用できますが、これらのセットアップは追加の調整が必要で、低速でのデータ取り込みしかできません。

16GB未満のRAMでClickHouseを使用する場合、次の推奨を行います:

  • config.xml 内でマークキャッシュのサイズを下げます。500 MBまで下げることができますが、ゼロには設定できません。
  • クエリ処理スレッド数を 1 に下げます。
  • max_block_size8192 に下げます。1024 まで下げても実用的です。
  • max_download_threads1 に下げます。
  • input_format_parallel_parsingoutput_format_parallel_formatting0 に設定します。

追加の注意事項:

  • メモリアロケーターによってキャッシュされたメモリをフラッシュするには、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-6(推奨)またはRAID-50を使用し、RAID-5を避けてください。 RAID-5、RAID-6、またはRAID-50を使用する場合は、常にstripe_cache_sizeを増やしてください。デフォルトの値は通常最適ではありません。

デバイス数とブロックサイズから、以下の式を使って正確な数を計算します:2 * num_devices * chunk_size_in_bytes / 4096

ブロックサイズは、多くのRAID構成にとって64 KBで十分です。average clickhouse-serverの書き込みサイズは約1 MB(1024 KB)であるため、推奨されたストライプサイズも1 MBです。必要に応じてブロックサイズは、RAID配列内の不整合ディスクの数で割った1 MBに設定することで最適化できます。すべての利用可能な不整合ディスクに書き込みを並行化するためです。 ブロックサイズを小さすぎたり大きすぎたりしてはいけません。

SSDではRAID-0を使用できます。 RAIDを使用するかどうかにかかわらず、常にデータのセキュリティのためにレプリケーションを使用してください。

長いキューでNCQを有効にします。HDDの場合はmq-deadlineまたはCFQスケジューラを選び、SSDの場合はnoopを選択します。readahead設定を減少させないでください。 HDDの場合、書き込みキャッシュを有効にしてください。

オペレーティングシステムの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も機能しますが、数十 TBのデータをレプリカにパッチする際にはずっと悪化しますし、大量の中間データを持つ分散クエリの処理には劣ります。

大きなページ

古い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クラスターにはClickHouse Keeperの使用が推奨されています。 ClickHouse Keeper に関するドキュメントを参照してください。

ZooKeeperを引き続き使用したい場合は、最新のZooKeeperバージョン(3.4.9以降)を使用するのが最良です。安定したLinuxディストリビューションに含まれているバージョンは古くなっている可能性があります。

異なるZooKeeperクラスター間でデータを転送するために手動で書かれたスクリプトを使用しないでください。結果が順番にノードに対して不正確になるためです。同じ理由で「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)のフォルダーをスキップするように設定してください。そうしないと、性能が低下し、データの取り込みやバックグラウンドのマージ中に予期しないエラーが発生する可能性があります。