Is my cluster normal?

CassandraのMLにて表題のような面白いスレッドがありましたので試みに翻訳してみようと思います。


I have a cluster of 4 m4.xlarge nodes(4 cpus and 16 gb memory and 600GB ssd EBS).
I can reach a cluster wide write requests of 30k/second and read request about 100/second.
The cluster OS load constantly above 10.
Are those normal?

私は4つのm4.xlargeノード(4個のCPUと16ギガバイトのメモリと600ギガバイトSSDのEBS)のクラスタを持っています。
クラスタ全体への書き込み要求は30K/秒に、読み込み要求は100/秒に達します。
クラスターOSのロードは常に10以上になります。
これは正常ですか?


Assuming you meant 100k, that likely for something with 16mb of storage (probably way small)
where the data is more that 64k hence will not fit into the row cache.

あなたの意味するものが100kであった場合、おそらく、むしろ後にデータがその64kである16mb(おそらく小さい方法)の
ストレージを持つ何かのため行キャッシュに収まりません。


writes 30k/second is the main thing.

30K /秒の書き込みが主です。


Are you saying 7k writes per node? or 30k writes per node?

あなたの言っている意味はノードごとに7Kの書き込みですかそれとも30kの書き込みですか?


yes, it is about 8k writes per node.

はい、それは、ノードあたり約8kの書き込みです。


Lots of variables you're leaving out.

Depends on write size, if you're using logged batch or not, what consistency level, what RF, if the writes come in bursts, etc, etc.
However, that's all sort of moot for determining "normal" really you need a baseline as all those variables end up mattering a huge amount.

I would suggest using Cassandra stress as a baseline and go from there depending on what those numbers say (just pick the defaults).

たくさんの情報が欠落しています。

書き込みのサイズ、Batch文を使用しているか、コンシステンシーレベル、
レプリケーションファクター、書き込みがバーストしているかなどなどたくさんの部分に依存します。
しかし、これらはあなたが最終的にそれらの項目において決定づけられる莫大な量の
ベースラインとして本当に必要とするノーマルかを決定する議題の一つです。

私はベースラインとしてカサンドラストレスを使用することをお勧めし、これらの数字は、
(単にデフォルトを選ぶ)言うことに応じて、そこから話を進めます。


Yes, here is my stress test result:
Results:
op rate : 12200 [WRITE:12200]
partition rate : 12200 [WRITE:12200]
row rate : 12200 [WRITE:12200]
latency mean : 16.4 [WRITE:16.4]
latency median : 7.1 [WRITE:7.1]
latency 95th percentile : 38.1 [WRITE:38.1]
latency 99th percentile : 204.3 [WRITE:204.3]
latency 99.9th percentile : 465.9 [WRITE:465.9]
latency max : 1408.4 [WRITE:1408.4]
Total partitions : 1000000 [WRITE:1000000]
Total errors : 0 [WRITE:0]
total gc count : 0
total gc mb : 0
total gc time (s) : 0
avg gc time(ms) : NaN
stdev gc time(ms) : 0
Total operation time : 00:01:21
END

はい、これがストレステストの結果です。
~省略~


You might find this blog post a useful comparison:
https://www.instaclustr.com/blog/2016/01/07/multi-data-center-apache-spark-and-apache-cassandra-benchmark/

Although the focus is on Spark and Cassandra and multi-DC there are also some single DC benchmarks of m4.xl clusters plus some discussion of how we went about benchmarking.

あなたにとってこのブログの投稿は便利な比較かもしれません。
https://www.instaclustr.com/blog/2016/01/07/multi-data-center-apache-spark-and-apache-cassandra-benchmark/

フォーカスがスパークと、カサンドラとマルチDCですが、m4.xl クラスタのいくつかの
シングルDCでのベンチマークと、私たちのベンチマークを実行した際の考察を含んでいます。


For the post, it seems they got a little better but similar result than i did. Good to know it.
I am not sure if a little fine tuning of heap memory will help or not.

投稿によって、それは彼らが私がやったよりも良い少しも同様の結果を得たようです。
それが知れて嬉しいです。
私は、ヒープメモリのチューニングを行うべきかどうかわかりません。


what version of cassandra and java?

CassandraとJavaのバージョンは?


The version of cassandra is 3.0.6 and
java version "1.8.0_91"

Cassandraは 3.0.6で
Javaは"1.8.0_91" です。


