[GitHub] cassandra pull request #71: Intruduce the fix for FixforCASSANDRA-11272

[zhiyanshao]

Github user zhiyanshao closed the pull request at:

https://github.com/apache/cassandra/pull/71


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cassandra pull request #71: Intruduce the fix for FixforCASSANDRA-11272

[zhiyanshao]

GitHub user zhiyanshao opened a pull request:

https://github.com/apache/cassandra/pull/71

Intruduce the fix for FixforCASSANDRA-11272



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zhiyanshao/cassandra 
2.2.5PlusFixforCASSANDRA-11272

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cassandra/pull/71.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #71


commit 1151249919e2eece40d3c2b51f13cf8803b45498
Author: Zhiyan Shao 
Date:   2016-06-20T17:53:01Z

Intruduce the fix for FixforCASSANDRA-11272




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Jira down, again?

[Michael Shuler]

On 06/20/2016 01:16 PM, Will Hayworth wrote:
> Hey all--I didn't want to add more heat than light to this, but I think at
> this point I'm behooved to speak up. :) I'm a developer at Atlassian (the
> folks who make JIRA); I don't work on JIRA itself but have some familiarity
> with its mechanics and administration and, at worst, could put someone from
> ASF in touch with a colleague to get things running more smoothly.
> 
> How can I/we help? :)

http://www.apache.org/dev/infra-contact

-- 
Kind regards,
Michael

Re: Jira down, again?

[Will Hayworth]

Hey all--I didn't want to add more heat than light to this, but I think at
this point I'm behooved to speak up. :) I'm a developer at Atlassian (the
folks who make JIRA); I don't work on JIRA itself but have some familiarity
with its mechanics and administration and, at worst, could put someone from
ASF in touch with a colleague to get things running more smoothly.

How can I/we help? :)

Will

___
Will Hayworth
Developer, Engagement Engine
Atlassian

My pronoun is "they". 



