PgConf US 2017

[Joshua D. Drake]

Hello folks,

This is the last week of the PGConf US 2017 CFP. It would be great to 
see some integrated content from other communities.


http://www.pgconf.us/2017/submit/

Sincerely,

JD
--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

Re: STCS in L0 behaviour

[Eric Evans]

On Sat, Nov 26, 2016 at 6:30 PM, Dikang Gu  wrote:
> Hi Marcus,
>
> Do you have some stack trace to show that which function in the `
> getNextBackgroundTask` is most expensive?
>
> Yeah, I think having 15-20K sstables in L0 is very bad, in our heavy-write
> cluster, I try my best to reduce the impact of repair, and keep number of
> sstables in L0 < 100.
>
> Thanks
> Dikang.
>
> On Thu, Nov 24, 2016 at 12:53 PM, Nate McCall  wrote:
>
>> > The reason is described here:
>> https://issues.apache.org/jira/browse/CASSANDRA-5371?
>> focusedCommentId=13621679&page=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-13621679
>> >
>> > /Marcus
>>
>> "...a lot of the work you've done you will redo when you compact your now
>> bigger L0 sstable against L1."
>>
>> ^ Sylvain's hypothesis (next comment down) is actually something we see
>> occasionally in practice: having to re-write the contents of L1 too often
>> when large L0 SSTables are pulled in. Here is an example we took on a
>> system with pending compaction spikes that was seeing this specific issue
>> with four LCS-based tables:
>>
>> https://gist.github.com/zznate/d22812551fa7a527d4c0d931f107c950
>>
>> The significant part of this particular workload is a burst of heavy writes
>> from long-duration scheduled jobs.
>>
>
>
>
> --
> Dikang



-- 
Eric Evans
john.eric.ev...@gmail.com

Segfaults in Unit Test Results on CI

[Oleksandr Petrov]

Hi everyone,

Wanted to ask everyone to take extra care when you see error messages such
as:

Forked Java VM exited abnormally. Please note the time in the report
does not reflect the time until the VM exit.


in your unit test reports on cassci. When you see such a failure, please
always check the full log to see what happened to the JVM, since in the
full log output there might be more information on why JVM exited, which
may be a serious issue, for example segfault due to native memory access.

Since junit already does report it all, I just wanted to stress that if you
see such things, just take a minute to check out logs in more details. If
you already do it this way - it's great and awesome.

If you would like to see an example of such report, you can refer to this
issue [1]

[1] https://issues.apache.org/jira/browse/CASSANDRA-12957

-- 
Alex Petrov

Re: [VOTE FAILED] Release Apache Cassandra 3.10 (Take 3)

[Michael Shuler]

Thanks for the feedback all. For the previous listed reasons, I'll swap
to a -1 vote, too.

I count 2 binding +1, 3 binding -1, and 3 non-binding -1 votes.

Since cassandra-3.11 was branched last week for fixes on top of 3.10, it
seems that the next 3.10 candidate could just come from the
cassandra-3.11 branch.

-- 
Kind regards,
Michael

On 11/18/2016 12:08 PM, Michael Shuler wrote:
> I propose the following artifacts for release as 3.10.
> 
> sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1135/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1135/
> 
> The Debian packages are available here: http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: (CHANGES.txt) https://goo.gl/vah74X
> [2]: (NEWS.txt) https://goo.gl/In3vp7
> 




signature.asc
Description: OpenPGP digital signature