You machine instance is 4 vcpus that is 4 threads (not cores!!!),
aside from any Cassandra specific discussion a system load of 10 on a 4 threads machine is way too much in my opinion.
If that is the running average system load I would look deeper into system details.
Is that IO wait? Is that CPU Stolen?
Is that a Cassandra only instance or are there other processes pushing the load?
What does your "nodetool tpstats" say?
How many dropped messages do you have?

あなたのインスタンスは、4つのvcpuで4つのスレッドが実行できます。(コアではありません!!!)
Cassandra固有の議論は別として、私の意見としては4スレッド上の10のシステムロードは非常に多い使用方法です。
もしそれが平均的なシステムロードであるなら、私はシステム詳細により深く見るでしょう。
そのIO待ちはそうであるか?
CPUのリソースが盗めれていないか?
それはCassandraのインスタンスだけ か、またはロードを押し上げている他のプロセスがあるか?
あなたの「nodetool tpstats」は何といっているか?
あなたは、いくつのドロップメッセージを持っているか?.


Very low IO-wait. About 0.3%.
No stolen CPU. It is a casssandra only instance. I did not see any dropped messages.

ubuntu@cassandra1:/mnt/data$ nodetool tpstats
Pool Name Active Pending Completed Blocked All time blocked
MutationStage 1 1 929509244 0 0
ViewMutationStage 0 0 0 0 0
ReadStage 4 0 4021570 0 0
RequestResponseStage 0 0 731477999 0 0
ReadRepairStage 0 0 165603 0 0
CounterMutationStage 0 0 0 0 0
MiscStage 0 0 0 0 0
CompactionExecutor 2 55 92022 0 0
MemtableReclaimMemory 0 0 1736 0 0
PendingRangeCalculator 0 0 6 0 0
GossipStage 0 0 345474 0 0
SecondaryIndexManagement 0 0 0 0 0
HintsDispatcher 0 0 4 0 0
MigrationStage 0 0 35 0 0
MemtablePostFlush 0 0 1973 0 0
ValidationExecutor 0 0 0 0 0
Sampler 0 0 0 0 0
MemtableFlushWriter 0 0 1736 0 0
InternalResponseStage 0 0 5311 0 0
AntiEntropyStage 0 0 0 0 0
CacheCleanupExecutor 0 0 0 0 0
Native-Transport-Requests 128 128 347508531 2 15891862

Message type Dropped
READ 0
RANGE_SLICE 0
_TRACE 0
HINT 0
MUTATION 0
COUNTER_MUTATION 0
BATCH_STORE 0
BATCH_REMOVE 0
REQUEST_RESPONSE 0
PAGED_RANGE 0
READ_REPAIR 0

0.3%程度の非常に低い IO wait です。
いいえ盗まれたCPUはありません。それはcasssandra唯一のインスタンスです。
ドロップされたメッセージも表示されませんでした。

~省略~


What's your CPU looking like? If it's low, check your IO with iostat or dstat.
I know some people have used Ebs and say it's fine but ive been burned too many times.

あなたのCPUはどのようにみえていますか?
それが低いなら、iostatかdstatであなたのIOを確認してください。
私は人々がEBSを使用している事を知っています。
彼らはEBSは良いけれども、たびたび炎上するとも言っています。


The IOs are like below. I am not sure why one node always has a much bigger KB_read/s than other nodes. It seems not good.

==============
avg-cpu: %user %nice %system %iowait %steal %idle
54.78 24.48 9.35 0.96 0.08 10.35

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 2.31 14.64 17.95 1415348 1734856
xvdf 252.68 11789.51 6394.15 1139459318 617996710

=============

avg-cpu: %user %nice %system %iowait %steal %idle
22.71 6.57 3.96 0.50 0.19 66.07

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 1.12 3.63 10.59 3993540 11648848
xvdf 68.20 923.51 2526.86 1016095212 2780187819

===============
avg-cpu: %user %nice %system %iowait %steal %idle
22.31 8.08 3.70 0.26 0.23 65.42

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 1.07 2.87 10.89 3153996 11976704
xvdf 34.48 498.21 2293.70 547844196 2522227746

================
avg-cpu: %user %nice %system %iowait %steal %idle
22.75 8.13 3.82 0.36 0.21 64.73

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 1.10 3.20 11.33 3515752 12442344
xvdf 44.45 474.30 2511.71 520758840 2757732583

IOSは以下のようなものです。私は1つのノードが常に他のノードよりもはるかに大きいKB_read /秒を持っている理由はわかりません。それは良くないようです。

==============
~省略~


EBS iops scale with volume size.

