One last word on the effect of memory mapped IO on the VIRT, RES and
SHR columns in the output of the top utility.
With mmap enabled, VIRT can be big, as much as the sum of the size of
all index and data files and the sizes of shared libraries. RES is the
sum of the sizes of
1) the Java heap,
2)
Ok, so I think I found one major cause contributing to the increasing
Nice job tracking this down! That is useful to know, even outside of
Cassandra use cases. Frankly it's disappointing to learn what nio is
doing.
--
/ Peter Schuller
Great debugging work!
That workaround sounds like the best alternative to me too.
On Sat, May 14, 2011 at 9:46 PM, Hannes Schmidt han...@eyealike.com wrote:
Ok, so I think I found one major cause contributing to the increasing
resident size of the Cassandra process. Looking at the OpenJDK
As promised: https://issues.apache.org/jira/browse/CASSANDRA-2654
On Sun, May 15, 2011 at 7:09 AM, Jonathan Ellis jbel...@gmail.com wrote:
Great debugging work!
That workaround sounds like the best alternative to me too.
On Sat, May 14, 2011 at 9:46 PM, Hannes Schmidt han...@eyealike.com
I have not looked into smaps before. But it actually seems odd that that
mmaped Index files are taking up so *little memory*. Are they only a
few kb on disk?
The sum of the sizes of all *-Index.db files in /var/lib/cassandra is 2924kb.
Is this a snapshot taken shortly after the process
On Thu, May 5, 2011 at 5:56 PM, Benjamin Coverston
ben.covers...@datastax.com wrote:
How many column families do you have?
We have 10 key spaces, each with 2 column families.
On 5/4/11 12:50 PM, Hannes Schmidt wrote:
Hi,
We are using Cassandra 0.6.12 in a cluster of 9 nodes. Each node is
On Thu, May 5, 2011 at 4:16 PM, aaron morton aa...@thelastpickle.com wrote:
Hannes,
To get a baseline of behaviour set disk_access to standard. You will
probably want to keep it like that if you want better control over the memory
on the box.
I'll do a test with standard and report
On Thu, May 5, 2011 at 6:16 PM, aaron morton aa...@thelastpickle.com wrote:
Hannes,
To get a baseline of behaviour set disk_access to standard. You will
probably want to keep it like that if you want better control over the memory
on the box.
Changing disk access mode just gives you
Probably this is because of mmapped io access mode, which is enabled by default
in 64-bit VMs - RAM is occupied by data files.
If you have such a tight memory reqs, you can turn on standard access mode in
storage-conf.xml, but dont expect it to work fast then:
!--
This was my first thought, too. We switched to mmap_index_only and
didn't see any change in behavior. Looking at the smaps file attached
to my original post, one can see that the mmapped index files take up
only a minuscule part of RSS.
On Wed, May 4, 2011 at 11:37 PM, Oleg Anastasyev
On 2011-05-05 06:30, Hannes Schmidt wrote:
This was my first thought, too. We switched to mmap_index_only and
didn't see any change in behavior. Looking at the smaps file attached
to my original post, one can see that the mmapped index files take up
only a minuscule part of RSS.
I have not
Reading this, I tried it again (this time on a freshly formated node due to
hd failure).
Before crashing, my data dir was only 7.7M big. Using nmap_indexonly
(mlockall was successfull) on a 64bit machine.
Anything else I could try to get this to work? Ps. All the other nodes (and
this node) run
Hannes,
To get a baseline of behaviour set disk_access to standard. You will
probably want to keep it like that if you want better control over the memory
on the box.
Also connect to the box with JConsole and look at the PermGen space
used it is not included in the max heap
How many column families do you have?
On 5/4/11 12:50 PM, Hannes Schmidt wrote:
Hi,
We are using Cassandra 0.6.12 in a cluster of 9 nodes. Each node is
64-bit, has 4 cores and 4G of RAM and runs on Ubuntu Lucid with the
stock 2.6.32-31-generic kernel. We use the Sun/Oracle JDK.
Here's the
Hi,
We are using Cassandra 0.6.12 in a cluster of 9 nodes. Each node is
64-bit, has 4 cores and 4G of RAM and runs on Ubuntu Lucid with the
stock 2.6.32-31-generic kernel. We use the Sun/Oracle JDK.
Here's the problem: The Cassandra process starts up with 1.1G resident
memory (according to top)
15 matches
Mail list logo
