This FAQ entry and the linked document provide a pretty good explanation:
http://wiki.apache.org/cassandra/FAQ#mmap
By the way, you should almost always turn off swap.
On Thu, Nov 17, 2011 at 1:16 AM, Jaesung Lee wrote:
> I am running 7 nodes cassandra(v1.0.2) cluster.
> I am putting 20K rows
I watched the logs pretty carefully as scrub ran and it definitely
skipped/deleted some problematic rows so perhaps that would explain the tmp
sstables but I'm not sure. Either way, they weren't still being written to
and after casting my restart spell, everything is totally fine and the tmp
table
tmp files are temporary in nature, if they fail to live up to their name then
they are against nature.
If they are still been written to then something is happening, either a flush
or a compaction. Check nodetool compactstats
They may indicate errors during the scrub (or compact), check the lo
Scrub seems to have worked. Thanks again!
Will a major compaction delete the "tmp" sstables genereated though? Scrub
seems to have generated a lot of them and they're taking up an unnerving
amount of disk space.
On Mon, Sep 19, 2011 at 5:34 PM, Eric Czech wrote:
> Ok then I'll shutdown the se
Ok then I'll shutdown the server, change the access mode, restart, and
run scrub (and then change the access mode back).
Thanks for the pointers and I'll let you know how it goes one way or the other.
On Tue, Sep 20, 2011 at 12:29 AM, aaron morton wrote:
> I've also found it useful to disable me
I've also found it useful to disable memmapped file access until the scrub is
complete by adding this to the yaml
disk_access_mode: standard
Cheers
-
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 20/09/2011, at 6:55 AM, Jonathan Ellis w
You should start with scrub.
On Mon, Sep 19, 2011 at 1:04 PM, Eric Czech wrote:
> I'm getting a lot of errors that look something like "java.io.IOError:
> java.io.IOException: mmap segment underflow; remaining is 348268797
> but 892417075 requested" on one node in a 10 node cluster. I'm
> curren
My guess would be CASSANDRA-2675. Upgrade to the latest version in
your release series, if you haven't.
On Sat, Aug 27, 2011 at 9:53 AM, Chad Johnson wrote:
> Hi,
>
> We periodically get the following exception in our Cassandra cluster. What I
> mean by periodically is once or twice a week. It
Try the patch at https://issues.apache.org/jira/browse/CASSANDRA-2417
On Mon, Apr 4, 2011 at 11:18 AM, Or Yanay wrote:
> Hi All,
>
>
>
> I have upgraded from 0.7.0 to 0.7.4, and while running scrub I get the
> following exception quite a lot:
>
>
>
> java.lang.AssertionError: mmap segment underfl
I am considering treating the node as a dead node, delete it's data files and
bootstrap from scratch.
Is that a reasonable approach? Is there a way for me to identify the bad file/s
and remove it/them?
From: Or Yanay [mailto:o...@peer39.com]
Sent: Monday, April 04, 2011 7:19 PM
To: user@cassandr
> Not 100% relevant but I found this to be interesting if you're nodes are
> doing heavy disk I/O:
>
> http://rackerhacker.com/2008/08/07/reduce-disk-io-for-small-reads-using-memory/
There are some pitfalls though, or at least there were the last time I
was tweaking such stuff for a PostgreSQL da
Not 100% relevant but I found this to be interesting if you're nodes are doing
heavy disk I/O:
http://rackerhacker.com/2008/08/07/reduce-disk-io-for-small-reads-using-memory/
-Chris
On Jul 15, 2010, at 11:47 PM, Peter Schuller wrote:
>> This would require that Cassandra run as root on Linux sy
> This would require that Cassandra run as root on Linux systems, as 'man
> mlockall' states:
IIRC, mlock() (as opposed to mlockall()) does not require root
privileges - but is subject to resource limitations.
However, given a lack of control of how memory is allocated in the JVM
I suppose mlock
On Thu, Jul 15, 2010 at 5:46 PM, Clint Byrum wrote:
> One other approach that works on Linux is to use HugeTLB. This post details
> the process for doing so with a jvm:
>
> http://andrigoss.blogspot.com/2008/02/jvm-performance-tuning.html
>
> Basically when mmapping using HUGETLB you don't have t
On Jul 15, 2010, at 2:52 PM, Jonathan Ellis wrote:
> On Thu, Jul 15, 2010 at 3:56 PM, Carlos Alvarez wrote:
>> On Thu, Jul 15, 2010 at 2:01 PM, Jonathan Ellis wrote:
>>> The main problem is not the syscall so much as Java insisting on
>>> zeroing out any buffer you create, which is a big hit to
On Thu, Jul 15, 2010 at 3:56 PM, Carlos Alvarez wrote:
> On Thu, Jul 15, 2010 at 2:01 PM, Jonathan Ellis wrote:
>> The main problem is not the syscall so much as Java insisting on
>> zeroing out any buffer you create, which is a big hit to performance
>> when you're allocating buffers for file i/
On Thu, Jul 15, 2010 at 2:01 PM, Jonathan Ellis wrote:
> The main problem is not the syscall so much as Java insisting on
> zeroing out any buffer you create, which is a big hit to performance
> when you're allocating buffers for file i/o on each request instead of
> just mmaping things. Re-using
> I'm convinced. :) See comments on
> https://issues.apache.org/jira/browse/CASSANDRA-1214
Noted :) To be clear I only mentioned it as an acknowledgement that
everyone didn't necessarily agree with what I was saying.
> The main problem is not the syscall so much as Java insisting on
> zeroing ou
On Thu, Jul 15, 2010 at 11:41 AM, Peter Schuller
wrote:
> Not really. That is, the intent of mmap is to let the OS dynamically
> choose what gets swapped in and out. The practical problem is that the
> OS will often tend to swap too much. I got the impression jbellis
> wasn't convinced, but my ane
I found, for large dataset, long-term random reading test, the performance
with mmap is very bad.
See the attached chart in
https://issues.apache.org/jira/browse/CASSANDRA-1214.
On Fri, Jul 16, 2010 at 12:41 AM, Peter Schuller <
peter.schul...@infidyne.com> wrote:
> > Can someone please explain t
> Can someone please explain the mmap issue.
> mmap is default for all storage files for 64bit machines.
> according to this case https://issues.apache.org/jira/browse/CASSANDRA-1214
> it might not be a good thing.
> Is it right to say that you should use mmap only if your MAX expected data
> is sm
21 matches
Mail list logo