A 600G EBS volume only guarantees 1800 iops – if you’re exhausting those on writes, you’re going to suffer on reads.

You have a 16G server, and probably a good chunk of that allocated to heap.
Consequently, you have almost no page cache, so your reads are going to hit the disk.
Your reads being very low is not uncommon if you have no page cache
– the default settings for Cassandra (64k compression chunks) are really inefficient for small reads served off of disk.
If you drop the compression chunk size (4k, for example), you’ll probably see your read throughput increase significantly,
which will give you more iops for commitlog, so write throughput likely goes up, too.

EBSのIOPSは、ボリュームのサイズに比例します。

600G EBSボリュームは1800 IOPSを保証します。 -あなたは書き込み時にそれらを使いつくしている場合は、読み込みに苦しむことになるでしょう。

あなたは16Gサーバ、およびヒープに割り当てられているのはおそらくかなりの部分を持っています。
そのため、あなたはほとんどページのキャッシュを持っていないので、あなたの読み込みは、直接ディスクを読み込みます。
ページキャッシュを持っていない場合は、読み込みが非常に低いということは珍しいことではありません
― カサンドラのデフォルト設定(64kの圧縮サイズ)は、ディスク外で提供される小さい読み込みに対して本当に非効率的です。
圧縮チャンクサイズ(例えば4K)を小さくした場合は、Commitlog により多くのIOPSが適用されるので、大幅に読み取りスループットが増加するでしょう。
また、書き込みのスループットもおそらく上がります。


The read being low is because we do not have much read operations right now.
The heap is only 4GB.
MAX_HEAP_SIZE=4GB

私たちは今、あまり読み込み処理をしていないので、読み込みは低いです。。
ヒープは4GBです。
MAX_HEAP_SIZE=4GB


Those numbers, as I suspected, line up pretty well with your AWS configuration and network latencies within AWS.
It is clear that this is a WRITE ONLY test. You might want to do a mixed (e.g. 50% read, 50% write) test for sanity.
Note that the test will populate the data BEFORE it begins doing the read/write tests.

In a dedicated environment at a recent client, with 10gbit links (just grabbing one casstest run from my archives)
I see less than twice the above. Note your latency max is the result of a stop-the-world garbage collection.
There were huge problems below because this particular run was using 24gb (Cassandra 2.x) java heap.

op rate : 21567 [WRITE:21567]
partition rate : 21567 [WRITE:21567]
row rate : 21567 [WRITE:21567]
latency mean : 9.3 [WRITE:9.3]
latency median : 7.7 [WRITE:7.7]
latency 95th percentile : 13.2 [WRITE:13.2]
latency 99th percentile : 32.6 [WRITE:32.6]
latency 99.9th percentile : 97.2 [WRITE:97.2]
latency max : 14906.1 [WRITE:14906.1]
Total partitions : 83333333 [WRITE:83333333]
Total errors : 0 [WRITE:0]
total gc count : 705
total gc mb : 1691132
total gc time (s) : 30
avg gc time(ms) : 43
stdev gc time(ms) : 13
Total operation time : 01:04:23

私が疑われるとしてこれらの数字は、AWS内のあなたのAWSの構成やネットワーク遅延などとかなりよく並びます。
これらは書き込みのみのテストであることは明らかです。あなたは正常のための混合(例えば、50%リード、50%ライト)テストを
実行したかもしれません。それは読み取り/書き込みテストを開始する前にテストデータを移入することに注意してください。

最近のクライアントに専用の環境では、10ギガビットリンクと共に(まさに、1つの私のアーカイブから動かされた「Cassandra Test」をつかんだ)私は上記の2倍未満だと思います。あなたの待ち時間maxはガベージコレクションのストップワールドの結果であることに注意してください。
この特定の実行が24ギガバイト(カサンドラ2.xの)Javaヒープを使用して実行されていたので、巨大な問題がありました。

~省略~


Can do you do:
iostat -dmx 2 10

これを実行できますか?:
iostat -dmx 2 10


When you have high system load it means your CPU is waiting for *something*, and in my experience it's usually slow disk.
A disk connected over network has been a culprit for me many times.

あなたが高いシステム負荷を持っているとき、それはあなたのCPUは*何か*を待っていることを意味し、私の経験では、通常、遅いディスクです。
ネットワークを介して接続されたディスクは、多くの場合犯人になっています。


While I'm surprised you don't have any dropped message I have to point the finger against the following tpstats line:

Native-Transport-Requests 128 128 347508531 2 15891862

