Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of michalm@opera.com designates
 213.236.208.81 as permitted sender)
Message-ID: <5151A4C0.3090908@opera.com>
Date: Tue, 26 Mar 2013 14:38:08 +0100
From: Michal Michalski <michalm@opera.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Re: index_interval file size is the same after modifying 128 to 512?
References: <CD76EE57.24553%Dean.Hiller@nrel.gov>
In-Reply-To: <CD76EE57.24553%Dean.Hiller@nrel.gov>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

OK, thanks for reply :-)

W dniu 26.03.2013 13:20, Hiller, Dean pisze:
> We only look at our program's response time at the high level and have a
> scatter plot.  The scatter plot shows no real differences so even though
> what you say may be true, our end users are not seeing any differences.  I
> have not checked the any further because the high level use cases look
> great.
>
> Dean
>
> On 3/26/13 2:35 AM, "Michal Michalski" <michalm@opera.com> wrote:
>
>> Dean, as I can see you are satisfied with the result of increasing ii
>>from 128 to 512, didn't you observed any drawbacks of this change? I
>> remember you mentioned no change in Read Latency and a significant drop
>> of heap size, but did you check any other metrics?
>>
>> I did the opposite (512 -> 128; before we've had problems with heap
>> size, now we can revert it, so I check if it makes sense) and I do not
>> see almost any difference in Read Latency too, but I can see that the
>> number of dropped READ messages has decreased significantly (it's 1 or
>> even 2 orders of magnitude lower for the nodes I set ii = 128 comparing
>> to the nodes with ii = 512; the exact value is about 0.005 / sec.
>> comparing to about 0.01 - 0.2 for other nodes) and I have much less
>> connection resets reported by netstat's Munin plugin. In other words, as
>> I understand it - there's much less timeouts which should improve
>> overall C* performance, even if I can't see it in read latency graph for
>> CFs (unluckily I don't have a graph for StorageProxy latencies to easily
>> check it).
>>
>> To make sure about the reason of this differences and its effect on C*
>> performance, I'm looking for some "references" in other people's
>> experience / observations :-)
>>
>> M.
>>
>> W dniu 22.03.2013 17:17, Hiller, Dean pisze:
>>> I was just curious.  Our RAM has significantly reduced but the
>>> *Index.db files are the same size size as before.
>>>
>>> Any ideas why this would be the case?
>>>
>>> Basically, Why is our disk size not reduced since RAM is way lower?  We
>>> are running strong now with 512 index_interval for past 2-3 days and RAM
>>> never looked better.  We were pushing 10G before and now we are 2G
>>> slowing increasing to 8G before gc compacts the long lived stuff which
>>> goes back down to 2G again�..very pleased with LCS in our system!!!!!
>>>
>>> Thanks,
>>> Dean
>>>
>>