Nodetool の使用
Cassandra の nodetool を使用すると、クラスタ全体の問題を特定のノードに絞り込み、Cassandra プロセス自体の状態を詳細に把握できます。 数十個の便利なコマンドがありますが (すべてのコマンドについては nodetool help を参照)、トラブルシューティングに最も役立つコマンドの一部を簡単に紹介します。
クラスタステータス
nodetool status を使用して、クラスタのステータスを評価できます。
$ nodetool status <optional keyspace>
Datacenter: dc1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 127.0.1.1 4.69 GiB 1 100.0% 35ea8c9f-b7a2-40a7-b9c5-0ee8b91fdd0e r1
UN 127.0.1.2 4.71 GiB 1 100.0% 752e278f-b7c5-4f58-974b-9328455af73f r2
UN 127.0.1.3 4.69 GiB 1 100.0% 9dc1a293-2cc0-40fa-a6fd-9e6054da04a7 r3この場合、1 つのデータセンターに約 4.6GB のデータを持つ 3 つのノードがあり、すべて "稼働中" であることがわかります。ノードの稼働/停止ステータスは、クラスタ内のすべてのノードによって独立して決定されるため、クラスタ内の複数のノードで nodetool status を実行して、全体像を確認する必要がある場合があります。
nodetool status と grep を使用して、停止しているノードを確認できます。
$ nodetool status | grep -v '^UN'
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
DN 127.0.0.5 105.73 KiB 1 33.3% df303ac7-61de-46e9-ac79-6e630115fd75 r1この場合、2 つのデータセンターがあり、データセンター dc2 とラック r1 に停止しているノードが 1 つあります。これは、127.0.0.5 に問題がある可能性があり、調査が必要であることを示している可能性があります。
コーディネータクエリレイテンシ
nodetool proxyhistograms を使用して、コーディネータの読み取りおよび書き込みレイテンシのレイテンシ分布を表示し、レイテンシの問題を絞り込むことができます。
$ nodetool proxyhistograms
Percentile Read Latency Write Latency Range Latency CAS Read Latency CAS Write Latency View Write Latency
(micros) (micros) (micros) (micros) (micros) (micros)
50% 454.83 219.34 0.00 0.00 0.00 0.00
75% 545.79 263.21 0.00 0.00 0.00 0.00
95% 654.95 315.85 0.00 0.00 0.00 0.00
98% 785.94 379.02 0.00 0.00 0.00 0.00
99% 3379.39 2346.80 0.00 0.00 0.00 0.00
Min 42.51 105.78 0.00 0.00 0.00 0.00
Max 25109.16 43388.63 0.00 0.00 0.00 0.00ここでは、読み取り、書き込み、範囲リクエスト (例: select * from keyspace.table)、CAS 読み取り (CAS の比較フェーズ)、CAS 書き込み (比較と設定の設定フェーズ) の完全なレイテンシ分布を確認できます。これらは、高レベルのレイテンシの問題を絞り込むのに役立ちます。たとえば、この場合、クライアントの読み取りタイムアウトが 20 ミリ秒の場合、このノードから時々タイムアウトが発生する可能性がありますが、1% 未満です (99% 読み取りレイテンシが 3.3 ミリ秒 < 20 ミリ秒であるため)。
ローカルクエリレイテンシ
レイテンシ/エラーの問題が発生しているテーブルがわかっている場合は、nodetool tablehistograms を使用して、ノードでローカルに何が起こっているかをより詳細に把握できます。
$ nodetool tablehistograms keyspace table
Percentile SSTables Write Latency Read Latency Partition Size Cell Count
(micros) (micros) (bytes)
50% 0.00 73.46 182.79 17084 103
75% 1.00 88.15 315.85 17084 103
95% 2.00 126.93 545.79 17084 103
98% 2.00 152.32 654.95 17084 103
99% 2.00 182.79 785.94 17084 103
Min 0.00 42.51 24.60 14238 87
Max 2.00 12108.97 17436.92 17084 103これは、特に重要なメトリクスのパーセンタイル内訳を示しています。
最初の列には、論理読み取りごとに読み取られた sstable の数が含まれています。ここでの数値が非常に大きい場合は、間違ったコンパクション戦略を選択した可能性があります。たとえば、更新が多いワークロードの場合、SizeTieredCompactionStrategy は通常、LeveledCompactionStrategy よりも読み取りごとの読み取り数がはるかに多くなります。
2 番目の列は、*ローカル* 書き込みレイテンシのレイテンシ内訳を示しています。この場合、p50 は 73 マイクロ秒と非常に良好ですが、最大レイテンシは 12 ミリ秒と非常に遅くなっています。書き込みの最大レイテンシが高い場合は、多くの場合、コミットログボリュームの速度が遅い (fsync が遅い) か、コミットログセグメントをすぐに飽和させる大きな書き込みがあることを示しています.
3 番目の列は、*ローカル* 読み取りレイテンシのレイテンシ内訳を示しています。ローカル Cassandra 読み取りは (予想どおり) ローカル書き込みよりも遅く、読み取り速度は読み取りごとに読み取られる sstable の数と高度に相関していることがわかります。
4 番目と 5 番目の列は、パーティションサイズとパーティションごとの列数の分布を示しています。これらは、テーブルに平均してスキニーパーティションまたはワイドパーティションがあるかどうかを判断するのに役立ち、不正なデータパターンを特定するのに役立ちます。たとえば、2 メガバイトの単一セルがある場合、読み取られるとヒープ圧力が発生する可能性があります。
スレッドプール状態
nodetool tpstats を使用して、特定のノードの現在の未処理リクエストを表示できます。これは、Cassandra プロセスに不足しているリソース (読み取りスレッド、書き込みスレッド、コンパクション、リクエストレスポンススレッド) を特定しようとする場合に役立ちます。例えば
$ nodetool tpstats
Pool Name Active Pending Completed Blocked All time blocked
ReadStage 2 0 12 0 0
MiscStage 0 0 0 0 0
CompactionExecutor 0 0 1940 0 0
MutationStage 0 0 0 0 0
GossipStage 0 0 10293 0 0
Repair-Task 0 0 0 0 0
RequestResponseStage 0 0 16 0 0
ReadRepairStage 0 0 0 0 0
CounterMutationStage 0 0 0 0 0
MemtablePostFlush 0 0 83 0 0
ValidationExecutor 0 0 0 0 0
MemtableFlushWriter 0 0 30 0 0
ViewMutationStage 0 0 0 0 0
CacheCleanupExecutor 0 0 0 0 0
MemtableReclaimMemory 0 0 30 0 0
PendingRangeCalculator 0 0 11 0 0
SecondaryIndexManagement 0 0 0 0 0
HintsDispatcher 0 0 0 0 0
Native-Transport-Requests 0 0 192 0 0
MigrationStage 0 0 14 0 0
PerDiskMemtableFlushWriter_0 0 0 30 0 0
Sampler 0 0 0 0 0
ViewBuildExecutor 0 0 0 0 0
InternalResponseStage 0 0 0 0 0
AntiEntropyStage 0 0 0 0 0
Message type Dropped Latency waiting in queue (micros)
50% 95% 99% Max
READ 0 N/A N/A N/A N/A
RANGE_SLICE 0 0.00 0.00 0.00 0.00
_TRACE 0 N/A N/A N/A N/A
HINT 0 N/A N/A N/A N/A
MUTATION 0 N/A N/A N/A N/A
COUNTER_MUTATION 0 N/A N/A N/A N/A
BATCH_STORE 0 N/A N/A N/A N/A
BATCH_REMOVE 0 N/A N/A N/A N/A
REQUEST_RESPONSE 0 0.00 0.00 0.00 0.00
PAGED_RANGE 0 N/A N/A N/A N/A
READ_REPAIR 0 N/A N/A N/A N/Aこのコマンドは、あらゆる種類の興味深い統計情報を示しています.最初のセクションには、現在実行中のスレッド数 (アクティブ) と実行を待機しているスレッド数 (保留中) を含む、Cassandra ステージごとのスレッドプールの詳細な内訳が表示されます。通常、特定のスレッドプールで保留中の実行が表示される場合は、そのタイプの操作に限定された問題が発生していることを示します。たとえば、RequestResponseState キューがバックアップしている場合、これはコーディネータが多くのダウンストリームレプリカリクエストを待機しており、トークン認識の不足、または読み取りリクエストで使用されている非常に高い整合性レベル (たとえば、ALL での読み取りは RF RequestResponseState スレッドを拘束しますが、LOCAL_ONE は ReadStage スレッドプール内の単一スレッドのみを使用します) を示している可能性があります。一方、多くの保留中のコンパクションが表示される場合は、コンパクションスレッドが書き込みの量に追いつかず、コンパクション戦略または concurrent_compactors または compaction_throughput オプションを調整する必要があることを示している可能性があります。
2 番目のセクションには、すべての主要なリクエストタイプのドロップ (エラー) とレイテンシ分布が表示されます。ドロップはプロセス開始以降累積されますが、ドロップとして認定されるデフォルトのタイムアウトが非常に高いため (約 5 ～ 10 秒)、深刻な問題を示すものがある場合は、ドロップされたメッセージをさらに調査する必要があります。
コンパクション状態
Cassandra は LSM データストアであるため、Cassandra は sstable をまとめて圧縮する必要がある場合があり、パフォーマンスに悪影響を与える可能性があります。特に、コンパクションはかなりの量の CPU リソースを使用し、大量の OS ページキャッシュ を無効にし、ディスクドライブに大きな負荷をかける可能性があります。これが当てはまるかどうかを判断するための優れた os ツール <os-iostat> がありますが、多くの場合、nodetool compactionstats を使用してコンパクションが実行されているかどうかを確認することをお勧めします。
$ nodetool compactionstats
pending tasks: 2
- keyspace.table: 2
id compaction type keyspace table completed total unit progress
2062b290-7f3a-11e8-9358-cd941b956e60 Compaction keyspace table 21848273 97867583 bytes 22.32%
Active compaction remaining time : 0h00m04sこの場合、keyspace.table テーブルで 1 つのコンパクションが実行されており、97 のうち 21.8 メガバイトが完了し、Cassandra は (設定されたコンパクションスループットに基づいて) これに 4 秒かかると推定しています。 -H を渡して、単位を人間が判読できる形式にすることもできます。
一般に、実行中の各コンパクションは単一のコアを消費できますが、並列して実行するほどデータのコンパクションが高速になります.コンパクションは良好な読み取りパフォーマンスを確保するために不可欠であるため、コンパクションが迅速に完了し、クエリ スレッドから多くのリソースを奪わないように、同時コンパクションの適切なバランスをとることがパフォーマンスにとって非常に重要です。コンパクションが追いつかないことに気付いた場合は、Cassandra の concurrent_compactors または compaction_throughput オプションを調整してみてください。
データファイルに使用されるパス
Cassandra は、設定されたディレクトリ内のディスクにデータを永続化しています。データファイルは、data_file_directories で設定されたディレクトリに分散されます。キースペースとテーブルの構造に似て、Cassandra は data_file_directories 内にサブディレクトリを作成します。ただし、テーブルとキースペースが削除されても、ディレクトリは削除されません。これらのディレクトリはスナップショットを保持するという理由で保持されていますが、削除される可能性があります。運用担当者は、どのディレクトリがまだ使用されているかを知る必要があります。 nodetool datapaths コマンドを実行すると、Cassandra が実際に sstable データをディスクに保存しているディレクトリを簡単に一覧表示できます。
% nodetool datapaths -- system_auth
Keyspace: system_auth
Table: role_permissions
Paths:
/var/lib/cassandra/data/system_auth/role_permissions-3afbe79f219431a7add7f5ab90d8ec9c
Table: network_permissions
Paths:
/var/lib/cassandra/data/system_auth/network_permissions-d46780c22f1c3db9b4c1b8d9fbc0cc23
Table: resource_role_permissons_index
Paths:
/var/lib/cassandra/data/system_auth/resource_role_permissons_index-5f2fbdad91f13946bd25d5da3a5c35ec
Table: roles
Paths:
/var/lib/cassandra/data/system_auth/roles-5bc52802de2535edaeab188eecebb090
Table: role_members
Paths:
/var/lib/cassandra/data/system_auth/role_members-0ecdaa87f8fb3e6088d174fb36fe5c0dデフォルトではすべてのキースペースとテーブルが一覧表示されますが、特定のデータパスを照会するために keyspace と keyspace.table 引数のリストを指定できます。 --format オプションを使用すると、出力を YAML または JSON としてフォーマットできます。