where the the first '128' are the active reuests and the second '128' are the pending ones.
Might not be strictly related, however this might be of interest:

ASF JIRA

there's a chance that tuning the 'native_transport_*' related options can mitigate/solve the issue.

私が、あなたが、Dropメッセージも持っていないことに驚く間、私は以下のtpstatsラインを指摘する必要がります。
Native-Transport-Requests 128 128 347508531 2 15891862

最初の'128'は、アクティブリクエストであり、2番目の「128」は、保留中のものです。
ここで、厳密に関連しないかもしれませんが、これは参考になります。

ASF JIRA

緩和、もしくは問題を解決することができる「native_transport_ * 」関連のオプションを調整することが出来ます。


Here is the result:

ubuntu@ip-172-31-44-250:~$ iostat -dmx 2 10
Linux 3.13.0-74-generic (ip-172-31-44-250) 07/12/2016 _x86_64_ (4 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
xvda 0.01 2.13 0.74 1.55 0.01 0.02 27.77 0.00 0.74 0.89 0.66 0.43 0.10
xvdf 0.01 0.58 237.41 52.50 12.90 6.21 135.02 2.32 8.01 3.65 27.72 0.57 16.63

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 7.50 0.00 2.50 0.00 0.04 32.00 0.00 1.60 0.00 1.60 1.60 0.40
xvdf 0.00 0.00 353.50 0.00 24.12 0.00 139.75 0.49 1.37 1.37 0.00 0.58 20.60

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.00 0.00 1.00 0.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 2.00 463.50 35.00 30.69 2.86 137.84 0.88 1.77 1.29 8.17 0.60 30.00

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.00 0.00 1.00 0.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 0.00 99.50 36.00 8.54 4.40 195.62 1.55 3.88 1.45 10.61 1.06 14.40

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 5.00 0.00 1.50 0.00 0.03 34.67 0.00 1.33 0.00 1.33 1.33 0.20
xvdf 0.00 1.50 703.00 195.00 48.83 23.76 165.57 6.49 8.36 1.66 32.51 0.55 49.80

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.00 0.00 1.00 0.00 0.04 72.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 2.50 149.50 69.50 10.12 6.68 157.14 0.74 3.42 1.18 8.23 0.51 11.20

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 5.00 0.00 2.50 0.00 0.03 24.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 0.00 61.50 22.50 5.36 2.75 197.64 0.33 3.93 1.50 10.58 0.88 7.40

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.00 0.00 0.50 0.00 0.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 0.00 375.00 0.00 24.84 0.00 135.64 0.45 1.20 1.20 0.00 0.57 21.20

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 1.00 0.00 6.00 0.00 0.03 9.33 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 0.00 542.50 23.50 35.08 2.83 137.16 0.80 1.41 1.15 7.23 0.49 28.00

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 3.50 0.50 1.50 0.00 0.02 24.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdf 0.00 1.50 272.00 153.50 16.18 18.67 167.73 14.32 33.66 1.39 90.84 0.81 34.60

これが結果です。:

~省略~


$nodetool tpstats
...
Pool Name Active Pending Completed Blocked All time blocked
Native-Transport-Requests 128 128 1420623949 1 142821509
...
What is this? Is it normal?

$nodetool tpstats
...
Pool Name Active Pending Completed Blocked All time blocked
Native-Transport-Requests 128 128 1420623949 1 142821509
...
これは何ですか?
これは正常ですか?


In addition, it seems the compaction is very often.
It happens like every couple of seconds and one after one.
It seems causing high load.

加えて、頻繁にコンパクションが実行されているように思えます。
それは各実行ごとに毎秒毎に実行されます。
それは、高いロードの原因になると思います。


Sometimes, the Pending can change from 128 to 129, 125 etc.

時には、保留中は、128から129や125などにに代わることがあります。


Same behavior here with a very different setup.
After an upgrade to 2.1.14 (from 2.0.17) I see a high load and many NTR "all time blocked".
Offheap memtable lowered the blocked NTR for me,
I put a comment on CASSANDRA-11363

非常に違うセットアップを持つこの場所の同じ動作です。
2.1.14 ( 2.0.17からの)へのアップグレードの後に、私は、高いロードと、「いつもブロックしている」という多くのNative-Transport-Requestsを見ます。
Offheapにあるmemtalbeは、ブロックされたNTRを低下させます。
私はコメントをCASSANDRA-11363に書いています。

現在もThreadは続きそうなので追加され次第更新していきます。