詳細分析と外部ツールの活用
マシンへのアクセスにより、運用担当者はログや nodetool では不可能な、より詳細な分析を行うことができます。Cassandra の運用担当者にはそれぞれ独自のツールセットがあるかもしれませんが、このページでは、問題のトラブルシューティングに使用される一般的な手法とツールの例をいくつか紹介します。これらのコマンドの多くは Linux でのみ動作しますが、別のオペレーティングシステムにデプロイしている場合は、同様の OS レベルのメトリクスとプロセスを評価する、実質的に同様のツールにアクセスできる場合があります。
JVM ツール
JVM には、多くの便利なツールが付属しています。これらのツールの一部は、特にヒープや実行スタックに関連する Cassandra の問題をデバッグするのに役立ちます。
注意: JVM ツールと Cassandra には、2 つのよくある落とし穴があります。
-
デフォルトでは、Cassandra は、長い一時停止を防ぐために
-XX:+PerfDisableSharedMemが設定されて出荷されます (詳細はCASSANDRA-9242とCASSANDRA-9483を参照)。JVM ツールを使用する場合は、代わりに/tmpをメモリ上のtmpfsにマウントすることで、CASSANDRA-9242を効果的に回避できます。 -
ツールを Cassandra と同じユーザーとして実行してください。たとえば、データベースが
cassandraとして実行されている場合、ツールもcassandraとして実行する必要があります (例:sudo -u cassandra <cmd>を使用)。
ガベージコレクションの状態 (jstat)
ヒープの圧迫が疑われる場合は、jstat を使用して Cassandra プロセスのガベージコレクションの状態を詳細に分析できます。このコマンドは常に安全に実行でき、eden ヒープの使用量 (E)、古い世代のヒープの使用量 (O)、eden コレクションの数 (YGC)、eden コレクションに費やされた時間 (YGCT)、古い/混合世代のコレクション (FGC)、および古い/混合世代のコレクションに費やされた時間 (FGCT) を含む、詳細なヒープ情報が得られます。
jstat -gcutil <cassandra pid> 500ms
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 0.00 81.53 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 82.36 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 82.36 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 83.19 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 83.19 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 84.19 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 84.19 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 85.03 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 85.03 31.16 93.07 88.20 12 0.151 3 0.257 0.408
0.00 0.00 85.94 31.16 93.07 88.20 12 0.151 3 0.257 0.408この場合、古い世代のヒープの使用量が 31.16%、eden が 83% で、比較的健全なヒーププロファイルであることがわかります。古い世代が日常的に 75% を超えている場合は、おそらくより多くのヒープが必要です (占有しきい値が 75% の CMS を想定)。このような永続的に高い古い世代がある場合は、古い世代のヒープの割り当てが不足しているか、Cassandra が収集するにはヒープ上にライブデータが多すぎる (例: memtable のため) ことを意味します。もう 1 つ注意すべき点は、eden ヒープが収集される頻度を示す、若いガベージコレクション (YGC) 間の時間です。各若い gc の一時停止は約 20 ～ 50 ミリ秒であるため、多数ある場合は、クライアントの高パーセンタイルレイテンシに気づかれるでしょう。
スレッド情報 (jstack)
Cassandra が何を行っているかの時点のスナップショットを取得するには、Cassandra の PID に対して jstack を実行します。注意: これにより、JVM が非常に短い時間 (<20 ミリ秒) 一時停止します。
$ jstack <cassandra pid> > threaddump
# display the threaddump
$ cat threaddump
# look at runnable threads
$grep RUNNABLE threaddump -B 1
"Attach Listener" #15 daemon prio=9 os_prio=0 tid=0x00007f829c001000 nid=0x3a74 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
--
"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x00007f82e800e000 nid=0x2a19 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
--
"JPS thread pool" #10 prio=5 os_prio=0 tid=0x00007f82e84d0800 nid=0x2a2c runnable [0x00007f82d0856000]
java.lang.Thread.State: RUNNABLE
--
"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007f82e80d7000 nid=0x2a2a runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
--
"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f82e80cc000 nid=0x2a29 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
--
# Note that the nid is the Linux thread idスレッドダンプで最も重要な情報のいくつかは、待機中/ブロック中のスレッドであり、スレッドがブロック/待機しているロックやモニターが含まれます。
基本的な OS ツール
Cassandra の問題をデバッグする場合、まず Cassandra がシステムリソースとどのように相互作用しているかを理解することが重要です。以下は、Cassandra が大量に使用するすべてのリソースです。
-
CPU コア。同時ユーザークエリの 実行用。
-
CPU 処理時間。クエリアクティビティ (データの解凍縮、行のマージなど) 用。
-
CPU 処理時間 (低優先度)。バックグラウンドタスク (コンパクション、ストリーミングなど) 用。
-
Java ヒープ用 RAM。内部データ構造と、デフォルトでは Cassandra memtable を保持するために使用されます。ヒープスペースは、書き込みパフォーマンスと同様に、一般的に重要なコンポーネントです。
-
OS ディスクキャッシュ用 RAM。頻繁にアクセスされる SSTable ブロックをキャッシュするために使用されます。OS ディスクキャッシュは、読み取りパフォーマンスの重要なコンポーネントです。
-
ディスク。Cassandra は、ディスクの読み取りレイテンシ、ディスクの書き込みスループット、そしてもちろんディスク容量を非常に重視します。
-
ネットワークレイテンシ。Cassandra は多くのノード間リクエストを行うため、ノード間のネットワークレイテンシはパフォーマンスに直接影響を与える可能性があります。
-
ネットワークスループット。Cassandra (および他のデータベース) には、小さなリクエスト (例:
SELECT * from foo.bar) が非常に大きな結果セット (例: データセット全体) を返す、いわゆる「インキャスト」問題がよく発生します。このような状況では、送信帯域幅が重要になります。
多くの場合、Cassandra のトラブルシューティングは、マシンまたはクラスターのリソースが不足している原因のトラブルシューティングに帰着します。次に、そのリソースを増やすか、クエリパターンを変更してそのリソースの使用量を減らします。
高レベルのリソース使用量 (top/htop)
Cassandra はシステムリソースを大量に使用するため、多くの場合、最初に行うべきことは、top または htop (ウェブサイト) を実行してマシンの状態を確認することです。
確認すべき項目
-
システム負荷レベル。これらの数値は混乱を招く可能性がありますが、一般的に、負荷平均が CPU コア数よりも大きい場合、Cassandra はおそらく良好な (100 ミリ秒未満の) レイテンシを実現できません。詳細は、Linux の負荷平均 を参照してください。
-
CPU 使用率。特に
htopは、CPU 使用率をuser(低優先度と通常優先度)、system(カーネル)、およびio-waitに分類するのに役立ちます。Cassandra クエリスレッドは通常優先度のuserスレッドとして実行され、コンパクションスレッドは低優先度のuserスレッドとして実行されます。高いsystem時間は、スレッドの競合などの問題を示している可能性があり、高いio-waitはディスクドライブの速度が遅いことを示している可能性があります。これは、Cassandra が処理リソースを何に使用しているかを理解するのに役立ちます。 -
メモリ使用量。どのプログラムが最も多くの常駐メモリを使用しているかを確認します。おそらく Cassandra です。Linux (2018 年現在) がメモリマップファイルメモリをどのように処理しているかのため、Cassandra の数値は実際よりも高く表示される可能性があります。
IO 使用量 (iostat)
iostat を使用して、レイテンシ分布、スループット、および使用率など、データドライブの状態を判断します。
$ sudo iostat -xdm 2
Linux 4.13.0-13-generic (hostname) 07/03/2018 _x86_64_ (8 CPU)
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.28 0.32 5.42 0.01 0.13 48.55 0.01 2.21 0.26 2.32 0.64 0.37
sdb 0.00 0.00 0.00 0.00 0.00 0.00 79.34 0.00 0.20 0.20 0.00 0.16 0.00
sdc 0.34 0.27 0.76 0.36 0.01 0.02 47.56 0.03 26.90 2.98 77.73 9.21 1.03
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 2.00 32.00 0.01 4.04 244.24 0.54 16.00 0.00 17.00 1.06 3.60
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 24.50 0.00 114.00 0.00 11.62 208.70 5.56 48.79 0.00 48.79 1.12 12.80この場合、/dev/sdc1 は非常に低速なドライブであり、await が 50 ミリ秒近く、avgqu-sz が 5 ios に近いです。ドライブは特に飽和状態ではありません (使用率はわずか 12.8%) が、50 ミリ秒は一般的な Cassandra 操作ではかなり長いため、これが p99 レイテンシにどのように影響するかを懸念する必要があります。ただし、この場合、レイテンシのほとんどは書き込みに存在し (通常、書き込みは読み取りよりもレイテンシが高い)、Cassandra の LSM の性質により、ユーザーからは隠されていることがよくあります。
iostat を使用して評価する重要なメトリクス
-
1 秒あたりの読み取りと書き込み。これらの数値はワークロードによって変化しますが、一般的に、Cassandra がディスクから読み取る必要がある量が多いほど、Cassandra の読み取りレイテンシは遅くなります。1 秒あたりの読み取り数が非常に多い場合は、クラスターの OS ページキャッシングのメモリが不足していることを示している可能性があります。
-
書き込みスループット。CassandraのLSMモデルは、ユーザーの書き込みを遅延させてバッチ処理するため、基盤となるメディアへのスループットがCassandraの最も重要な書き込みメトリックとなります。
-
読み取りレイテンシ（
r_await）。CassandraがOSページキャッシュをミスし、SSTableから読み取る場合、読み取りレイテンシはCassandraがデータで応答できる速度を直接決定します。 -
書き込みレイテンシ。Cassandraは、コミットログを同期する場合を除き、書き込みレイテンシの影響を受けにくいです。これは通常、書き込みレイテンシの非常に高いパーセンタイルに入ります。
詳細なレイテンシの内訳を取得するには、bcc-toolsなどのより高度なツールが必要になることに注意してください。
OSページキャッシュ使用量
Cassandraはメモリマップファイルを集中的に使用するため、オペレーティングシステムのページキャッシュの状態はパフォーマンスにとって非常に重要です。まず、システムで使用可能なキャッシュの量を確認します。
$ free -g
total used free shared buff/cache available
Mem: 15 9 2 0 3 5
Swap: 0 0 0この場合、9GBのメモリがユーザープロセス（Cassandraヒープ）によって使用され、8GBがOSページキャッシュに使用可能です。そのうち、3GBが実際にファイルのキャッシュに使用されています。ほとんどのメモリが使用されていてページキャッシュに使用できない場合、Cassandraのパフォーマンスは大幅に低下する可能性があります。そのため、Cassandraはヒープ用に予約された適度に少量のメモリから開始します。
ネットワークレイテンシと信頼性
Cassandraが他のレプリカを伴う書き込みまたは読み取りを行う場合（たとえば、LOCAL_QUORUM読み取り）、レイテンシに大きな影響を与える要因の1つはネットワークレイテンシです。複数マシン操作の問題をデバッグしようとするとき、ネットワークは調査する重要なリソースとなる可能性があります。pingやtraceroute、または最も効果的なmtrなどのツールを使用して、ノード間のレイテンシを特定できます。
$ mtr -nr www.google.com
Start: Sun Jul 22 13:10:28 2018
HOST: hostname Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 10 2.0 1.9 1.1 3.7 0.7
2.|-- 96.123.29.15 0.0% 10 11.4 11.0 9.0 16.4 1.9
3.|-- 68.86.249.21 0.0% 10 10.6 10.7 9.0 13.7 1.1
4.|-- 162.141.78.129 0.0% 10 11.5 10.6 9.6 12.4 0.7
5.|-- 162.151.78.253 0.0% 10 10.9 12.1 10.4 20.2 2.8
6.|-- 68.86.143.93 0.0% 10 12.4 12.6 9.9 23.1 3.8
7.|-- 96.112.146.18 0.0% 10 11.9 12.4 10.6 15.5 1.6
9.|-- 209.85.252.250 0.0% 10 13.7 13.2 12.5 13.9 0.0
10.|-- 108.170.242.238 0.0% 10 12.7 12.4 11.1 13.0 0.5
11.|-- 74.125.253.149 0.0% 10 13.4 13.7 11.8 19.2 2.1
12.|-- 216.239.62.40 0.0% 10 13.4 14.7 11.5 26.9 4.6
13.|-- 108.170.242.81 0.0% 10 14.4 13.2 10.9 16.0 1.7
14.|-- 72.14.239.43 0.0% 10 12.2 16.1 11.0 32.8 7.1
15.|-- 216.58.195.68 0.0% 10 25.1 15.3 11.1 25.1 4.8このmtrの例では、パケットが通過するパスと、典型的な損失とレイテンシを迅速に評価できます。パケット損失は通常、200msから3秒の追加レイテンシにつながるため、レイテンシの問題の一般的な原因となる可能性があります。
ネットワークスループット
Cassandraは送信帯域幅の制限の影響を受けやすいため、ネットワークスループットが制限されているかどうかを判断すると便利な場合があります。これを行うための便利なツールの1つは、帯域幅の使用状況と接続情報を一目で示すiftopです。ローカルのccmクラスターに対するストレステスト実行中のトラフィックを示す例を以下に示します。
$ # remove the -t for ncurses instead of pure text
$ sudo iftop -nNtP -i lo
interface: lo
IP address is: 127.0.0.1
MAC address is: 00:00:00:00:00:00
Listening on lo
# Host name (port/service if enabled) last 2s last 10s last 40s cumulative
--------------------------------------------------------------------------------------------
1 127.0.0.1:58946 => 869Kb 869Kb 869Kb 217KB
127.0.0.3:9042 <= 0b 0b 0b 0B
2 127.0.0.1:54654 => 736Kb 736Kb 736Kb 184KB
127.0.0.1:9042 <= 0b 0b 0b 0B
3 127.0.0.1:51186 => 669Kb 669Kb 669Kb 167KB
127.0.0.2:9042 <= 0b 0b 0b 0B
4 127.0.0.3:9042 => 3.30Kb 3.30Kb 3.30Kb 845B
127.0.0.1:58946 <= 0b 0b 0b 0B
5 127.0.0.1:9042 => 2.79Kb 2.79Kb 2.79Kb 715B
127.0.0.1:54654 <= 0b 0b 0b 0B
6 127.0.0.2:9042 => 2.54Kb 2.54Kb 2.54Kb 650B
127.0.0.1:51186 <= 0b 0b 0b 0B
7 127.0.0.1:36894 => 1.65Kb 1.65Kb 1.65Kb 423B
127.0.0.5:7000 <= 0b 0b 0b 0B
8 127.0.0.1:38034 => 1.50Kb 1.50Kb 1.50Kb 385B
127.0.0.2:7000 <= 0b 0b 0b 0B
9 127.0.0.1:56324 => 1.50Kb 1.50Kb 1.50Kb 383B
127.0.0.1:7000 <= 0b 0b 0b 0B
10 127.0.0.1:53044 => 1.43Kb 1.43Kb 1.43Kb 366B
127.0.0.4:7000 <= 0b 0b 0b 0B
--------------------------------------------------------------------------------------------
Total send rate: 2.25Mb 2.25Mb 2.25Mb
Total receive rate: 0b 0b 0b
Total send and receive rate: 2.25Mb 2.25Mb 2.25Mb
--------------------------------------------------------------------------------------------
Peak rate (sent/received/total): 2.25Mb 0b 2.25Mb
Cumulative (sent/received/total): 576KB 0B 576KB
============================================================================================この場合、帯域幅は多くのピア間でかなり均等に共有されていますが、合計がNICの定格容量に近づいている場合、または単一のクライアントに集中している場合は、発生している問題の手がかりを示している可能性があります。
高度なツール
運用担当者として、本当に深く掘り下げる必要がある場合があります。これは、高度なOSツールが役立つところです。
bcc-tools
最新のLinuxディストリビューション（4.1より新しいカーネル）のほとんどは、パフォーマンスの問題を深く掘り下げるためのbcc-toolsをサポートしています。まず、Debianではaptなどを介してbcc-toolsをインストールします。
$ apt install bcc-toolsその後、bcc-toolsに含まれるすべてのツールを使用できます。最も便利なツールの1つはcachestat（cachestatの例）で、OSページキャッシュのヒット数とミス数を正確に判断できます。
$ sudo /usr/share/bcc/tools/cachestat -T 1
TIME TOTAL MISSES HITS DIRTIES BUFFERS_MB CACHED_MB
18:44:08 66 66 0 64 88 4427
18:44:09 40 40 0 75 88 4427
18:44:10 4353 45 4308 203 88 4427
18:44:11 84 77 7 13 88 4428
18:44:12 2511 14 2497 14 88 4428
18:44:13 101 98 3 18 88 4428
18:44:14 16741 0 16741 58 88 4428
18:44:15 1935 36 1899 18 88 4428
18:44:16 89 34 55 18 88 4428この場合、ページキャッシュのMISSESはそれほど多くないため、キャッシュサイズが適切であることを示しています。これらのメトリックは、Cassandraノードの「ホット」データセットの最も直接的な測定値です。キャッシュが不足している場合、MISSESが高くなり、パフォーマンスが低下します。キャッシュが十分にある場合、MISSESは低くなり、パフォーマンスは高速になります（ほとんどすべての読み取りがメモリから提供されるため）。
biolatency（biolatencyの例）を使用してディスクレイテンシ分布を測定し、読み取りがOSページキャッシュをミスしてディスクにアクセスする必要がある場合にCassandraがどれほど遅くなるかを知ることができます。
$ sudo /usr/share/bcc/tools/biolatency -D 10
Tracing block device I/O... Hit Ctrl-C to end.
disk = 'sda'
usecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 12 |****************************************|
32 -> 63 : 9 |****************************** |
64 -> 127 : 1 |*** |
128 -> 255 : 3 |********** |
256 -> 511 : 7 |*********************** |
512 -> 1023 : 2 |****** |
disk = 'sdc'
usecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 41 |************ |
128 -> 255 : 17 |***** |
256 -> 511 : 13 |*** |
512 -> 1023 : 2 | |
1024 -> 2047 : 0 | |
2048 -> 4095 : 0 | |
4096 -> 8191 : 56 |***************** |
8192 -> 16383 : 131 |****************************************|
16384 -> 32767 : 9 |** |この場合、データドライブ（sdc）のほとんどのIOは高速ですが、多くは8〜16ミリ秒かかります。
最後に、biosnoop（例）を使用してさらに深く掘り下げ、IOごとのレイテンシを確認できます。
$ sudo /usr/share/bcc/tools/biosnoop | grep java | head
0.000000000 java 17427 sdc R 3972458600 4096 13.58
0.000818000 java 17427 sdc R 3972459408 4096 0.35
0.007098000 java 17416 sdc R 3972401824 4096 5.81
0.007896000 java 17416 sdc R 3972489960 4096 0.34
0.008920000 java 17416 sdc R 3972489896 4096 0.34
0.009487000 java 17427 sdc R 3972401880 4096 0.32
0.010238000 java 17416 sdc R 3972488368 4096 0.37
0.010596000 java 17427 sdc R 3972488376 4096 0.34
0.011236000 java 17410 sdc R 3972488424 4096 0.32
0.011825000 java 17427 sdc R 3972488576 16384 0.65
... time passes
8.032687000 java 18279 sdc R 10899712 122880 3.01
8.033175000 java 18279 sdc R 10899952 8192 0.46
8.073295000 java 18279 sdc R 23384320 122880 3.01
8.073768000 java 18279 sdc R 23384560 8192 0.46biosnoopを使用すると、すべてのIOとそれらにかかる時間を確認できます。このデータを使用して、biolatencyのレイテンシ分布を作成できますが、ディスクレイテンシがパフォーマンスにどのように影響するかをよりよく理解するためにも使用できます。たとえば、この特定のドライブは、read_ahead_kbのデフォルト値（128kb）が大きいため、メモリマップ読み取りの処理に約3ミリ秒かかります。ポイント読み取りパフォーマンスを向上させるには、高速データボリューム（SSDなど）でread_ahead_kbを減らし、HDの場合は128kbなどの高い値を維持するのが適切かもしれません。トレードオフがあります。詳細については、queue-sysfsのドキュメントを参照してください。ただし、いずれにしても、biosnoopはCassandraがドライブを*どのように*使用するかを理解するのに役立ちます。
vmtouch
CassandraデータファイルのどれだけがOSによってキャッシュされているかを知りたい場合があります。この質問に答えるための優れたツールは、vmtouchです。
最初にインストールします。
$ git clone https://github.com/hoytech/vmtouch.git
$ cd vmtouch
$ make次に、Cassandraデータディレクトリで実行します。
$ ./vmtouch /var/lib/cassandra/data/
Files: 312
Directories: 92
Resident Pages: 62503/64308 244M/251M 97.2%
Elapsed: 0.005657 secondsこの場合、データセットのほぼ全体がOSページキャッシュでホットです。一般的に、読み取りがキャッシュをミスしていない限り、パーセンテージは実際には問題になりません（たとえば、cachestat）。その場合、追加のメモリがあると読み取りパフォーマンスが向上する可能性があります。
CPU Flamegraphs
Cassandraは多くの場合、多くのCPUを使用しますが、*何を*しているかを判断するのは難しい場合があります。CPU時間におけるCassandraを分析する最良の方法の1つは、CPU Flamegraphsを使用することです。これは、Cassandraコードのどの領域がCPUを使用しているかを有用な方法で表示します。これにより、コンパクションの問題を「トゥームストーンをドロップするコンパクションの問題」に絞り込んだり、問題が発生している間にCassandraが何をしているかを絞り込んだりするのに役立ちます。CPU Flamegraphsを取得するには、Java Flamegraphsの手順に従ってください。
一般的に
-
Cassandraの
jvm.options構成ファイルで-XX:+PreserveFramePointerオプションを有効にします。これはパフォーマンスへの影響はごくわずかですが、Cassandraが実際に行っていることを確認できます。 -
perfを実行してデータを取得します。 -
そのデータをFlameGraphツールセットの関連スクリプトに送信し、データをきれいなflamegraphに変換します。結果のSVG画像をブラウザまたは他の画像ブラウザで表示します。
たとえば、githubから直接クローンを作成するだけで、まずperf-map-agentをJVMの場所（/usr/lib/jvmと想定）にインストールします。
$ sudo bash
$ export JAVA_HOME=/usr/lib/jvm/java-8-oracle/
$ cd /usr/lib/jvm
$ git clone --depth=1 https://github.com/jvm-profiling-tools/perf-map-agent
$ cd perf-map-agent
$ cmake .
$ make次に、flamegraphを取得します。
$ git clone --depth=1 https://github.com/brendangregg/FlameGraph
$ sudo bash
$ cd FlameGraph
$ # Record traces of Cassandra and map symbols for all java processes
$ perf record -F 49 -a -g -p <CASSANDRA PID> -- sleep 30; ./jmaps
$ # Translate the data
$ perf script > cassandra_stacks
$ cat cassandra_stacks | ./stackcollapse-perf.pl | grep -v cpu_idle | \
./flamegraph.pl --color=java --hash > cassandra_flames.svg結果のSVGは検索可能で、ズーム可能で、一般的にブラウザを使用してイントロスペクトしやすいです。
パケットキャプチャ
問題のトラブルシューティングを行うために、Cassandraノードが*今すぐ*実行しているクエリを理解する必要がある場合があります。このような場合は、tcpdumpやWiresharkなどの信頼できるパケットキャプチャツールが、パケットキャプチャを分析するのに非常に役立ちます。WiresharkにはネイティブのCQLサポートもありますが、新しいCassandraプロトコルリリースとの互換性の問題が発生することがあります。
パケットキャプチャを取得するには、まずいくつかのパケットをキャプチャします。
$ sudo tcpdump -U -s0 -i <INTERFACE> -w cassandra.pcap -n "tcp port 9042"次に、wiresharkで開きます。
$ wireshark cassandra.pcapCQLのようなステートメントが表示されない場合は、9042に送信されるパケットを右クリック→Decode as→ポート9042のドロップダウンからCQLを選択して、CQLとしてデコードするように指示してみてください。
これを手動で行ったり、GUIを使用したりしたくない場合は、cqltraceなどを使用して、CQLパケットキャプチャの取得と解析を容易にすることもできます。
