[jira] [Updated] (CASSANDRA-14813) Crash frequently due to fatal error caused by "StubRoutines::updateBytesCRC32"
[
https://issues.apache.org/jira/browse/CASSANDRA-14813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinchao Zhang updated CASSANDRA-14813:
--
Reviewer: Ariel Weisberg (was: Jeff Jirsa)
> Crash frequently due to fatal error caused by "StubRoutines::updateBytesCRC32"
> --
>
> Key: CASSANDRA-14813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14813
> Project: Cassandra
> Issue Type: Bug
> Environment: *OS:*
> {code:java}
> CentOS release 6.9 (Final){code}
> *JAVA:*
> {noformat}
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode){noformat}
>
> *Memory:*
> {noformat}
> 256GB{noformat}
> *CPU:*
> {noformat}
> 4* Intel® Xeon® Processor E5-2620 v4{noformat}
> *DISK:*
> {noformat}
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda3 423G 28G 374G 7% /
> tmpfs 126G 68K 126G 1% /dev/shm
> /dev/sda1 240M 40M 188M 18% /boot
> /dev/sdb 3.7T 33M 3.7T 1% /mpp-data/c/cache
> /dev/sdc 3.7T 2.7T 984G 74% /mpp-data/c/data00
> /dev/sdd 3.7T 2.5T 1.2T 68% /mpp-data/c/data01
> /dev/sde 3.7T 2.7T 1.1T 72% /mpp-data/c/data02
> /dev/sdf 3.7T 2.5T 1.2T 68% /mpp-data/c/data03
> /dev/sdg 3.7T 2.4T 1.3T 66% /mpp-data/c/data04
> /dev/sdh 3.7T 2.6T 1.2T 69% /mpp-data/c/data05
> /dev/sdi 3.7T 2.6T 1.2T 70% /mpp-data/c/data06{noformat}
>Reporter: Jinchao Zhang
>Priority: Major
> Labels: StubRoutines, crash, updateBytesCRC32
> Attachments: f3.png, f4.png, hs1.png, hs2.png, hs_err_pid26350.log
>
>
> Recently, we encountered the same problem described by CASSANDRA-14283 in our
> production system, which runs on Cassandra 3.11.2. We noticed that this issue
> has been resolved in Cassandra 3.11.3 (CASSANDRA-14284), thus we upgrade our
> system to 3.11.3. However, this induce more frequent crash，as shown in the
> following screenshots, and the reduced hs file is posted here as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14813) Crash frequently due to fatal error caused by "StubRoutines::updateBytesCRC32"
[
https://issues.apache.org/jira/browse/CASSANDRA-14813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinchao Zhang updated CASSANDRA-14813:
--
Labels: StubRoutines crash updateBytesCRC32 (was: crash)
> Crash frequently due to fatal error caused by "StubRoutines::updateBytesCRC32"
> --
>
> Key: CASSANDRA-14813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14813
> Project: Cassandra
> Issue Type: Bug
> Environment: *OS:*
> {code:java}
> CentOS release 6.9 (Final){code}
> *JAVA:*
> {noformat}
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode){noformat}
>
> *Memory:*
> {noformat}
> 256GB{noformat}
> *CPU:*
> {noformat}
> 4* Intel® Xeon® Processor E5-2620 v4{noformat}
> *DISK:*
> {noformat}
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda3 423G 28G 374G 7% /
> tmpfs 126G 68K 126G 1% /dev/shm
> /dev/sda1 240M 40M 188M 18% /boot
> /dev/sdb 3.7T 33M 3.7T 1% /mpp-data/c/cache
> /dev/sdc 3.7T 2.7T 984G 74% /mpp-data/c/data00
> /dev/sdd 3.7T 2.5T 1.2T 68% /mpp-data/c/data01
> /dev/sde 3.7T 2.7T 1.1T 72% /mpp-data/c/data02
> /dev/sdf 3.7T 2.5T 1.2T 68% /mpp-data/c/data03
> /dev/sdg 3.7T 2.4T 1.3T 66% /mpp-data/c/data04
> /dev/sdh 3.7T 2.6T 1.2T 69% /mpp-data/c/data05
> /dev/sdi 3.7T 2.6T 1.2T 70% /mpp-data/c/data06{noformat}
>Reporter: Jinchao Zhang
>Priority: Major
> Labels: StubRoutines, crash, updateBytesCRC32
> Attachments: f3.png, f4.png, hs1.png, hs2.png, hs_err_pid26350.log
>
>
> Recently, we encountered the same problem described by CASSANDRA-14283 in our
> production system, which runs on Cassandra 3.11.2. We noticed that this issue
> has been resolved in Cassandra 3.11.3 (CASSANDRA-14284), thus we upgrade our
> system to 3.11.3. However, this induce more frequent crash，as shown in the
> following screenshots, and the reduced hs file is posted here as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14813) Crash frequently due to fatal error caused by "StubRoutines::updateBytesCRC32"
[
https://issues.apache.org/jira/browse/CASSANDRA-14813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinchao Zhang updated CASSANDRA-14813:
--
Labels: crash (was: )
> Crash frequently due to fatal error caused by "StubRoutines::updateBytesCRC32"
> --
>
> Key: CASSANDRA-14813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14813
> Project: Cassandra
> Issue Type: Bug
> Environment: *OS:*
> {code:java}
> CentOS release 6.9 (Final){code}
> *JAVA:*
> {noformat}
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode){noformat}
>
> *Memory:*
> {noformat}
> 256GB{noformat}
> *CPU:*
> {noformat}
> 4* Intel® Xeon® Processor E5-2620 v4{noformat}
> *DISK:*
> {noformat}
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda3 423G 28G 374G 7% /
> tmpfs 126G 68K 126G 1% /dev/shm
> /dev/sda1 240M 40M 188M 18% /boot
> /dev/sdb 3.7T 33M 3.7T 1% /mpp-data/c/cache
> /dev/sdc 3.7T 2.7T 984G 74% /mpp-data/c/data00
> /dev/sdd 3.7T 2.5T 1.2T 68% /mpp-data/c/data01
> /dev/sde 3.7T 2.7T 1.1T 72% /mpp-data/c/data02
> /dev/sdf 3.7T 2.5T 1.2T 68% /mpp-data/c/data03
> /dev/sdg 3.7T 2.4T 1.3T 66% /mpp-data/c/data04
> /dev/sdh 3.7T 2.6T 1.2T 69% /mpp-data/c/data05
> /dev/sdi 3.7T 2.6T 1.2T 70% /mpp-data/c/data06{noformat}
>Reporter: Jinchao Zhang
>Priority: Major
> Labels: crash
> Attachments: f3.png, f4.png, hs1.png, hs2.png, hs_err_pid26350.log
>
>
> Recently, we encountered the same problem described by CASSANDRA-14283 in our
> production system, which runs on Cassandra 3.11.2. We noticed that this issue
> has been resolved in Cassandra 3.11.3 (CASSANDRA-14284), thus we upgrade our
> system to 3.11.3. However, this induce more frequent crash，as shown in the
> following screenshots, and the reduced hs file is posted here as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14444) Got NPE when querying Cassandra 3.11.2
[
https://issues.apache.org/jira/browse/CASSANDRA-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660013#comment-16660013
]
Jeff Jirsa commented on CASSANDRA-1:
Everyone satisfied this is a dupe of CASSANDRA-10880 ? Can I close it as
such?
> Got NPE when querying Cassandra 3.11.2
> --
>
> Key: CASSANDRA-1
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Ubuntu 14.04, JDK 1.8.0_171.
> Cassandra 3.11.2
>Reporter: Xiaodong Xie
>Assignee: Xiaodong Xie
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We just upgraded our Cassandra cluster from 2.2.6 to 3.11.2
> After upgrading, we immediately got exceptions in Cassandra like this one:
>
> {code}
> ERROR [Native-Transport-Requests-1] 2018-05-11 17:10:21,994
> QueryMessage.java:129 - Unexpected error during query
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.dht.RandomPartitioner.getToken(RandomPartitioner.java:248)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.dht.RandomPartitioner.decorateKey(RandomPartitioner.java:92)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.config.CFMetaData.decorateKey(CFMetaData.java:666)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.service.pager.PartitionRangeQueryPager.(PartitionRangeQueryPager.java:44)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.db.PartitionRangeReadCommand.getPager(PartitionRangeReadCommand.java:268)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.getPager(SelectStatement.java:475)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:288)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:118)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:255)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:240)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_171]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_171]
> {code}
>
> The table schema is like:
> {code}
> CREATE TABLE example.example_table (
> id bigint,
> hash text,
> json text,
> PRIMARY KEY (id, hash)
> ) WITH COMPACT STORAGE
> {code}
>
> The query is something like:
> {code}
> "select * from example.example_table;" // (We do know this is bad practise,
> and we are trying to fix that right now)
> {code}
> with fetch-size as 200, using DataStax Java driver.
> This table contains about 20k rows.
>
> Actually, the fix is quite simple,
>
> {code}
> --- a/src/java/org/apache/cassandra/service/pager/PagingState.java
> +++ b/src/java/org/apache/cassandra/service/pager/PagingState.java
> @@ -46,7 +46,7 @@ public class PagingState
> public PagingState(ByteBuffer partitionKey, RowMark rowMark, int remaining,
> int remainingInPartition)
> {
> - this.partitionKey = partitionKey;
> + this.partitionK
[jira] [Updated] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[ https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-14498: - Status: Patch Available (was: In Progress) > Audit log does not include statements on some system keyspaces > -- > > Key: CASSANDRA-14498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14498 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Per Otterström >Assignee: Vinay Chella >Priority: Major > Labels: audit, lhf, security > Fix For: 4.0 > > Attachments: 14498-trunk.txt > > > Audit logs does not include statements on the "system" and "system_schema" > keyspace. > It may be a common use case to whitelist queries on these keyspaces, but > Cassandra should not make assumptions. Users who don't want these statements > in their audit log are still able to whitelist them with configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13241) Lower default chunk_length_in_kb from 64kb to 16kb
[ https://issues.apache.org/jira/browse/CASSANDRA-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-13241: --- Status: Open (was: Patch Available) > Lower default chunk_length_in_kb from 64kb to 16kb > -- > > Key: CASSANDRA-13241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13241 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: Benjamin Roth >Assignee: Ariel Weisberg >Priority: Major > Attachments: CompactIntegerSequence.java, > CompactIntegerSequenceBench.java, CompactSummingIntegerSequence.java > > > Having a too low chunk size may result in some wasted disk space. A too high > chunk size may lead to massive overreads and may have a critical impact on > overall system performance. > In my case, the default chunk size lead to peak read IOs of up to 1GB/s and > avg reads of 200MB/s. After lowering chunksize (of course aligned with read > ahead), the avg read IO went below 20 MB/s, rather 10-15MB/s. > The risk of (physical) overreads is increasing with lower (page cache size) / > (total data size) ratio. > High chunk sizes are mostly appropriate for bigger payloads pre request but > if the model consists rather of small rows or small resultsets, the read > overhead with 64kb chunk size is insanely high. This applies for example for > (small) skinny rows. > Please also see here: > https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY > To give you some insights what a difference it can make (460GB data, 128GB > RAM): > - Latency of a quite large CF: https://cl.ly/1r3e0W0S393L > - Disk throughput: https://cl.ly/2a0Z250S1M3c > - This shows, that the request distribution remained the same, so no "dynamic > snitch magic": https://cl.ly/3E0t1T1z2c0J -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14721) sstabledump displays incorrect value for "position" key
[
https://issues.apache.org/jira/browse/CASSANDRA-14721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659701#comment-16659701
]
Chris Lohfink commented on CASSANDRA-14721:
---
all versions are effected, and from what i can tell will apply cleanly (didn't
try all though).
> sstabledump displays incorrect value for "position" key
> ---
>
> Key: CASSANDRA-14721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14721
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Damien Stevenson
>Assignee: Cameron Zemek
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: cassandra-dump.patch
>
>
> When partitions with multiple rows are displayed using sstabledump, the
> "position" value the first row of each partition is incorrect.
> For example:
> {code:java}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1", "24" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-10 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.290086Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 8 },
> { "name" : "chanceofrain", "value" : 0.1 },
> { "name" : "feelslike", "value" : 8 },
> { "name" : "humidity", "value" : 0.76 },
> { "name" : "wind", "value" : 10.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-11 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.295369Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 4 },
> { "name" : "chanceofrain", "value" : 0.3 },
> { "name" : "feelslike", "value" : 4 },
> { "name" : "humidity", "value" : 0.9 },
> { "name" : "wind", "value" : 12.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 105,
> "clustering" : [ "2013-12-12 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.300841Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 3 },
> { "name" : "chanceofrain", "value" : 0.2 },
> { "name" : "feelslike", "value" : 3 },
> { "name" : "humidity", "value" : 0.68 },
> { "name" : "wind", "value" : 6.0 }
> ]
> }
> ]
> }
> ]
> {code}
> The expected output is:
> {code:java}
> [
> {
> "partition" : {
> "key" : [ "1", "24" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 28,
> "clustering" : [ "2013-12-10 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.290086Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 8 },
> { "name" : "chanceofrain", "value" : 0.1 },
> { "name" : "feelslike", "value" : 8 },
> { "name" : "humidity", "value" : 0.76 },
> { "name" : "wind", "value" : 10.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-11 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.295369Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 4 },
> { "name" : "chanceofrain", "value" : 0.3 },
> { "name" : "feelslike", "value" : 4 },
> { "name" : "humidity", "value" : 0.9 },
> { "name" : "wind", "value" : 12.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 105,
> "clustering" : [ "2013-12-12 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.300841Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 3 },
> { "name" : "chanceofrain", "value" : 0.2 },
> { "name" : "feelslike", "value" : 3 },
> { "name" : "humidity", "value" : 0.68 },
> { "name" : "wind", "value" : 6.0 }
> ]
> }
> ]
> }
> ]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13241) Lower default chunk_length_in_kb from 64kb to 16kb
[ https://issues.apache.org/jira/browse/CASSANDRA-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-13241: --- Status: Patch Available (was: Open) [trunk patch|https://github.com/apache/cassandra/compare/trunk...aweisberg:13241-trunk?expand=1] [CircleCI|https://circleci.com/gh/aweisberg/cassandra/tree/13241-trunk] CircleCI link doesn't work yet. They are backed up due to the github outage. > Lower default chunk_length_in_kb from 64kb to 16kb > -- > > Key: CASSANDRA-13241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13241 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: Benjamin Roth >Assignee: Ariel Weisberg >Priority: Major > Attachments: CompactIntegerSequence.java, > CompactIntegerSequenceBench.java, CompactSummingIntegerSequence.java > > > Having a too low chunk size may result in some wasted disk space. A too high > chunk size may lead to massive overreads and may have a critical impact on > overall system performance. > In my case, the default chunk size lead to peak read IOs of up to 1GB/s and > avg reads of 200MB/s. After lowering chunksize (of course aligned with read > ahead), the avg read IO went below 20 MB/s, rather 10-15MB/s. > The risk of (physical) overreads is increasing with lower (page cache size) / > (total data size) ratio. > High chunk sizes are mostly appropriate for bigger payloads pre request but > if the model consists rather of small rows or small resultsets, the read > overhead with 64kb chunk size is insanely high. This applies for example for > (small) skinny rows. > Please also see here: > https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY > To give you some insights what a difference it can make (460GB data, 128GB > RAM): > - Latency of a quite large CF: https://cl.ly/1r3e0W0S393L > - Disk throughput: https://cl.ly/2a0Z250S1M3c > - This shows, that the request distribution remained the same, so no "dynamic > snitch magic": https://cl.ly/3E0t1T1z2c0J -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13241) Lower default chunk_length_in_kb from 64kb to 16kb
[ https://issues.apache.org/jira/browse/CASSANDRA-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-13241: --- Summary: Lower default chunk_length_in_kb from 64kb to 16kb (was: Lower default chunk_length_in_kb from 64kb to 4kb) > Lower default chunk_length_in_kb from 64kb to 16kb > -- > > Key: CASSANDRA-13241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13241 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: Benjamin Roth >Assignee: Ariel Weisberg >Priority: Major > Attachments: CompactIntegerSequence.java, > CompactIntegerSequenceBench.java, CompactSummingIntegerSequence.java > > > Having a too low chunk size may result in some wasted disk space. A too high > chunk size may lead to massive overreads and may have a critical impact on > overall system performance. > In my case, the default chunk size lead to peak read IOs of up to 1GB/s and > avg reads of 200MB/s. After lowering chunksize (of course aligned with read > ahead), the avg read IO went below 20 MB/s, rather 10-15MB/s. > The risk of (physical) overreads is increasing with lower (page cache size) / > (total data size) ratio. > High chunk sizes are mostly appropriate for bigger payloads pre request but > if the model consists rather of small rows or small resultsets, the read > overhead with 64kb chunk size is insanely high. This applies for example for > (small) skinny rows. > Please also see here: > https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY > To give you some insights what a difference it can make (460GB data, 128GB > RAM): > - Latency of a quite large CF: https://cl.ly/1r3e0W0S393L > - Disk throughput: https://cl.ly/2a0Z250S1M3c > - This shows, that the request distribution remained the same, so no "dynamic > snitch magic": https://cl.ly/3E0t1T1z2c0J -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14721) sstabledump displays incorrect value for "position" key
[
https://issues.apache.org/jira/browse/CASSANDRA-14721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-14721:
---
Fix Version/s: 4.x
3.11.x
3.0.x
> sstabledump displays incorrect value for "position" key
> ---
>
> Key: CASSANDRA-14721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14721
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Damien Stevenson
>Assignee: Cameron Zemek
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: cassandra-dump.patch
>
>
> When partitions with multiple rows are displayed using sstabledump, the
> "position" value the first row of each partition is incorrect.
> For example:
> {code:java}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1", "24" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-10 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.290086Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 8 },
> { "name" : "chanceofrain", "value" : 0.1 },
> { "name" : "feelslike", "value" : 8 },
> { "name" : "humidity", "value" : 0.76 },
> { "name" : "wind", "value" : 10.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-11 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.295369Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 4 },
> { "name" : "chanceofrain", "value" : 0.3 },
> { "name" : "feelslike", "value" : 4 },
> { "name" : "humidity", "value" : 0.9 },
> { "name" : "wind", "value" : 12.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 105,
> "clustering" : [ "2013-12-12 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.300841Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 3 },
> { "name" : "chanceofrain", "value" : 0.2 },
> { "name" : "feelslike", "value" : 3 },
> { "name" : "humidity", "value" : 0.68 },
> { "name" : "wind", "value" : 6.0 }
> ]
> }
> ]
> }
> ]
> {code}
> The expected output is:
> {code:java}
> [
> {
> "partition" : {
> "key" : [ "1", "24" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 28,
> "clustering" : [ "2013-12-10 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.290086Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 8 },
> { "name" : "chanceofrain", "value" : 0.1 },
> { "name" : "feelslike", "value" : 8 },
> { "name" : "humidity", "value" : 0.76 },
> { "name" : "wind", "value" : 10.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-11 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.295369Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 4 },
> { "name" : "chanceofrain", "value" : 0.3 },
> { "name" : "feelslike", "value" : 4 },
> { "name" : "humidity", "value" : 0.9 },
> { "name" : "wind", "value" : 12.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 105,
> "clustering" : [ "2013-12-12 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.300841Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 3 },
> { "name" : "chanceofrain", "value" : 0.2 },
> { "name" : "feelslike", "value" : 3 },
> { "name" : "humidity", "value" : 0.68 },
> { "name" : "wind", "value" : 6.0 }
> ]
> }
> ]
> }
> ]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14721) sstabledump displays incorrect value for "position" key
[
https://issues.apache.org/jira/browse/CASSANDRA-14721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659636#comment-16659636
]
Jeff Jirsa commented on CASSANDRA-14721:
[~cam1982] / [~cnlwsu] - which versions are affected? Does the patch apply
cleanly to all of them?
> sstabledump displays incorrect value for "position" key
> ---
>
> Key: CASSANDRA-14721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14721
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Damien Stevenson
>Assignee: Cameron Zemek
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: cassandra-dump.patch
>
>
> When partitions with multiple rows are displayed using sstabledump, the
> "position" value the first row of each partition is incorrect.
> For example:
> {code:java}
> sstabledump mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "1", "24" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-10 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.290086Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 8 },
> { "name" : "chanceofrain", "value" : 0.1 },
> { "name" : "feelslike", "value" : 8 },
> { "name" : "humidity", "value" : 0.76 },
> { "name" : "wind", "value" : 10.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-11 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.295369Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 4 },
> { "name" : "chanceofrain", "value" : 0.3 },
> { "name" : "feelslike", "value" : 4 },
> { "name" : "humidity", "value" : 0.9 },
> { "name" : "wind", "value" : 12.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 105,
> "clustering" : [ "2013-12-12 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.300841Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 3 },
> { "name" : "chanceofrain", "value" : 0.2 },
> { "name" : "feelslike", "value" : 3 },
> { "name" : "humidity", "value" : 0.68 },
> { "name" : "wind", "value" : 6.0 }
> ]
> }
> ]
> }
> ]
> {code}
> The expected output is:
> {code:java}
> [
> {
> "partition" : {
> "key" : [ "1", "24" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 28,
> "clustering" : [ "2013-12-10 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.290086Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 8 },
> { "name" : "chanceofrain", "value" : 0.1 },
> { "name" : "feelslike", "value" : 8 },
> { "name" : "humidity", "value" : 0.76 },
> { "name" : "wind", "value" : 10.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 66,
> "clustering" : [ "2013-12-11 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.295369Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 4 },
> { "name" : "chanceofrain", "value" : 0.3 },
> { "name" : "feelslike", "value" : 4 },
> { "name" : "humidity", "value" : 0.9 },
> { "name" : "wind", "value" : 12.0 }
> ]
> },
> {
> "type" : "row",
> "position" : 105,
> "clustering" : [ "2013-12-12 00:00:00.000Z" ],
> "liveness_info" : { "tstamp" : "2018-09-12T05:01:09.300841Z" },
> "cells" : [
> { "name" : "centigrade", "value" : 3 },
> { "name" : "chanceofrain", "value" : 0.2 },
> { "name" : "feelslike", "value" : 3 },
> { "name" : "humidity", "value" : 0.68 },
> { "name" : "wind", "value" : 6.0 }
> ]
> }
> ]
> }
> ]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13241) Lower default chunk_length_in_kb from 64kb to 4kb
[ https://issues.apache.org/jira/browse/CASSANDRA-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16656821#comment-16656821 ] Ariel Weisberg edited comment on CASSANDRA-13241 at 10/22/18 3:44 PM: -- Summary as charts Load: ||Chunk size|Time| |64k|39:27| |64k|36:37| |32k|37:29| |16k|39:25| |16k|38:15| |8k|37:47| |4k|39:33| Read: ||Chunk size|Time|Speedup| |64k|25:20|1.005x| |64k|25:33|1.000x| |32k|20:01|1.265x| |16k|19:19|1.319x| |16k|19:14|1.323x| |8k|16:51|1.534x| |4k|15:39|1.645x| ||Chunk size|Compression Ratio|Improvement|Compared to 64k improvement| |64k|0.607208|39.3%|1.000| |32k|0.634735|36.6%|0.931| |16k|0.667236|33.3%|0.847| |8k|0.709473|29.1%|0.740| was (Author: aweisberg): Summary as charts Load: ||Chunk size|Time|| |64k|39:27| |64k|36:37| |32k|37:29| |16k|39:25| |16k|38:15| |8k|37:47| |4k|39:33| Read: ||Chunk size|Time|| |64k|25:20| |64k|25:33| |32k|20:01| |16k|19:19| |16k|19:14| |8k|16:51| |4k|15:39| > Lower default chunk_length_in_kb from 64kb to 4kb > - > > Key: CASSANDRA-13241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13241 > Project: Cassandra > Issue Type: Wish > Components: Core >Reporter: Benjamin Roth >Assignee: Ariel Weisberg >Priority: Major > Attachments: CompactIntegerSequence.java, > CompactIntegerSequenceBench.java, CompactSummingIntegerSequence.java > > > Having a too low chunk size may result in some wasted disk space. A too high > chunk size may lead to massive overreads and may have a critical impact on > overall system performance. > In my case, the default chunk size lead to peak read IOs of up to 1GB/s and > avg reads of 200MB/s. After lowering chunksize (of course aligned with read > ahead), the avg read IO went below 20 MB/s, rather 10-15MB/s. > The risk of (physical) overreads is increasing with lower (page cache size) / > (total data size) ratio. > High chunk sizes are mostly appropriate for bigger payloads pre request but > if the model consists rather of small rows or small resultsets, the read > overhead with 64kb chunk size is insanely high. This applies for example for > (small) skinny rows. > Please also see here: > https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY > To give you some insights what a difference it can make (460GB data, 128GB > RAM): > - Latency of a quite large CF: https://cl.ly/1r3e0W0S393L > - Disk throughput: https://cl.ly/2a0Z250S1M3c > - This shows, that the request distribution remained the same, so no "dynamic > snitch magic": https://cl.ly/3E0t1T1z2c0J -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)
[
https://issues.apache.org/jira/browse/CASSANDRA-13938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658981#comment-16658981
]
Alex Lourie edited comment on CASSANDRA-13938 at 10/22/18 1:39 PM:
---
[~jasobrown] I've been testing both trunk and your branch in a simple repair
scenario and it's still failing. The scenario I'm working with is:
1. Start a cluster
2. Load the cluster for 10 minutes
3. Stop one node and load it for an additional 30 minutes
4. Clear the hints
5. Start the stopped node and let it resync with others for a couple of minutes.
6. Start the repairs on the previously stopped node.
Repairs crash on the other nodes (on 2 nodes in my 3-node test cluster) with
the following error:
{code}
Oct 22 13:10:54 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:10:54,716 Validator.java:417 - [repair
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Sending completed merkle tree to
35.162.15.68:7000 for alex.test2
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,594 StreamingRepairTask.java:72 - [streaming task
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Performing streaming repair of 7382
ranges with 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamResultFuture.java:89 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Executing streaming plan for Repair
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamSession.java:287 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Starting streaming to 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,987 StreamCoordinator.java:259 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619, ID#0] Beginning stream session with
35.162.15.68:7000
Oct 22 13:16:03 ip-10-0-13-111 cassandra[5927]: INFO
[Stream-Deserializer-35.162.15.68:7000-0b32ed63] 2018-10-22 13:16:03,783
StreamResultFuture.java:178 - [Stream #9fe63820-d5fc-11e8-8a2b-3555ba61a619
ID#0] Prepare completed. Receiving 6 files(215.878MiB), sending 17
files(720.317MiB)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: WARN
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,355
CassandraCompressedStreamReader.java:110 - [Stream
9fe63820-d5fc-11e8-8a2b-3555ba61a619] Error while reading partition
DecoratedKey(-9088115514873584734, 646572706865616435393632373436) from stream
on ks='alex' and table='test2'.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: ERROR
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,362
StreamingInboundHandler.java:213 - [Stream channel: be7cb6ee] stream operation
from 35.162.15.68:60292 failed
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: java.lang.AssertionError:
stream can only read forward.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CompressedInputStream.position(CompressedInputStream.java:108)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:93)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:74)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:177)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
java.lang.Thread.run(Thread.java:748)
{code}
The data is created as follows:
{code:sql}
CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
'NetworkTopologyStrategy', 'alourie': 3 };
CREATE TABLE IF NOT EXISTS alex.test2 (
part text,
[jira] [Commented] (CASSANDRA-13938) Default repair is broken, crashes other nodes participating in repair (in trunk)
[
https://issues.apache.org/jira/browse/CASSANDRA-13938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658981#comment-16658981
]
Alex Lourie commented on CASSANDRA-13938:
-
[~jasobrown] I've been testing both trunk and your branch in a simple repair
scenario and it's still failing. The scenario I'm working with is:
1. Start a cluster
2. Load the cluster for 10 minutes
3. Stop one node and load it for an additional 30 minutes
4. Clear the hints
5. Start the stopped node and let it resync with others for a couple of minutes.
6. Start the repairs on the previously stopped node.
Repairs crash on the other nodes (on 2 nodes in my 3-node test cluster) with
the following error:
{code}
Oct 22 13:10:54 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:10:54,716 Validator.java:417 - [repair
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Sending completed merkle tree to
35.162.15.68:7000 for alex.test2
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,594 StreamingRepairTask.java:72 - [streaming task
#9c38dd00-d5fb-11e8-ac32-316a9d8f8d32] Performing streaming repair of 7382
ranges with 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamResultFuture.java:89 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Executing streaming plan for Repair
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,981 StreamSession.java:287 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619] Starting streaming to 35.162.15.68:7000
Oct 22 13:16:02 ip-10-0-13-111 cassandra[5927]: INFO [AntiEntropyStage:1]
2018-10-22 13:16:02,987 StreamCoordinator.java:259 - [Stream
#9fe63820-d5fc-11e8-8a2b-3555ba61a619, ID#0] Beginning stream session with
35.162.15.68:7000
Oct 22 13:16:03 ip-10-0-13-111 cassandra[5927]: INFO
[Stream-Deserializer-35.162.15.68:7000-0b32ed63] 2018-10-22 13:16:03,783
StreamResultFuture.java:178 - [Stream #9fe63820-d5fc-11e8-8a2b-3555ba61a619
ID#0] Prepare completed. Receiving 6 files(215.878MiB), sending 17
files(720.317MiB)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: WARN
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,355
CassandraCompressedStreamReader.java:110 - [Stream
9fe63820-d5fc-11e8-8a2b-3555ba61a619] Error while reading partition
DecoratedKey(-9088115514873584734, 646572706865616435393632373436) from stream
on ks='alex' and table='test2'.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: ERROR
[Stream-Deserializer-35.162.15.68:60292-be7cb6ee] 2018-10-22 13:16:04,362
StreamingInboundHandler.java:213 - [Stream channel: be7cb6ee] stream operation
from 35.162.15.68:60292 failed
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: java.lang.AssertionError:
stream can only read forward.
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CompressedInputStream.position(CompressedInputStream.java:108)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:93)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:74)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:55)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:177)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
Oct 22 13:16:04 ip-10-0-13-111 cassandra[5927]: at
java.lang.Thread.run(Thread.java:748)
{code}
The data is created as follows:
{code:cql}
CREATE KEYSPACE IF NOT EXISTS alex with replication = { 'class':
'NetworkTopologyStrategy', 'alourie': 3 };
CREATE TABLE IF NOT EXISTS alex.test2 (
part text,
clus int,
[jira] [Commented] (CASSANDRA-14498) Audit log does not include statements on some system keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658877#comment-16658877
]
Per Otterström commented on CASSANDRA-14498:
{quote}You could have an empty {{excluded_keyspaces}} in yaml without
mentioning any keyspaces.
{quote}
Ahh, right! That works for me. And same approach is applicable for the nodetool
options.
I'm +1 on this patch!
> Audit log does not include statements on some system keyspaces
> --
>
> Key: CASSANDRA-14498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14498
> Project: Cassandra
> Issue Type: Bug
> Components: Auth
>Reporter: Per Otterström
>Assignee: Vinay Chella
>Priority: Major
> Labels: audit, lhf, security
> Fix For: 4.0
>
> Attachments: 14498-trunk.txt
>
>
> Audit logs does not include statements on the "system" and "system_schema"
> keyspace.
> It may be a common use case to whitelist queries on these keyspaces, but
> Cassandra should not make assumptions. Users who don't want these statements
> in their audit log are still able to whitelist them with configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13835) Thrift get_slice responds slower on Cassandra 3
[
https://issues.apache.org/jira/browse/CASSANDRA-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658723#comment-16658723
]
Pawel Szlendak commented on CASSANDRA-13835:
[~pjanicki] Are you able to provide a patch that changes it only for a Windows
platform?
This way I hope the patch could get merged in.
> Thrift get_slice responds slower on Cassandra 3
> ---
>
> Key: CASSANDRA-13835
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13835
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows
>Reporter: Pawel Szlendak
>Priority: Major
> Attachments: 0001-Fix-performance-when-running-on-Windows.patch,
> attack.py, cassandra120_get_slice_reply_time.png,
> cassandra310_get_slice_reply_time.png
>
>
> I have recently upgraded from Cassandra 1.2.18 to Cassandra 3.10 and was
> surprised to notice performance degradation of my server application.
> I dug down through my application stack only to find out that the cause of
> the performance issue was slower response time of Cassandra 3.10 get_slice as
> compared to Cassandra 1.2.18 (almost x3 times slower on average).
> I am attaching a python script (attack.py) here that can be used to reproduce
> this issue on a Windows platform. The script uses the pycassa python library
> that can easily be installed using pip.
> REPRODUCTION STEPS:
> 1. Install Cassandra 1.2.18 from
> https://archive.apache.org/dist/cassandra/1.2.18/apache-cassandra-1.2.18-bin.tar.gz
> 2. Run Cassandra 1.2.18 from cmd console using cassandra.bat
> 3. Create a test keyspace and an empty CF using attack.py script
>
> {noformat}
> python attack.py create
> {noformat}
> 4. Run some get_slice queries to an empty CF and note down the average
> response time (in seconds)
>
> {noformat}
> python attack.py
> {noformat}
>get_slice count: 788
>get_slice total response time: 0.3126376
>*get_slice average response time: 0.000397208075838*
> 5. Stop Cassandra 1.2.18 and install Cassandra 3.10 from
> https://archive.apache.org/dist/cassandra/3.10/apache-cassandra-3.10-bin.tar.gz
> 6. Tweak cassandra.yaml to run thrift service (start_rpc=true) and run
> Cassandra from an elevated cmd console using cassandra.bat
> 7. Create a test keyspace and an empty CF using attack.py script
>
> {noformat}
> python attack.py create
> {noformat}
> 8. Run some get_slice queries to an empty CF using attack.py and note down
> the average response time (in seconds)
> {noformat}
> python attack.py
> {noformat}
>get_slice count: 788
>get_slice total response time: 1.1646185
>*get_slice average response time: 0.00147842634753*
> 9. Compare the average response times
> EXPECTED:
>get_slice response time of Cassandra 3.10 is not worse than on Cassandra
> 1.2.18
> ACTUAL:
>get_slice response time of Cassandra 3.10 is x3 worse than that of
> Cassandra 1.2.18
> REMARKS:
> - this seems to happen only on Windows platform (tested on Windows 10 and
> Windows Server 2008 R2)
> - running the very same procedure on Linux (Ubuntu) renders roughly the same
> response times
> - I sniffed the traffic to/from Cassandra 1.2.18 and Cassandra 3.10 and it
> can be seen that Cassandra 3.10 responds slower (Wireshark dumps attached)
> - when attacking the server with concurrent get_slice queries I can see lower
> CPU usage for Cassandra 3.10 that for Cassandra 1.2.18
> - get_slice in attack.py queries the column family for non-exisitng key (the
> column familiy is empty)
> I am willing to work on this on my own if you guys give me some tips on where
> to look for. I am also aware that this might be more Windows/Java related,
> nevertheless, any help from your side would be much appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
