[
https://issues.apache.org/jira/browse/CASSANDRA-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560734#comment-14560734
]
Stefania commented on CASSANDRA-8897:
-------------------------------------
Thanks for the comments, as discussed earlier on, it should be clear now.
In the meantime I have been working on the cperf test:
bq. It would be nice to run some tests that show this change's strengths: if
you disable auto-compaction on cstar (not sure if you can do this), and make
the memtable size very small, then we can produce a workload with many sstables
that still fit in memory. If we aim to write say 4G of data, but perhaps with
many overwrites so each operation has to touch multiple files (so perhaps only
400M of data written 10 times, or 4G of data with 10+ clustering values,
written with visits=fixed(10)). If we set the memtable size to <= 100Mb, this
will likely result in files of <= 30Mb, giving us 120+ sstables. If we
constrain the size of the file cache to just 64Mb, say, we should on a random
read workload see much more GC activity under the old scheme, and likely
reduced throughput.
I can disable compaction in the schema and setup the memtable size parameters
in cassandra.yaml so as to obtain sstables of approx 30MB. However I am having
problems ensuring the overwrite part. Is it enough to run stress 10 times
writing 400MB each time or do I need to do anything specific like using visits:
fixed(10), which I cannot get to work, or using 10 clustering values (which
generate batches too big and I cannot work out how to disable batching using
stress).
Here is the profile:
{code}
keyspace: perftesting
keyspace_definition: |
CREATE KEYSPACE perftesting WITH replication = { 'class': 'SimpleStrategy',
'replication_factor':1};
table: mytest
table_definition:
CREATE TABLE mytest (
id text,
sub_id uuid,
data text,
PRIMARY KEY(id, sub_id)
) WITH compaction = {'class':'SizeTieredCompactionStrategy', 'enabled':false
};
columnspec:
- name: id
size: gaussian(1..50)
population: uniform(1..5000)
- name: sub_id
cluster: fixed(5000)
- name: data
size: fixed(1000)
insert:
partitions: fixed(1)
select: fixed(1)/5000
batchtype: LOGGED
queries:
read:
cql: select * from mytest where id = ? LIMIT 10
fields: samerow
{code}
Here is the command:
{code}
./tools/bin/cassandra-stress user profile=~/Documents/tests/8897.yaml
ops\(insert=1\) n=300000 -rate threads=50
{code}
Here are the warnings:
{code}
WARN 10:02:18 Batch of prepared statements for [perftesting.mytest] is of size
5140, exceeding specified threshold of 5120 by 20.
{code}
And this is the problem when adding {{visits: fixed(10)}} to the profile insert
section, plus I am not sure it is picked up even if I comment out the line
generating the Exception:
{code}
Exception in thread "main" java.lang.IllegalArgumentException: Unrecognised
insert option(s): {visits=fixed(10)}
at
org.apache.cassandra.stress.StressProfile.getInsert(StressProfile.java:357)
at
org.apache.cassandra.stress.settings.SettingsCommandUser$1.get(SettingsCommandUser.java:82)
at
org.apache.cassandra.stress.settings.SettingsCommandUser$1.get(SettingsCommandUser.java:78)
at
org.apache.cassandra.stress.operations.SampledOpDistributionFactory$1.get(SampledOpDistributionFactory.java:80)
at
org.apache.cassandra.stress.StressAction$Consumer.<init>(StressAction.java:269)
at org.apache.cassandra.stress.StressAction.run(StressAction.java:204)
at
org.apache.cassandra.stress.StressAction.warmup(StressAction.java:105)
at org.apache.cassandra.stress.StressAction.run(StressAction.java:61)
at org.apache.cassandra.stress.Stress.main(Stress.java:109)
{code}
Thanks! :)
> Remove FileCacheService, instead pooling the buffers
> ----------------------------------------------------
>
> Key: CASSANDRA-8897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8897
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Stefania
> Fix For: 3.x
>
> Attachments: 9240_test_results.txt,
> snapshot-1431582436640-cpu-backtraces.png,
> snapshot-1431582436640-cpu-calltree-compression-8897.nps,
> snapshot-1431582436640-cpu-calltree-compression-trunk.nps
>
>
> After CASSANDRA-8893, a RAR will be a very lightweight object and will not
> need caching, so we can eliminate this cache entirely. Instead we should have
> a pool of buffers that are page-aligned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
