So I upgraded to 2.2.2 and change the compaction strategy from
DateTieredCompactionStrategy to LeveledCompactionStrategy. But the problem
still exists.
At the start we were getting responses around 80 to a couple of hundred of ms.
But after 1.5 hours of running, it is now hitting 1447 ms. I think this will
degrade some more as time progresses. I will let this run a couple of hours
more and will also try to force compaction.
BTW, with 2.2.2 I am getting the following exceptions. Not sure if there is
already a bug report on this.
Caused by: java.io.IOException: Seek position 182054 is not within mmap segment
(seg offs: 0, length: 182054)
at
org.apache.cassandra.io.util.ByteBufferDataInput.seek(ByteBufferDataInput.java:47)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.util.AbstractDataInput.skipBytes(AbstractDataInput.java:33)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.util.FileUtils.skipBytesFully(FileUtils.java:405)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.RowIndexEntry$Serializer.skipPromotedIndex(RowIndexEntry.java:164)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.RowIndexEntry$Serializer.skip(RowIndexEntry.java:155)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.sstable.format.big.BigTableReader.getPosition(BigTableReader.java:244)
~[apache-cassandra-2.2.2.jar:2.2.2]
... 17 common frames omitted
WARN [SharedPool-Worker-42] 2015-10-09 12:54:57,221
AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread
Thread[SharedPool-Worker-42,5,main]: {}
java.lang.RuntimeException:
org.apache.cassandra.io.sstable.CorruptSSTableException: java.io.IOException:
Seek position 182054 is not within mmap segment (seg offs: 0, length: 182054)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2187)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_60]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
~[apache-cassandra-2.2.2.jar:2.2.2]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-2.2.2.jar:2.2.2]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
java.io.IOException: Seek position 182054 is not within mmap segment (seg offs:
0, length: 182054)
at
org.apache.cassandra.io.sstable.format.big.BigTableReader.getPosition(BigTableReader.java:250)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.sstable.format.SSTableReader.getPosition(SSTableReader.java:1558)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.sstable.format.big.SSTableSliceIterator.<init>(SSTableSliceIterator.java:42)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.sstable.format.big.BigTableReader.iterator(BigTableReader.java:75)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:246)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:270)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:2004)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1808)
~[apache-cassandra-2.2.2.jar:2.2.2]
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:360)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1537)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2183)
~[apache-cassandra-2.2.2.jar:2.2.2]
... 4 common frames omitted
Caused by: java.io.IOException: Seek position 182054 is not within mmap segment
(seg offs: 0, length: 182054)
at
org.apache.cassandra.io.util.ByteBufferDataInput.seek(ByteBufferDataInput.java:47)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.util.AbstractDataInput.skipBytes(AbstractDataInput.java:33)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.util.FileUtils.skipBytesFully(FileUtils.java:405)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.RowIndexEntry$Serializer.skipPromotedIndex(RowIndexEntry.java:164)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.db.RowIndexEntry$Serializer.skip(RowIndexEntry.java:155)
~[apache-cassandra-2.2.2.jar:2.2.2]
at
org.apache.cassandra.io.sstable.format.big.BigTableReader.getPosition(BigTableReader.java:244)
~[apache-cassandra-2.2.2.jar:2.2.2]
> On Oct 9, 2015, at 9:26 AM, Carlos Alonso <[email protected]> wrote:
>
> Yeah, I was about to suggest the compaction strategy too. Leveled compaction
> sounds like a better fit when records are being updated
>
> Carlos Alonso | Software Engineer | @calonso <https://twitter.com/calonso>
>
> On 8 October 2015 at 22:35, Tyler Hobbs <[email protected]
> <mailto:[email protected]>> wrote:
> Upgrade to 2.2.2. Your sstables are probably not compacting due to
> CASSANDRA-10270 <https://issues.apache.org/jira/browse/CASSANDRA-10270>,
> which was fixed in 2.2.2.
>
> Additionally, you may want to look into using leveled compaction
> (http://www.datastax.com/dev/blog/when-to-use-leveled-compaction
> <http://www.datastax.com/dev/blog/when-to-use-leveled-compaction>).
>
> On Thu, Oct 8, 2015 at 4:27 PM, Nazario Parsacala <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
>
> so we are developing a system that computes profile of things that it
> observes. The observation comes in form of events. Each thing that it observe
> has an id and each thing has a set of subthings in it which has measurement
> of some kind. Roughly there are about 500 subthings within each thing. We
> receive events containing measurements of these 500 subthings every 10
> seconds or so.
>
> So as we receive events, we read the old profile value, calculate the new
> profile based on the new value and save it back. We use the following schema
> to hold the profile.
>
> CREATE TABLE myprofile (
> id text,
> month text,
> day text,
> hour text,
> subthings text,
> lastvalue double,
> count int,
> stddev double,
> PRIMARY KEY ((id, month, day, hour), subthings)
> ) WITH CLUSTERING ORDER BY (subthings ASC) );
>
>
> This profile will then be use for certain analytics that can use in the
> context of the ‘thing’ or in the context of specific thing and subthing.
>
> A profile can be defined as monthly, daily, hourly. So in case of monthly the
> month will be set to the current month (i.e. ‘Oct’) and the day and hour will
> be set to empty ‘’ string.
>
>
> The problem that we have observed is that over time (actually in just a
> matter of hours) we will see a huge degradation of query response for the
> monthly profile. At the start it will be respinding in 10-100 ms and after a
> couple of hours it will go to 2000-3000 ms . If you leave it for a couple of
> days you will start experiencing readtimeouts . The query is basically just :
>
> select * from myprofile where id=‘1’ and month=‘Oct’ and day=‘’ and hour=‘'
>
> This will have only about 500 rows or so.
>
>
> I believe that this is cause by the fact there are multiple updates done to
> this specific partition. So what do we think can be done to resolve this ?
>
> BTW, I am using Cassandra 2.2.1 . And since this is a test , this is just
> running on a single node.
>
>
>
>
>
>
>
> --
> Tyler Hobbs
> DataStax <http://datastax.com/>
>
