nodetool tpstats
スレッド・プールの使用状況の統計を表示します。
スレッド・プールの使用状況の統計を表示します。
構文
$ nodetool <options> tpstats
installation_location/resources/cassandra/bin| 短い形式 | 長い形式 | 説明 |
|---|---|---|
-h |
--host |
ホスト名またはIPアドレス。 |
| -F | --format | 出力形式はjsonまたはyaml。 |
-p |
--port |
ポート番号。 |
-pwf |
--password-file |
パスワード・ファイルのパス。 |
-pw |
--password |
パスワード。 |
-u |
--username |
リモートJMXエージェントのユーザー名。 |
-- |
オプションと間違えられる可能性のある引数とオプションを区切ります。 | |
説明
DataStax Enterprise(DSE)データベースは、Staged Event Driven Architecture(SEDA)に基づいて設計されています。データベースは、異なるタスクをメッセージング・サービスに接続された段階に分けます。各段階には、キューとスレッド・プールが存在します。一部の段階には、同じノードに別の段階が存在する場合がありますが、その段階にあるメッセージング・サービスとキュー・タスクを即座にスキップします。「DataStax Enterpriseのクラスターの監視」で説明されているように、次の段階がビジー状態で、パフォーマンスのボトルネックにつながる場合、データベースはキューをバックアップできます。
nodetool tpstatsコマンドは、スレッド・プールによるデータベース操作の各段階を報告します。Activeスレッドの数- このスレッド・プールによる実行を待機している
Pending要求の数 - スレッド・プールによる
Completedタスクの数 - サービスの次のステップのスレッド・プールが満杯であるため、現在
Blockedとなっている要求の数 All-Time Blocked要求の総数。これは、現在までにこのスレッド・プールでブロックされたすべての要求です。
ローカル・ノード上でnodetool tpstatsを実行して、そのノード上で実行されているDSEインスタンスが使用するスレッド・プールの統計を取得します。
適切なオプションを指定してnodetool tpstatsを実行し、リモート・ノードのスレッド・プール統計を確認します。設定手順については、「JMXユーザー認証の設定」を参照してください。
nodetool tpstatsのプール名とタスク
以下の表では、nodetool tpstats出力でレポートされる各プール名に関連付けられているタスクまたはプロパティについて説明します。
| プール名 | 関連付けられているタスク | 関連情報 |
|---|---|---|
| AntiEntropyStage | リペア・メッセージとストリーミングの処理 | 詳細については、「Nodetoolリペア」を参照してください。 |
| CacheCleanupExecutor | キャッシュの消去 | |
| CommitlogArchiver | 復元のためのcommitlogファイルのコピーまたはアーカイブ | |
| CompactionExecutor | コンパクションの実行 | |
| CounterMutationStage | ローカル・カウンターの変更の処理 | 書き込みレートがミューテーション・レートを超えた場合にバックアップします。整合性レベルがONE(デフォルト)に設定されており、カウンター・インクリメント・ワークロードが高い場合、保留カウントが大きくなります。 |
| GossipStage | ゴシップ経由でのノード情報の分散 | 同期されていないスキーマは問題の原因になる可能性があります。nodetool resetlocalschemaを使用して同期する必要がある場合があります。 |
| HintedHandoff | 取りこぼしたミューテーションの他のノードへの送信 | 通常は、他の問題の兆候です。nodetool disablehandoffを使用して、リペアを実行します。 |
| InternalResponseStage | ブートストラップおよびスキーマ・チェックを含む、クライアント以外が送信したメッセージへの応答 | |
| MemtableFlushWriter | memtableの内容のディスクへの書き込み | キューがディスクI/Oをオーバーランした場合、またはプロセスのソートが原因でバックアップすることがあります。 警告:
nodetool tpstatsは、MemtableFlushWriterプールでブロックされたスレッドは報告しません。nodetool tblestatsで報告される保留中のフラッシュ・メトリクスを確認してください。 |
| MemtablePostFlush | memtableをフラッシュした後のクリーンアップ(必要に応じてコミット・ログおよびセカンダリ・インデックスを破棄します) | |
| MemtableReclaimMemory | 使用されていないメモリーを使用可能にする | |
| MigrationStage | スキーマの変更の処理 | |
| MiscStage | ノードの除去の完了後にデータのスナップショットとレプリケーションを実行します。 | |
| MutationStage | ローカルでの挿入/更新、スキーマのマージ、コミット・ログの再生、または進行状況のヒントを実行する | Pendingの書き込み要求数が多い場合は、ノードの処理に問題があることを示しています。ノードの追加、ハードウェアと構成の調整、データ・モデルの更新により、これを修正します。 |
| Native-Transport-Requests | サーバーへのCQL要求の処理 | |
| PendingRangeCalculator | ブートストラップおよび離脱ノードごとの保留範囲の計算 | このツールによるレポートは役に立ちません。「開発者に対する注意」を参照してください。 |
| ReadRepairStage | 読み取りリペアの実行 | レプリカ間の接続が良好であれば、通常は高速です。Pendingが多くなりすぎた場合は、テーブルがread_repair_chanceとして0.11などの小さな値を使用するように変更することで、レートの高い読み取りテーブルのレートを下げてみてください。 |
| ReadStage | ローカル読み取りの実行 | また、行キャッシュからのデータのデシリアライズが含まれます。保留中の値により、読み取りレイテンシーが増加する可能性があります。通常、ノードを追加するか、システムを調整することで解決します。 |
| RequestResponseStage | 他のノードからの応答の処理 | |
| ValidationExecutor | スキーマの検証 |
nodetool tpstatsの削除可能なメッセージ
データベースは以下のメッセージを生成しますが、タイムアウト後に破棄します。nodetool tpstatsコマンドは、削除された各タイプのメッセージ数を報告します。JMXクライアントを使用して、これらのメッセージを表示できます。
| メッセージ・タイプ | 段階 | メモ |
|---|---|---|
| BINARY | なし | 廃止予定 |
| _TRACE | なし(特別) | トレース(nodetool settraceprobability)を記録するために使用します。実行中ではなく、挿入時にメッセージを破棄する特別エグゼキューター(1スレッド、キューの深さ1000)があります。 |
| MUTATION | MutationStage | 書き込みメッセージが、タイムアウト(write_request_timeout_in_ms)後に処理された場合、書き込み失敗をクライアントに送信したか、必要な整合性レベルを満たしました。成功した場合は、ミューテーションを実行するために、ヒンテッド・ハンドオフと読み取りリペアをリレーします。 |
| COUNTER_MUTATION | MutationStage | 書き込みメッセージが、タイムアウト(write_request_timeout_in_ms)後に処理された場合、書き込み失敗をクライアントに送信したか、必要な整合性レベルを満たしました。成功した場合は、ミューテーションを実行するために、ヒンテッド・ハンドオフと読み取りリペアをリレーします。 |
| READ_REPAIR | MutationStage | write_request_timeout_in_ms後にタイムアウト |
| 読み取り | ReadStage | read_request_timeout_in_ms後にタイムアウト。それ以降の読み取りは行われず、クライアントにエラーが返されます。 |
| RANGE_SLICE | ReadStage | range_request_timeout_in_ms後にタイムアウト。 |
| PAGED_RANGE | ReadStage | request_timeout_in_ms後にタイムアウト。 |
| REQUEST_RESPONSE | RequestResponseStage | request_timeout_in_ms後にタイムアウト。応答が完了して、返送されたが、タイムアウト前ではなかった。 |
例
ホストlabcluster上でnodetool tpstatsを実行します。
$ nodetool -h labcluster tpstats
出力例:
Pool Name Active Pending Completed Blocked All time blocked
CounterMutationStage 0 0 0 0 0
ReadStage 0 0 103 0 0
RequestResponseStage 0 0 0 0 0
MutationStage 0 0 13234794 0 0
ReadRepairStage 0 0 0 0 0
GossipStage 0 0 0 0 0
CacheCleanupExecutor 0 0 0 0 0
AntiEntropyStage 0 0 0 0 0
MigrationStage 0 0 11 0 0
ValidationExecutor 0 0 0 0 0
CommitLogArchiver 0 0 0 0 0
MiscStage 0 0 0 0 0
MemtableFlushWriter 0 0 126 0 0
MemtableReclaimMemory 0 0 126 0 0
PendingRangeCalculator 0 0 1 0 0
MemtablePostFlush 0 0 1468 0 0
CompactionExecutor 0 0 254 0 0
InternalResponseStage 0 0 1 0 0
HintedHandoff 0 0 0
Message type Dropped
RANGE_SLICE 0
READ_REPAIR 0
PAGED_RANGE 0
BINARY 0
READ 0
MUTATION 180
_TRACE 0
REQUEST_RESPONSE 0
COUNTER_MUTATION 0