On Mon, Jun 20, 2016 at 10:55 AM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> Hm... weird, JIRA isn't working again? S bizarre!! 
>
> > On Jun 15, 2016, at 5:38 PM, Michael Kjellman <
> mkjell...@internalcircle.com> wrote:
> >
> > down. again.
> >
> >> On Jun 14, 2016, at 11:14 AM, Alex Popescu  wrote:
> >>
> >> I've been trying to get to a ticket for the last 2h and I only get
> service
> >> unavailable :-(
> >>
> >> On Tue, Jun 14, 2016 at 10:26 AM, Michael Kjellman <
> >> mkjell...@internalcircle.com> wrote:
> >>
> >>> and, it's down again. :(
> >>>
>  On Jun 14, 2016, at 4:48 AM, Dave Brosius 
> wrote:
> 
>  They are aware of these things
> 
>  https://twitter.com/infrabot 
> 
>  On 06/14/2016 05:28 AM, Giampaolo Trapasso wrote:
> > Hi to all,
> > at the moment is the same for me. Is there a way to notify to someone
> >>> this
> > situation?
> >
> > Giampaolo
> >
> > 2016-06-13 23:27 GMT+02:00 Mahdi Mohammadi :
> >
> >> And when it is not down, it is very slow for me.
> >>
> >> Do others have the same experience?
> >>
> >> Best Regards
> >>
> >> On Tue, Jun 14, 2016 at 4:19 AM, Brandon Williams  >
> >> wrote:
> >>
> >>> Everyone.
> >>>
> >>> On Mon, Jun 13, 2016 at 3:18 PM, Michael Kjellman <
> >>> mkjell...@internalcircle.com> wrote:
> >>>
>  Seems like Apache Jira is 100% down, again, for like the 500th
> time
> >>> in
> >>> the
>  last 2 months. Just me or everyone?
> 
> >>>
> >>>
> >>
> >>
> >> --
> >> Bests,
> >>
> >> Alex Popescu | @al3xandru
> >> Sen. Product Manager @ DataStax
> >>
> >> 
> >>
> >> » DataStax Enterprise - the database for cloud applications. «
> >
>
>

Re: Jira down, again?

[Michael Kjellman]

Hm... weird, JIRA isn't working again? S bizarre!! 

> On Jun 15, 2016, at 5:38 PM, Michael Kjellman  
> wrote:
> 
> down. again.
> 
>> On Jun 14, 2016, at 11:14 AM, Alex Popescu  wrote:
>> 
>> I've been trying to get to a ticket for the last 2h and I only get service
>> unavailable :-(
>> 
>> On Tue, Jun 14, 2016 at 10:26 AM, Michael Kjellman <
>> mkjell...@internalcircle.com> wrote:
>> 
>>> and, it's down again. :(
>>> 
 On Jun 14, 2016, at 4:48 AM, Dave Brosius  wrote:
 
 They are aware of these things
 
 https://twitter.com/infrabot 
 
 On 06/14/2016 05:28 AM, Giampaolo Trapasso wrote:
> Hi to all,
> at the moment is the same for me. Is there a way to notify to someone
>>> this
> situation?
> 
> Giampaolo
> 
> 2016-06-13 23:27 GMT+02:00 Mahdi Mohammadi :
> 
>> And when it is not down, it is very slow for me.
>> 
>> Do others have the same experience?
>> 
>> Best Regards
>> 
>> On Tue, Jun 14, 2016 at 4:19 AM, Brandon Williams 
>> wrote:
>> 
>>> Everyone.
>>> 
>>> On Mon, Jun 13, 2016 at 3:18 PM, Michael Kjellman <
>>> mkjell...@internalcircle.com> wrote:
>>> 
 Seems like Apache Jira is 100% down, again, for like the 500th time
>>> in
>>> the
 last 2 months. Just me or everyone?
 
>>> 
>>> 
>> 
>> 
>> -- 
>> Bests,
>> 
>> Alex Popescu | @al3xandru
>> Sen. Product Manager @ DataStax
>> 
>> 
>> 
>> » DataStax Enterprise - the database for cloud applications. «
> 

Re: Schema Disagreement vs Nodetool resetlocalschema

[Aleksey Yeschenko]

Schema will disagree during the upgrade itself, you can’t really work around 
it. It will converge once you finish the upgrade, however.

-- 
AY

On 20 June 2016 at 04:21:02, Michael Fong (michael.f...@ruckuswireless.com) 
wrote:

Hi,  

We have recently encountered several schema disagreement issue while upgrading 
Cassandra. In one of the cases, the 2-node cluster idled for over 30 minutes 
and their schema remain unsynced. Due to other logic flows, Cassandra cannot be 
restarted, and hence we need to come up an alternative on-the-fly. We are 
thinking to do a nodetool resetlocalschema to force the schema synchronization. 
How safe is this method? Do we need to disable thrift/gossip protocol before 
performing this function, and enable them back after resync completes?  

Thanks in advance!  

Sincerely,  

Michael Fong  

Re: Optimizing IOPS during sequential I/O (compactions)

[Stefania Alborghetti]

Hi Mike

Try reading the discussions on CASSANDRA-8894
, plus related
tickets, and CASSANDRA-8630
, both delivered in
3.0.

This code changed significantly in 3.0, and then again more recently in the
latest 3.x releases, and it is still in the process of changing. I am more
familiar with the 3.0 changes than the recent ones,  but if you are
interested in deep diving in the code, and if you specify which version, I
can be more precise and point you to the relevant code sections.

The quick summary is that, for standard access mode, the buffer size is set
to 64k if there is a limiter, even if its throughput is unlimited, which
means that for compaction and other seq. ops that use a limiter, the buffer
size will be 64k whilst for other read ops the buffer size, in 3.0+, is
calculated in SegmentedFile.bufferSize()

and it is based on the average record size, the disk type and two other
configurable parameters: the chance that a record will cross an aligned
cache page, and the percentile used to estimate the record size. You find
these 3 parameters here

and you may try optimizing them given that the ticket for benchmarking them,
CASSANDRA-10407 , is
still open. The buffer size will always be rounded to multiples of the
cache page size, 4k.

It is currently not possible to use mmap for one type of reads and std for
another type, as far as I know.

On Sun, Jun 19, 2016 at 6:17 PM, Mike Heffner  wrote:

> Hi,
>
> I'm curious to know if anyone has attempted to improve read IOPS
> performance during sequential I/O operations (largely compactions) while
> still maintaining read performance for small row, random-access client
> reads?
>
> Our use case is very high write load to read load ratio with rows that are
> small (< 1-2kb). We've taken many of the steps to ensure that client reads
> to random-access rows are optimal by reducing read_ahead and even using a
> smaller default LZ4 chunk size. So far performance has been great with p95
> read times that are < 10ms.
>
> However, we have noticed that our total read IOPS to the Cassandra data
> drive is extremely high compared to our write IOPS, almost 15x the write
> IOPS to the same drive. We even setup a ring that took the same write load
> with zero client reads and observed that the high read IOPS were driven by
> compaction operations. During large (>50GB) compactions, write and read
> volume (bytes) were nearly identical which matched our assumptions, while
> read iops were 15x write iops.
>
> When we plotted the average read and write op size we saw an average read
> ops size of just under 5KB and average write op of 120KB. Given we are
> using the default disk access mode of mmap, this aligns with our assumption
> that we are paging in a single 4KB page at a time while the write size is
> coalescing write flushes. We wanted to test this, so we switched a single
> node to `disk_access_mode:standard`, which should do reads based on the
> chunksizes, and found that read op size increased to ~7.5KB:
>
> https://imgur.com/okbfFby
>
> We don't want to sacrifice our read performance, but we also must
> scale/size our disk performance based on peak iops. If we could cut the
> read iops by a quarter or even half during compaction operations, that
> would mean a large cost savings. We are also limited on drive throughput,
> so there's a theoretical maximum op size we'd want to use to stay under
> that throughput limit. Alternatively, we could also tune compaction
> throughput to maintain that limit too.
>
> Has any work been done to optimize sequential I/O operations in Cassandra?
> Naively it seems that sequential I/O operations could use a standard disk
> access mode reader with configurable block size while normal read
> operations stuck to the mmap'd segments. Being unfamiliar with the code,
> are compaction/sequential sstable reads done through any single interface
> or does it use the same as normal read ops?
>
> Thoughts?
>
> -Mike
>
> --
>
>   Mike Heffner 
>   Librato, Inc.
>



-- 


[image: datastax_logo.png] 

Stefania Alborghetti

Apache Cassandra Software Engineer

|+852 6114 9265| stefania.alborghe...@datastax.com


[image: cassandrasummit.org/Email_Signature]