[jira] [Updated] (CASSANDRA-13023) Add droppable tombstone metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-13023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-13023:
---
Summary: Add droppable tombstone metrics (was: Add Tombstone Metrics)
> Add droppable tombstone metrics
> ---
>
> Key: CASSANDRA-13023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13023
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Attachments: 13023-3.0.patch
>
>
> Currently it's only possible to inspect the ratio of droppable tombstones on
> sstable basis using the {{sstablemetadata}} tool. It would be very useful to
> have this information provided as part of Cassandra metrics as well, e.g. to
> get an idea on the effectiveness of tombstone eviction during compactions
> over time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11431) java: error: unmappable character for encoding ASCII
[
https://issues.apache.org/jira/browse/CASSANDRA-11431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15810936#comment-15810936
]
Stefania commented on CASSANDRA-11431:
--
Thanks for the patch. I think this problem should be fixed by CASSANDRA-11077,
we just need to backport it to 3.0. Could you test it since I am unable to
reproduce the problem?
I've also added an additional commit with the fix for the tabs in build.xml,
and the typo in ColumnFamilyStoreCQLHelper:
||3.0||
|[patch|https://github.com/stef1927/cassandra/commits/11431-3.0]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11431-3.0-testall/]|
> java: error: unmappable character for encoding ASCII
>
>
> Key: CASSANDRA-11431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11431
> Project: Cassandra
> Issue Type: Bug
> Environment: java version "1.7.0_95"
> OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-0ubuntu0.15.10.1)
> OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
> Linux 22be6fbead2c 4.2.0-34-generic #39-Ubuntu SMP Thu Mar 10 22:11:28 UTC
> 2016 ppc64le ppc64le ppc64le GNU/Linux
>Reporter: Lorena Pesantez
>Assignee: Jay Zhuang
> Labels: lhf
> Fix For: 3.0.x
>
> Attachments: 11431-3.0-update.txt, 11431-3.0.txt
>
>
> I saw this closed issue with the exact same signature as the one I
> encountered, so cloning... I fixed the errors below by adding the line
> "" after lines 727 and 1089 of the
> cassandra/build.xml file. I am working PerfKitBenchmarker, so the workload
> must build on my platform (ppc64) without any changes after cloning it from
> github. Thanks!
> {code}
> build-project:
> [echo] apache-cassandra: /tmp/pkb/cassandra/build.xml
> [javac] Compiling 997 source files to
> /tmp/pkb/cassandra/build/classes/main
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/net/OutboundTcpConnection.java:106:
> error: unmappable character for encoding ASCII
> [javac] logger.info("OutboundTcpConnection coalescing window
> set to " + coalescingWindow + "??s");
> [javac]
> ^
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/net/OutboundTcpConnection.java:106:
> error: unmappable character for encoding ASCII
> [javac] logger.info("OutboundTcpConnection coalescing window
> set to " + coalescingWindow + "??s");
> [javac]
>^
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/utils/CoalescingStrategies.java:172:
> error: unmappable character for encoding ASCII
> [javac] logger.info(toString() + " gap " +
> TimeUnit.NANOSECONDS.toMicros(averageGap) + "??s");
> [javac]
> ^
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/utils/CoalescingStrategies.java:172:
> error: unmappable character for encoding ASCII
> [javac] logger.info(toString() + " gap " +
> TimeUnit.NANOSECONDS.toMicros(averageGap) + "??s");
> [javac]
>^
> [javac] 4 errors
> BUILD FAILED
> /tmp/pkb/cassandra/build.xml:723: Compile failed; see the compiler error
> output for details.
> build-test:
> [javac] Compiling 263 source files to
> /tmp/pkb/cassandra/build/test/classes
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac] ^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac]^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac] ^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac]
[jira] [Updated] (CASSANDRA-11431) java: error: unmappable character for encoding ASCII
[
https://issues.apache.org/jira/browse/CASSANDRA-11431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-11431:
-
Reviewer: Stefania
> java: error: unmappable character for encoding ASCII
>
>
> Key: CASSANDRA-11431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11431
> Project: Cassandra
> Issue Type: Bug
> Environment: java version "1.7.0_95"
> OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-0ubuntu0.15.10.1)
> OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
> Linux 22be6fbead2c 4.2.0-34-generic #39-Ubuntu SMP Thu Mar 10 22:11:28 UTC
> 2016 ppc64le ppc64le ppc64le GNU/Linux
>Reporter: Lorena Pesantez
>Assignee: Jay Zhuang
> Labels: lhf
> Fix For: 3.0.x
>
> Attachments: 11431-3.0-update.txt, 11431-3.0.txt
>
>
> I saw this closed issue with the exact same signature as the one I
> encountered, so cloning... I fixed the errors below by adding the line
> "" after lines 727 and 1089 of the
> cassandra/build.xml file. I am working PerfKitBenchmarker, so the workload
> must build on my platform (ppc64) without any changes after cloning it from
> github. Thanks!
> {code}
> build-project:
> [echo] apache-cassandra: /tmp/pkb/cassandra/build.xml
> [javac] Compiling 997 source files to
> /tmp/pkb/cassandra/build/classes/main
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/net/OutboundTcpConnection.java:106:
> error: unmappable character for encoding ASCII
> [javac] logger.info("OutboundTcpConnection coalescing window
> set to " + coalescingWindow + "??s");
> [javac]
> ^
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/net/OutboundTcpConnection.java:106:
> error: unmappable character for encoding ASCII
> [javac] logger.info("OutboundTcpConnection coalescing window
> set to " + coalescingWindow + "??s");
> [javac]
>^
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/utils/CoalescingStrategies.java:172:
> error: unmappable character for encoding ASCII
> [javac] logger.info(toString() + " gap " +
> TimeUnit.NANOSECONDS.toMicros(averageGap) + "??s");
> [javac]
> ^
> [javac]
> /tmp/pkb/cassandra/src/java/org/apache/cassandra/utils/CoalescingStrategies.java:172:
> error: unmappable character for encoding ASCII
> [javac] logger.info(toString() + " gap " +
> TimeUnit.NANOSECONDS.toMicros(averageGap) + "??s");
> [javac]
>^
> [javac] 4 errors
> BUILD FAILED
> /tmp/pkb/cassandra/build.xml:723: Compile failed; see the compiler error
> output for details.
> build-test:
> [javac] Compiling 263 source files to
> /tmp/pkb/cassandra/build/test/classes
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac] ^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac]^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac] ^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac] ^
> [javac]
> /tmp/pkb/cassandra/test/unit/org/apache/cassandra/cql3/validation/operations/UpdateTest.java:38:
> error: unmappable character for encoding ASCII
> [javac] execute("INSERT INTO %s (k, c, v, s) VALUES ('??', '??',
> '??', {'??'})");
> [javac]
[jira] [Updated] (CASSANDRA-12968) Configurable password policy in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-12968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Chauhan updated CASSANDRA-12968: Attachment: User Story - Password Policy.docx Attached (User Story - Password Policy.docx) are the initial User Stories for Password Policy feature. > Configurable password policy in Cassandra > - > > Key: CASSANDRA-12968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Prakash Chauhan >Assignee: Prakash Chauhan > Fix For: 3.x > > Attachments: User Story - Password Policy.docx > > > In Apache Cassandra , there are no strict password policies for creating a > new user. > A new user can be created with a password as simple as "abc" which is not at > all recommended for production use. Moreover the same password can be used > again and again. > There should be a configurable password policy in Cassandra for creating new > users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-13110) no host available exception
Dhruv created CASSANDRA-13110: - Summary: no host available exception Key: CASSANDRA-13110 URL: https://issues.apache.org/jira/browse/CASSANDRA-13110 Project: Cassandra Issue Type: Bug Reporter: Dhruv com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: localhost/127.0.0.1:9042 (com.datastax.driver.core.exceptions.ServerError: An unexpected error occurred server side on localhost/127.0.0.1:9042: java.nio.BufferUnderflowException)) at com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:84) at com.datastax.driver.core.exceptions.NoHostAvailableException.copy(NoHostAvailableException.java:37) at info.archinnov.achilles.internals.dsl.AsyncAware.extractCauseFromExecutionException(AsyncAware.java:34) at info.archinnov.achilles.internals.dsl.action.MutationAction.executeWithStats(MutationAction.java:49) at com.prontoitlabs.mobiadz.repository.AdvertiserRepository.updateAdvertiser(AdvertiserRepository.java:122) at com.prontoitlabs.mobiadz.service.impl.AdvertiserServiceImpl.updateAdvertiser(AdvertiserServiceImpl.java:248) at com.prontoitlabs.mobiadz.service.impl.OfferServiceImpl.add(OfferServiceImpl.java:183) at com.prontoitlabs.mobiadz.controller.OfferController.add(OfferController.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:267) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384) at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206) at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180) at org.glassfish.grizzly.http.server.HttpHandlerChain.doHandle(HttpHandlerChain.java:197) at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235) at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283) at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200) at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132) at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111) at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536) at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) at
[jira] [Updated] (CASSANDRA-13103) incorrect jvm metric names
[
https://issues.apache.org/jira/browse/CASSANDRA-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alain Rastoul updated CASSANDRA-13103:
--
Fix Version/s: 3.9
3.x
Status: Patch Available (was: Open)
> incorrect jvm metric names
> --
>
> Key: CASSANDRA-13103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13103
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Alain Rastoul
>Priority: Minor
> Labels: lhf
> Fix For: 3.x, 3.9
>
> Attachments: Fix-incorrect-jvm-metric-names-CASSANDRA-13103.patch
>
>
> Some jvm metrics have a double dot in name like:
> jvm.memory..total.max , jvm.memory..total.init (etc).
> it seems that an extra dot is added at the end of the name in
> CassandraDaemon.java, around line 367 (in 3.0.10):
> ...
> // enable metrics provided by metrics-jvm.jar
> CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new
> BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
> CassandraMetricsRegistry.Metrics.register("jvm.gc.", new
> GarbageCollectorMetricSet());
> CassandraMetricsRegistry.Metrics.register("jvm.memory.", new
> MemoryUsageGaugeSet());
> and also added in append method of MetricRegistry.
> Call stack is:
> MetricRegistry>>registerAll(String prefix, MetricSet metrics)
> MetricRegistry>>static String name(String name, String... names)
> MetricRegistry>>static void append(StringBuilder builder, String part)
> and in append the dot is also added:
> ...
> if(builder.length() > 0) {
> builder.append('.');
> }
> builder.append(part);
> ...
> The codahale MetricRegistry class seems to have no recent modification of
> name or append methods, so it look like a small bug.
> May be the fix could be to simply not to add the final dot in the metric
> name, ie "jvm.buffers" instead of "jvm.buffers."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-13103) incorrect jvm metric names
[
https://issues.apache.org/jira/browse/CASSANDRA-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15809186#comment-15809186
]
Alain Rastoul commented on CASSANDRA-13103:
---
The problem has been introduced in 3.9, CASSANDRA-12312 : Add JVM metrics for
custom metrics reporter, 2016-07-26.
It should be present in cassandra-2.2, cassandra-3.0, cassandra-3.11,
cassandra-3.X, trunk
I have attached a patch for 3.9 (and 3.X) which removes the unnecessary '.' and
added a unit test for jvm metrics registration.
I followed the 'How to contribute' wiki notes but was unable to assign myself
the issue.
May be an ASF member can tell me what to do or add me as assignable, in case I
could work on other LHF?
TIA
> incorrect jvm metric names
> --
>
> Key: CASSANDRA-13103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13103
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Alain Rastoul
>Priority: Minor
> Labels: lhf
> Attachments: Fix-incorrect-jvm-metric-names-CASSANDRA-13103.patch
>
>
> Some jvm metrics have a double dot in name like:
> jvm.memory..total.max , jvm.memory..total.init (etc).
> it seems that an extra dot is added at the end of the name in
> CassandraDaemon.java, around line 367 (in 3.0.10):
> ...
> // enable metrics provided by metrics-jvm.jar
> CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new
> BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
> CassandraMetricsRegistry.Metrics.register("jvm.gc.", new
> GarbageCollectorMetricSet());
> CassandraMetricsRegistry.Metrics.register("jvm.memory.", new
> MemoryUsageGaugeSet());
> and also added in append method of MetricRegistry.
> Call stack is:
> MetricRegistry>>registerAll(String prefix, MetricSet metrics)
> MetricRegistry>>static String name(String name, String... names)
> MetricRegistry>>static void append(StringBuilder builder, String part)
> and in append the dot is also added:
> ...
> if(builder.length() > 0) {
> builder.append('.');
> }
> builder.append(part);
> ...
> The codahale MetricRegistry class seems to have no recent modification of
> name or append methods, so it look like a small bug.
> May be the fix could be to simply not to add the final dot in the metric
> name, ie "jvm.buffers" instead of "jvm.buffers."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-13103) incorrect jvm metric names
[
https://issues.apache.org/jira/browse/CASSANDRA-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alain Rastoul updated CASSANDRA-13103:
--
Attachment: Fix-incorrect-jvm-metric-names-CASSANDRA-13103.patch
> incorrect jvm metric names
> --
>
> Key: CASSANDRA-13103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13103
> Project: Cassandra
> Issue Type: Bug
> Components: Observability
>Reporter: Alain Rastoul
>Priority: Minor
> Labels: lhf
> Attachments: Fix-incorrect-jvm-metric-names-CASSANDRA-13103.patch
>
>
> Some jvm metrics have a double dot in name like:
> jvm.memory..total.max , jvm.memory..total.init (etc).
> it seems that an extra dot is added at the end of the name in
> CassandraDaemon.java, around line 367 (in 3.0.10):
> ...
> // enable metrics provided by metrics-jvm.jar
> CassandraMetricsRegistry.Metrics.register("jvm.buffers.", new
> BufferPoolMetricSet(ManagementFactory.getPlatformMBeanServer()));
> CassandraMetricsRegistry.Metrics.register("jvm.gc.", new
> GarbageCollectorMetricSet());
> CassandraMetricsRegistry.Metrics.register("jvm.memory.", new
> MemoryUsageGaugeSet());
> and also added in append method of MetricRegistry.
> Call stack is:
> MetricRegistry>>registerAll(String prefix, MetricSet metrics)
> MetricRegistry>>static String name(String name, String... names)
> MetricRegistry>>static void append(StringBuilder builder, String part)
> and in append the dot is also added:
> ...
> if(builder.length() > 0) {
> builder.append('.');
> }
> builder.append(part);
> ...
> The codahale MetricRegistry class seems to have no recent modification of
> name or append methods, so it look like a small bug.
> May be the fix could be to simply not to add the final dot in the metric
> name, ie "jvm.buffers" instead of "jvm.buffers."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6271) Replace SnapTree in AtomicSortedColumns
[ https://issues.apache.org/jira/browse/CASSANDRA-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15809060#comment-15809060 ] Benedict commented on CASSANDRA-6271: - Do you mean in Cassandra, or more generally? > Replace SnapTree in AtomicSortedColumns > --- > > Key: CASSANDRA-6271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6271 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Benedict > Labels: performance > Fix For: 2.1 beta1 > > Attachments: 0001-Always-call-ReplaceFunction.txt, oprate.svg, > tmp.patch, tmp2.patch, tmp3.patch > > > On the write path a huge percentage of time is spent in GC (>50% in my tests, > if accounting for slow down due to parallel marking). SnapTrees are both GC > unfriendly due to their structure and also very expensive to keep around - > each column name in AtomicSortedColumns uses > 100 bytes on average > (excluding the actual ByteBuffer). > I suggest using a sorted array; changes are supplied at-once, as opposed to > one at a time, and if < 10% of the keys in the array change (and data equal > to < 10% of the size of the key array) we simply overlay a new array of > changes only over the top. Otherwise we rewrite the array. This method should > ensure much less GC overhead, and also save approximately 80% of the current > memory overhead. > TreeMap is similarly difficult object for the GC, and a related task might be > to remove it where not strictly necessary, even though we don't keep them > hanging around for long. TreeMapBackedSortedColumns, for instance, seems to > be used in a lot of places where we could simply sort the columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6271) Replace SnapTree in AtomicSortedColumns
[ https://issues.apache.org/jira/browse/CASSANDRA-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15809056#comment-15809056 ] Ethan W commented on CASSANDRA-6271: Hi [~benedict], I'm learning the data structure in SSTable. I have a question regarding Snaptree. what is the relationship between snap tree and skip list? Thanks! > Replace SnapTree in AtomicSortedColumns > --- > > Key: CASSANDRA-6271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6271 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Benedict > Labels: performance > Fix For: 2.1 beta1 > > Attachments: 0001-Always-call-ReplaceFunction.txt, oprate.svg, > tmp.patch, tmp2.patch, tmp3.patch > > > On the write path a huge percentage of time is spent in GC (>50% in my tests, > if accounting for slow down due to parallel marking). SnapTrees are both GC > unfriendly due to their structure and also very expensive to keep around - > each column name in AtomicSortedColumns uses > 100 bytes on average > (excluding the actual ByteBuffer). > I suggest using a sorted array; changes are supplied at-once, as opposed to > one at a time, and if < 10% of the keys in the array change (and data equal > to < 10% of the size of the key array) we simply overlay a new array of > changes only over the top. Otherwise we rewrite the array. This method should > ensure much less GC overhead, and also save approximately 80% of the current > memory overhead. > TreeMap is similarly difficult object for the GC, and a related task might be > to remove it where not strictly necessary, even though we don't keep them > hanging around for long. TreeMapBackedSortedColumns, for instance, seems to > be used in a lot of places where we could simply sort the columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
