[
https://issues.apache.org/jira/browse/CASSANDRA-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143214#comment-14143214
]
Nikolai Grigoriev commented on CASSANDRA-7949:
----------------------------------------------
Update: I have completed my last data writing test, now I have enough data to
start another phase. I did that last test with compaction strategy set to STCS
but disabled for the duration of the test. Once all writers have finished I
have re-enabled the compactions. In under one day STCS has completed the job on
all nodes, I ended up with few dozens (~40 or so) large sstables, total amount
of data about 23Tb on 15 nodes.
I have switched back to LCS this morning and immediately observed the "hockey
stick" on the pending compaction graph. Now each node reports about 8-10K of
pending compactions, they are all compacting in one stream per CF and consume
virtually no resources:
{code}
# nodetool compactionstats
pending tasks: 9900
compaction type keyspace table completed
total unit progress
Compaction testks test_list2 26630083587
812539331642 bytes 3.28%
Compaction testks test_list1 24071738534
1994877844635 bytes 1.21%
Active compaction remaining time : 2h16m55s
# w
13:41:45 up 23 days, 18:13, 2 users, load average: 1.81, 2.13, 2.51
...
# iostat -mdx 5
Linux 3.8.13-44.el6uek.x86_64 (cassandra01.mydomain.com) 22/09/14
_x86_64_ (32 CPU)
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz
avgqu-sz await svctm %util
sdb 0.00 5.73 88.00 13.33 5.47 5.16 214.84
0.51 5.08 0.39 3.98
sda 0.00 8.16 0.13 65.80 0.00 3.28 101.80
0.06 0.87 0.11 0.71
sdc 0.00 4.93 75.05 13.34 4.67 5.42 233.62
0.49 5.55 0.39 3.42
sdd 0.00 5.82 86.40 14.10 5.37 5.52 221.83
0.56 5.59 0.38 3.81
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz
avgqu-sz await svctm %util
sdb 0.00 0.00 134.60 0.00 8.37 0.00 127.30
0.06 0.42 0.42 5.64
sda 0.00 13.00 0.00 220.40 0.00 0.96 8.94
0.01 0.05 0.01 0.32
sdc 0.00 0.00 36.40 0.00 2.27 0.00 128.00
0.01 0.41 0.41 1.50
sdd 0.00 0.00 21.20 0.00 1.32 0.00 128.00
0.00 0.19 0.19 0.40
{code}
> LCS compaction low performance, many pending compactions, nodes are almost
> idle
> -------------------------------------------------------------------------------
>
> Key: CASSANDRA-7949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7949
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.1-1, Cassandra 2.0.8
> Reporter: Nikolai Grigoriev
> Attachments: iostats.txt, nodetool_compactionstats.txt,
> nodetool_tpstats.txt, pending compactions 2day.png, system.log.gz, vmstat.txt
>
>
> I've been evaluating new cluster of 15 nodes (32 core, 6x800Gb SSD disks +
> 2x600Gb SAS, 128Gb RAM, OEL 6.5) and I've built a simulator that creates the
> load similar to the load in our future product. Before running the simulator
> I had to pre-generate enough data. This was done using Java code and DataStax
> Java driver. To avoid going deep into details, two tables have been
> generated. Each table currently has about 55M rows and between few dozens and
> few thousands of columns in each row.
> This data generation process was generating massive amount of non-overlapping
> data. Thus, the activity was write-only and highly parallel. This is not the
> type of the traffic that the system will have ultimately to deal with, it
> will be mix of reads and updates to the existing data in the future. This is
> just to explain the choice of LCS, not mentioning the expensive SSD disk
> space.
> At some point while generating the data I have noticed that the compactions
> started to pile up. I knew that I was overloading the cluster but I still
> wanted the genration test to complete. I was expecting to give the cluster
> enough time to finish the pending compactions and get ready for real traffic.
> However, after the storm of write requests have been stopped I have noticed
> that the number of pending compactions remained constant (and even climbed up
> a little bit) on all nodes. After trying to tune some parameters (like
> setting the compaction bandwidth cap to 0) I have noticed a strange pattern:
> the nodes were compacting one of the CFs in a single stream using virtually
> no CPU and no disk I/O. This process was taking hours. After that it would be
> followed by a short burst of few dozens of compactions running in parallel
> (CPU at 2000%, some disk I/O - up to 10-20%) and then getting stuck again for
> many hours doing one compaction at time. So it looks like this:
> # nodetool compactionstats
> pending tasks: 3351
> compaction type keyspace table completed
> total unit progress
> Compaction myks table_list1 66499295588
> 1910515889913 bytes 3.48%
> Active compaction remaining time : n/a
> # df -h
> ...
> /dev/sdb 1.5T 637G 854G 43% /cassandra-data/disk1
> /dev/sdc 1.5T 425G 1.1T 29% /cassandra-data/disk2
> /dev/sdd 1.5T 429G 1.1T 29% /cassandra-data/disk3
> # find . -name **table_list1**Data** | grep -v snapshot | wc -l
> 1310
> Among these files I see:
> 1043 files of 161Mb (my sstable size is 160Mb)
> 9 large files - 3 between 1 and 2Gb, 3 of 5-8Gb, 55Gb, 70Gb and 370Gb
> 263 files of various sized - between few dozens of Kb and 160Mb
> I've been running the heavy load for about 1,5days and it's been close to 3
> days after that and the number of pending compactions does not go down.
> I have applied one of the not-so-obvious recommendations to disable
> multithreaded compactions and that seems to be helping a bit - I see some
> nodes started to have fewer pending compactions. About half of the cluster,
> in fact. But even there I see they are sitting idle most of the time lazily
> compacting in one stream with CPU at ~140% and occasionally doing the bursts
> of compaction work for few minutes.
> I am wondering if this is really a bug or something in the LCS logic that
> would manifest itself only in such an edge case scenario where I have loaded
> lots of unique data quickly.
> By the way, I see this pattern only for one of two tables - the one that has
> about 4 times more data than another (space-wise, number of rows is the
> same). Looks like all these pending compactions are really only for that
> larger table.
> I'll be attaching the relevant logs shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
