Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9BE801121E for ; Tue, 3 Jun 2014 03:07:37 +0000 (UTC) Received: (qmail 94661 invoked by uid 500); 3 Jun 2014 03:07:35 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 94619 invoked by uid 500); 3 Jun 2014 03:07:35 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 94611 invoked by uid 99); 3 Jun 2014 03:07:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2014 03:07:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of monster.bin@gmail.com designates 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-we0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2014 03:07:30 +0000 Received: by mail-we0-f178.google.com with SMTP id u56so5917591wes.23 for ; Mon, 02 Jun 2014 20:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=qM5LjtfNvo0K4+Bv8+r1/tVsR2OVbqNp2tFe32oHTsU=; b=oMH9bAwSR1z5qVM6jc4/dHiA5Wuh504cYCqyCMHm6W6B4HSDssoTlmPbzKwBPsdgob +04fEu5lIn4T6y30Hvnx9Y2fUyvId8+Gvl6oFqS7VfrVLjIgj9y+j+3m9gd/jx73/upr UsnU+EGTcSqKzOAFHKPNXIb1E8DaTm+zxprXJOvunqIBx051p3o2YVJkmq59rHeBZzSj yy9/vAIXsutOEV+R4q20fRuivgyLjPqgRbPVoGc8ni7LrtvK4FkYggB6KPtYvTjbWv9E +yhfBlBSAPExpyU8Iv9IcjWCyhJQ52GbLqiBKurXTYi6YoYNbkl+BRXuA4GWqoEAl+Lp 4+zQ== MIME-Version: 1.0 X-Received: by 10.194.236.169 with SMTP id uv9mr54026697wjc.46.1401764827601; Mon, 02 Jun 2014 20:07:07 -0700 (PDT) Sender: monster.bin@gmail.com Received: by 10.194.157.166 with HTTP; Mon, 2 Jun 2014 20:07:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jun 2014 12:07:07 +0900 X-Google-Sender-Auth: 54xCv9IGA5P-VB3c6NdNt_kih0Q Message-ID: Subject: Re: Paxos table gets larger when using 'IF NOT EXISTS' From: Frederick Haebin Na To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e014940249ba43704fae5ce57 X-Virus-Checked: Checked by ClamAV on apache.org --089e014940249ba43704fae5ce57 Content-Type: text/plain; charset=UTF-8 Sorry for spamming, folks. Okay, I found out why it is growing. system.paxos row count is actually 3% greater than the data table. It may be caused by re-insertion of some data range. My ultimate question now would be why the paxos rows are not getting removed after the transaction. There is high disk IO on the directory of the server where there are paxos table files. And the insertion gets slower and slower. (Yes, it seems to be somewhat anti-pattern since we are using 'IF NOT EXISTS' massively, yet, still, I don't understand why it is getting slower like this.) Thanks. Haebin 2014-06-03 11:20 GMT+09:00 Frederick Haebin Na : > Sorry, I found out what are in the system.paxos. > > select * from system.paxos limit 1; > > | row_key | cf_id | in_porgress_ballot | most_recent_commit | > most_recent_commit_at | proposal | proposal_ballot | > > I will investigate more on why it is growing continuously. > If anyone have an idea why it is like this, please, share your experiences. > > Thank you. > > Haebin > > > > 2014-06-03 11:00 GMT+09:00 Frederick Haebin Na : > > Hello all, >> >> We are trying to migrate data with 'INSERT IF NOT EXISTS' clause. >> Yet, strange thing is that the system.paxos table gets larger like 100GB >> which is equal to the size of the data table. >> >> Does anyone know what is happening here? >> What does system.paxos table store? >> >> Thank you. >> >> Haebin >> > > --089e014940249ba43704fae5ce57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for spamming, folks.

Okay, = I found out why it is growing.

system.paxos row count is= actually 3% greater than the data table.
It may be caused by re-= insertion of some data range.

My ultimate question now would be why the paxos rows ar= e not getting removed after the transaction.

There= is high disk IO on the directory of the server where there are paxos table= files.
And the insertion gets slower and slower.

(Ye= s, it seems to be somewhat anti-pattern since we are using 'IF NOT EXIS= TS' massively, yet, still, I don't understand why it is getting slo= wer like this.)

Thanks.

Haebin

<= /div>
=C2=A0




2014-06-03 11:2= 0 GMT+09:00 Frederick Haebin Na <haebin.na@gmail.com>:
Sorry, I found out what are= in the system.paxos.

select * from system.paxos limit 1= ;

| row_key | cf_id | in_porgress_ballot | most_rec= ent_commit | most_recent_commit_at | proposal | proposal_ballot |

I will investigate more on why it is growing continuous= ly.
If anyone have an idea why it is like this, please, share you= r experiences.

Thank you.

Haebin



2014-06-03 11:00 GMT+09:00 Frederick Haebin Na <haebin.na@gmail.com>:

Hello all,

We are trying to migrate data with 'INSERT IF NOT EXISTS' clause= .
Yet, strange thing is that the system.paxos table gets larger like 100= GB which is equal to the size of the data table.

Does anyone know what is happening here?
What= does system.paxos table store?

Thank you.

Haebin=C2=A0


--089e014940249ba43704fae5ce57--