Issues with Scaling horizontally with Cassandra NoSQL - cassandra

I am trying to configure and benchmark my AWS EC2 instances for Cassandra distributions with Datstax Community Edition. I'm working with 1 cluster so far, and I'm having issues with the horizontal scaling.
I'm running cassandra-stress tool to stress the nodes and I'm not seeing the horizontal scaling. My command is run under an EC2 instance that is on the same network as the nodes but not on the node (ie i'm not using one of the node to launch the command)
I have inputted the following:
cassandra-stress write n=1000000 cl=one -mode native cql3 -schema keyspace="keyspace1" -pop seq=1..1000000 -node ip1,ip2
I started with 2 nodes, and then 3, and then 6. But the numbers don't tell me what Cassandra is suppose to do: more nodes to a cluster should speed up read/write.
Results: 2 Nodes: 1M 3 Nodes: 1M 3 Nodes: 2M 6 Nodes: 1M 6 Nodes: 2M 6 Nodes: 6M 6 Nodes: 10M
op rate 6858 6049 6804 7711 7257 7531 8081
partition rate 6858 6049 6804 7711 7257 7531 8081
row rate 6858 6049 6804 7711 7257 7531 8081
latency mean 29.1 33 29.3 25.9 27.5 26.5 24.7
latency median 24.9 32.1 24 22.6 23.1 21.8 21.5
latency 95th percentile 57.9 73.3 62 50 56.2 52.1 40.2
latency 99th percentile 76 92.2 77.4 65.3 69.1 61.8 46.4
latency 99.9th percentile 87 103.4 83.5 76.2 75.7 64.9 48.1
latency max 561.1 587.1 1075 503.1 521.7 1662.3 590.3
total gc count 0 0 0 0 0 0 0
total gc mb 0 0 0 0 0 0 0
total gc time (s) 0 0 0 0 0 0 0
avg gc time(ms) NAN NaN NaN NaN NaN NaN NaN
stdev gc time(ms) 0 0 0 0 0 0 0
Total operation time 0:02:25 0:02:45 0:04:53 0:02:09 00:04.35 0:13:16 0:20:37
Each with the default keyspace1 that was provided.
I've tested at 3 Nodes: 1M, 2M iteration. 6 Nodes I've tried 1M,2M, 6M, and 10M. As I increased Iteration I'm marginally increasing the OP Rate.
Am I doing something wrong or do I have Cassandra backward. Right now RF = 1 as I don't want to insert latency for replications. I Just want to see in the longterm the horizontal scaling which I'm not seeing it.
Help?

Related

Spark not giving equal tasks to all executors

I am reading from kafka topic which has 5 partitions. Since 5 cores are not sufficient to handle the load, I am doing repartitioning the input to 30. I have given 30 cores to my spark process with 6 cores on each executor. With this setup i was assuming that each executor will get 6 tasks. But more oftan than not we are seeing that one executor is getting 4 tasks and others are getting 7 tasks. It is skewing the processing time of our job.
Can someone help me understand why all the executor will not get equal number of tasks? Here is the executor metrics after job has run for 12 hours.
Address
Status
RDD Blocks
Storage Memory
Disk Used
Cores
Active Tasks
Failed Tasks
Complete Tasks
Total Tasks
Task Time (GC Time)
Input
Shuffle Read
Shuffle Write
ip1:36759
Active
7
1.6 MB / 144.7 MB
0.0 B
6
6
0
442506
442512
35.9 h (26 min)
42.1 GB
25.9 GB
24.7 GB
ip2:36689
Active
0
0.0 B / 128 MB
0.0 B
0
0
0
0
0
0 ms (0 ms)
0.0 B
0.0 B
0.0 B
ip5:44481
Active
7
1.6 MB / 144.7 MB
0.0 B
6
6
0
399948
399954
29.0 h (20 min)
37.3 GB
22.8 GB
24.7 GB
ip1:33187
Active
7
1.5 MB / 144.7 MB
0.0 B
6
5
0
445720
445725
35.9 h (26 min)
42.4 GB
26 GB
24.7 GB
ip3:34935
Active
7
1.6 MB / 144.7 MB
0.0 B
6
6
0
427950
427956
33.8 h (23 min)
40.5 GB
24.8 GB
24.7 GB
ip4:38851
Active
7
1.7 MB / 144.7 MB
0.0 B
6
6
0
410276
410282
31.6 h (24 min)
39 GB
23.9 GB
24.7 GB
If you see there is a skew in number of tasks completed by ip5:44481. I dont see abnormal GC activity as well.
What metrics should i be looking at to understand this skew?
UPDATE
Upon further debugging I can see that all the partitions are having unequal data. And all the tasks are given approx same number of records.
Executor ID
Address
Task Time
Total Tasks
Failed Tasks
Killed Tasks
Succeeded Tasks
Shuffle Read Size / Records
Blacklisted
0stdoutstderr
ip3:37049
0.8 s
6
0
0
6
600.9 KB / 272
FALSE
1stdoutstderr
ip1:37875
0.6 s
6
0
0
6
612.2 KB / 273
FALSE
2stdoutstderr
ip3:41739
0.7 s
5
0
0
5
529.0 KB / 226
FALSE
3stdoutstderr
ip2:38269
0.5 s
6
0
0
6
623.4 KB / 272
FALSE
4stdoutstderr
ip1:40083
0.6 s
7
0
0
7
726.7 KB / 318
FALSE
This is the stats of stage just after repartitioning. We can see that number of tasks are proportional to number of records. As a next step I am trying to see how the partition function is working.
Update 2:
The only explanation i have come across is spark uses round robin partitioning. And It is indepandently executed on each partition. For example if there are 5 records on node1 and 7 records on node2. Node1's round robin will distribute approximately 3 records to node1, and approximately 2 records to node2. Node2's round robin will distribute approximately 4 records to node1, and approximately 3 records to node2. So, there is the possibility of having 7 records on node1 and 5 records on node2, depending on the ordering of the nodes that is interpreted within the framework code for each individual node. source
NOTE:
if you notice the best performing guys are on same ip. Is it because after shuffling transferring data on same host is faster? compared to other ip?
Based on above data we can see that repartition is working fine, i.e. assigning equal number of records to 30 partitions, but the question is why is some executors getting more partition than others.

Understand output of vmstat memory utilization

I have a solaris box and im trying to know whether its running out of memory or if its stable.
below is the output of vmstat.
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr vc vc vc vc in sy cs us sy id
1 0 0 11426696 4603520 613 1477 449 6 6 0 0 78 22 28 29 8970 37714 22961 43 6 51
4 0 0 4975280 0 1747 3487 805 0 0 0 0 233 41 33 44 9558 53713 15845 74 8 18
4 0 0 4936944 0 933 1837 0 0 0 0 0 56 28 12 39 9317 46898 14648 82 7 11
5 0 0 4943080 0 1056 2806 805 0 0 0 0 103 21 18 18 9286 46900 14866 78 8 14
5 0 0 4942264 0 1088 2173 804 6 6 0 0 109 8 40 31 9927 56484 16495 84 8 8
3 0 0 4942520 0 308 1018 1756 3 3 0 0 166 87 29 44 10638 64146 21413 83 9 8
0 0 0 4942512 0 156 326 1740 0 0 0 0 370 12 33 52 11554 40375 21897 75 9 16
2 0 0 4947384 0 294 560 845 0 0 0 0 121 18 23 20 9445 52382 17016 77 6 17
I can see the free column shows 0 however the sr column also shows 0
And output from top command doesn't show how much free memory available. Swap shows 0.0%
load averages: 11.4, 9.12, 9.24;
9021 processes: 9018 sleeping, 1 running, 2 on cpu
CPU states: 0.0% idle, 71.4% user, 28.6% kernel, 0.0% iowait, 0.0% swap
Memory: 24G phys mem, 16G total swap, 13G free swap
Am i running out of RAM?
Please suggest how to interpret this data. Do i need to increase my physical memory?
Appreciate some insights.
From the Solaris 11.4 vmstat man page, there's one important thing to note:
Without options, vmstat displays a one-line summary of the virtual memory activity since the system was booted.
That also applies to the first line of output from Solaris vmstat: it's a summary of all activity since the system was booted.
A good description of the output fields is found in the EXAMPLES section of the Solaris man vmstat page:
Examples
Example 1 Using vmstat
The following command displays a summary of what the system is doing
every five seconds.
example% vmstat 5
kthr memory page disk faults cpu
r b w swap free re mf pi p fr de sr s0 s1 s2 s3 in sy cs us sy id
0 0 0 11456 4120 1 41 19 1 3 0 2 0 4 0 0 48 112 130 4 14 82
0 0 1 10132 4280 0 4 44 0 0 0 0 0 23 0 0 211 230 144 3 35 62
0 0 1 10132 4616 0 0 20 0 0 0 0 0 19 0 0 150 172 146 3 33 64
0 0 1 10132 5292 0 0 9 0 0 0 0 0 21 0 0 165 105 130 1 21 78
1 1 1 10132 5496 0 0 5 0 0 0 0 0 23 0 0 183 92 134 1 20 79
1 0 1 10132 5564 0 0 25 0 0 0 0 0 18 0 0 131 231 116 4 34 62
1 0 1 10124 5412 0 0 37 0 0 0 0 0 22 0 0 166 179 118 1 33 67
1 0 1 10124 5236 0 0 24 0 0 0 0 0 14 0 0 109 243 113 4 56 39
example%
The fields of vmstat's display are
kthr
Report the number of kernel threads in each of the three following
states:
r
the number of kernel threads in run queue
b
the number of blocked kernel threads that are waiting for
resources I/O, paging, and so forth
w
the number of swapped out lightweight processes (LWPs) that
are waiting for processing resources to finish.
memory
Report on usage of virtual and real memory.
swap
available swap space (Kbytes)
free
size of the free list (Kbytes)
page
Report information about page faults and paging activity. The
information on each of the following activities is given in units per
second.
re
page reclaims — but see the –S option for how this field is modified.
mf
minor faults — but see the –S option for how this field is modified.
pi
kilobytes paged in
po
kilobytes paged out
fr
kilobytes freed
de
anticipated short-term memory shortfall (Kbytes)
sr
pages scanned by clock algorithm
When executed in a zone and if the pools facility is active, all of
the above (except for ‘de’) only report activity on the processors in
the processor set of the zone's pool.
disk
Report the number of disk operations per second. There are slots for
up to four disks, labeled with a single letter and number. The letter
indicates the type of disk (s = SCSI, i = IPI, and so forth); the
number is the logical unit number.
faults
Report the trap/interrupt rates (per second).
in
interrupts
sy
system calls
cs
CPU context switches
When executed in a zone and if the pools facility is active, all of
the above only report activity on the processors in the processor set
of the zone's pool.
cpu
Give a breakdown of percentage usage of CPU time. On MP systems, this
is an average across all processors.
us
user time
sy
system time
id
idle time
When executed in a zone and if the pools facility is active, all of
the above only report activity on the processors in the processor set
of the zone's pool.
This can help you https://www.howtogeek.com/424334/how-to-use-the-vmstat-command-on-linux/. There is explanation of those shorts.
Memory
swpd: the amount of virtual memory used. In other words, how much memory has been swapped out.,
free: the amount of idle (currently unused) memory.
buff: the amount of memory used as buffers.
cache: the amount of memory used as cache.
Swap
si: Amount of virtual memory swapped in from swap space.
so: Amount of virtual memory swapped out to swap space.
IO
bi: Blocks received from a block device. The number of data blocks used to swap virtual memory back into RAM.
bo: Blocks sent to a block device. The number of data blocks used to swap virtual memory out of RAM and into swap space.
System
in: The number of interrupts per second, including the clock.
cs: The number of context switches per second. A context switch is when the kernel swaps from system mode processing into user mode processing.
"0" is not a valid free memory value.
By design, Solaris always makes sure a minimal amount of free memory is available. The fact the sr column is also equals to zero suggests there is no memory shortage. In any case, you wouldn't have been able to run vmstat or top in the first place with such an extreme RAM shortage.
You should investigate further to understand why the free memory is reported a zero. mdb's ::memstat command would be a good start:
# echo "::memstat" | mdb -k

Some Spark Tasks In a Stage take much longer than others

I have a spark sql query that look like this:
val stats = readings
.join(stations, $"r.stationId" === $"i.stationId")
.groupBy($"i.country", $"r.date")
.agg(min($"r.temp").as("min"), max($"r.temp").as("max"), avg($"r.temp").as("avg"))
.as[CountryTemperatureDistribution]
When I run this over my dataset some of the tasks in the longest running stage take far longer to run than others. For example the summary in the spark ui is:
Index ID Executor ID Launch Time Duration GC Time Input Sze / Rec Write Time Shuffle Write Size / Rec
2 5 0 / 10.1.0.6 12:36:38 12 s 1 s 14.4 MB / 9287283 2 s 3.7 MB / 138847
3 6 2 / 10.1.0.4 12:36:38 17 s 2 s 0.0 B / 9273044 0.4 s 3.8 MB / 141888
5 8 0 / 10.1.0.6 12:36:38 22 s 1 s 14.5 MB / 9064853 1 s 5.6 MB / 206393
0 3 2 / 10.1.0.4 12:36:38 23 s 2 s 0.0 B / 9290667 0.3 s 4.1 MB / 157233
6 9 2 / 10.1.0.4 12:36:38 23 s 2 s 0.0 B / 9233245 0.2 s 4.1 MB / 158441
1 4 1 / 10.1.0.5 12:36:38 24 s 3 s 14.5 MB / 9289969 1 s 3.9 MB / 149370
4 7 1 / 10.1.0.5 12:36:38 24 s 3 s 14.8 MB / 9250565 1 s 4.0 MB / 154438
10 13 1 / 10.1.0.5 12:36:38 1.5 min 3 s 14.1 MB / 8734757 0.3 s 6.3 MB / 234829
12 15 0 / 10.1.0.6 12:36:50 2.3 min 88 ms 7.3 MB / 4338998 0.5 s 4.8 MB / 177381
9 12 2 / 10.1.0.4 12:36:38 3.1 min 2 s 0.0 B / 8242837 0.1 s 8.2 MB / 301212
8 11 0 / 10.1.0.6 12:36:38 7.3 min 2 s 13.1 MB / 8346974 0.4 s 7.6 MB / 277488
11 14 0 / 10.1.0.6 12:36:38 7.6 min 2 s 13.0 MB / 7950142 0.1 s 7.3 MB / 262211
7 10 1 / 10.1.0.5 12:36:38 8.4 min 3 s 15.2 MB / 9347698 0.1 s 8.2 MB / 292230
based on this some tasks complete in seconds, while others take several minutes. I'm trying to rule out data skew (my group by shouldn't produce skewed data), but if this was data skew presumably the slower jobs would have a much a larger input size than the faster ones (which they don't).
Another oddity is that sever jobs (even ones which take several minutes to complete) have an input size of 0B but a non-zero input records?!
TLDR: why do some of my taks take much longer to compete than others?

How to read the cassandra nodetool histograms percentile and other columns?

How to read the cassandra nodetool histograms percentile and other coulmns?
Percentile SSTables Write Latency Read Latency Partition Size Cell Count
(micros) (micros) (bytes)
50% 1.00 14.24 4055.27 149 2
75% 35.00 17.08 17436.92 149 2
95% 35.00 24.60 74975.55 642 2
98% 86.00 35.43 129557.75 770 2
99% 103.00 51.01 186563.16 770 2
Min 0.00 2.76 51.01 104 2
Max 124.00 36904729.27 12359319.16 924 2
They show the distribution of the metrics. For example, in your data the write latency for 95% of the requests were 24.60 microseconds or less. 95% of the partitions are 642 bytes or less with 2 cells. The SStables column is how many sstables are touched on a read, so 95% or read requests are looking at 35 sstables (this is fairly high).

Debian Wheezy with default Kernel (3.2.0-4-amd64) high load average

I have recently upgraded to a new machine and to Debian Wheezy.
Everything ist running fine, except that even with low actual load, the load average is too high.
Example:
14:29:35 up 9:49, 1 user, load average: 1.96, 2.22, 2.14
This happens even tho all components are at a low load (almost no I/O and all CPU Cores are <50%)
top:
top - 14:30:31 up 9:50, 1 user, load average: 2.38, 2.32, 2.18
Tasks: 156 total, 3 running, 153 sleeping, 0 stopped, 0 zombie
%Cpu(s): 28.2 us, 1.3 sy, 0.0 ni, 69.8 id, 0.4 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem: 32878740 total, 8036624 used, 24842116 free, 106544 buffers
KiB Swap: 16768892 total, 0 used, 16768892 free, 2897400 cached
iotop:
Total DISK READ: 0.00 B/s | Total DISK WRITE: 1004.39 B/s
vmstat:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 24809288 107236 2921816 0 0 10 1 102 138 17 2 81 0
1 0 0 24809364 107244 2921908 0 0 6 6 14334 15108 24 1 75 0
4 0 0 24808784 107260 2921952 0 0 2 16 14407 15222 24 1 74 0
0 0 0 24808660 107272 2922096 0 0 4 14 14570 15373 26 1 73 0
1 0 0 24808156 107280 2922220 0 0 0 13 14783 15499 27 1 72 0
2 0 0 24807420 107292 2922684 0 0 0 23 14590 15344 26 1 72 0
uname -r:
3.2.0-4-amd64
Anyone got a clue?
Load average is usually the number of process waiting for execution, as in the queue.
As it doesn't seem to be a problem with CPU and I/O, I would expect to be something like a shared memory semaphore, or a network dependent code.
Try to see what processes are with:
# top -b -n 1 | awk '{if (NR <=7) print; else if ($8 == "D") {print; count++} } END {print "Total status D: "count}'

Resources