cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viktor Jevdokimov <>
Subject RE: High commit size
Date Mon, 10 Sep 2012 13:41:45 GMT
Do not use mmap/auto on Windows, standard access mode only. In cassandra.yaml:
disk_access_mode: standard

Best regards / Pagarbiai
Viktor Jevdokimov
Senior Developer

Phone: +370 5 212 3063, Fax +370 5 261 0453
J. Jasinskio 16C, LT-01112 Vilnius, Lithuania
Follow us on Twitter: @adforminsider<!/adforminsider>
What is Adform: watch this short video<>

[Adform News] <>

Visit us at Dmexco: Hall: 7, Aisle: A, Stand: 030
September 12-13 Cologne, Germany
[dmexco] <>

Disclaimer: The information contained in this message and attachments is intended solely for
the attention and use of the named addressee and may be confidential. If you are not the intended
recipient, you are reminded that the information remains the property of the sender. You must
not use, disclose, distribute, copy, print or rely on this e-mail. If you have received this
message in error, please contact the sender immediately and irrevocably delete this message
and any copies.

From: Rene Kochen []
Sent: Monday, September 10, 2012 14:47
Subject: Re: High commit size

The problem is that the system just freezes and nodes are dying. The system becomes very unresponsive
and it always happens when the shareable amount of RAM reaches the total number of bytes in
the system.

Is there something in Windows that I can tune in order to avoid this behavior? I cannot easily
migrate to Linux right now.



2012/9/10 Oleg Dulin <<>>
It is memory-mapped I/O. I wouldn't worry about it.

BTW, Windows might not be the best choice to run Cassandra on. My experience running Cassandra
on Windows has not been positive one. We no longer support Windows as our production platform.


On 2012-09-10 09:00:02 +0000, Rene Kochen said:
Hi all,

On my test cluster I have three Windows Server 2008 R2 machines running Cassandra 1.0.11

If i use memory mapped IO (the default), then the nodes freeze after a while. Paging is disabled.

The private bytes are OK (8GB). That is the amount I use in the -Xms and -Xmx arguments. The
virtual size is big as expected because of the memory mapped IO. However, the working set
size (size in RAM) is 24 GB (my total RAM usage). If I look with Process Explorer to the physical
memory section I see a very high value in the "WS Sharable" section.

Anyone has a clue what is going om here?

Many thanks!


Oleg Dulin
NYC Java Big Data Engineer

View raw message