cassandra heap size config

[yuyantingzero]

Currently, the cassandra_stress_benchmark does not run on some instances types due to not enough heap in JVM, for example C4.2xlarge.
The default max_heap_size used is max(min(1/2 of the memory in the vm, 1GB), min(1/4 of the memory in the vm, 8GB)). In a C4.2xlarge vm, the max_heap_size is only 3,4 G.
Should we just leave the configuration as it is (mostly default), or try to tune the configurations a bit (increase the ratio of max_heap/memory on vm) to allow the benchmark run on all instance types and also allow users to change configurations?

[yuyantingzero]

The current configration used in cassandra_stress_benchmark is the same as http://storage.googleapis.com/p3rf-downloads/cassandra_1m_writes_per_sec_gist.tgz, except for the heap size, we used default to allow cassandra to run on small instances.

[ivansmf]

Larger heaps are better for write intensive workloads, and smaller heaps better for read intensive workloads. My suggestion is that we use 4GB and not run the tests on smaller VMs.

The DataStax documentation (http://docs.datastax.com/en/cassandra/1.2/cassandra/architecture/architecturePlanningHardware_c.html) says that the minimum hardware for both dedicated hardware and virtual environments is as follows:

• Production: 16GB to 64GB; the minimum is 8GB of RAM
• Development in non-loading testing environments: no less than 4GB of RAM.

So my suggestion is to not run the benchmark on anything with less than 8GB of RAM.

[yuyantingzero]

I agree that running on small instance types doesn't make much sense, we should tell the users not to run this benchmark on small instance types in README. But this problem is different.

C4.2xlarge machines actually has 15 GB memory, the default max heap is approximately 4 GB. But the amount of memory C4.2xlarge has is much less than the general purpose machine types with same number of cores (m3.2xlarge and n1-standard-8 both have 30 GB memory).
My point here is the size of heap should grow with the number of cores loader nodes have. Otherwise, with large compute instance types, it will still break.

[ivansmf]

The default install takes care of the heap size. You don't have to set it
explicitly, so don't.

The Cassandra file containing this logic is cassandra-env.sh. If you're
using setup_cassandra.sh you'd have to remove the used statement from there
as well.

Ivan

On Thursday, April 2, 2015, yuyanting [email protected] wrote:

I agree that running on small instance types doesn't make much sense, we
should tell the users not to run this benchmark on small instance types in
README. But this problem is different.

C4.2xlarge machines actually has 15 GB memory, the default max heap is
approximately 4 GB. But the amount of memory C4.2xlarge has is much less
than the general purpose machine types with same number of cores
(m3.2xlarge and n1-standard-8 both have 30 GB memory).
My point here is the size of heap should grow with the number of cores
loader nodes have. Otherwise, with large compute instance types, it will
still break.

—
Reply to this email directly or view it on GitHub
#204 (comment)
.

[voellm]

If we make this change we have to do it under a flag for now. If flag
should default to how it is now and setting the flag removes (or sets) the
memory config once we decide.
On Apr 4, 2015 1:01 AM, "Ivan Filho" [email protected] wrote:

The default install takes care of the heap size. You don't have to set it
explicitly, so don't.

The Cassandra file containing this logic is cassandra-env.sh. If you're
using setup_cassandra.sh you'd have to remove the used statement from there
as well.

Ivan

On Thursday, April 2, 2015, yuyanting [email protected] wrote:

I agree that running on small instance types doesn't make much sense, we
should tell the users not to run this benchmark on small instance types
in
README. But this problem is different.

C4.2xlarge machines actually has 15 GB memory, the default max heap is
approximately 4 GB. But the amount of memory C4.2xlarge has is much less
than the general purpose machine types with same number of cores
(m3.2xlarge and n1-standard-8 both have 30 GB memory).
My point here is the size of heap should grow with the number of cores
loader nodes have. Otherwise, with large compute instance types, it will
still break.

—
Reply to this email directly or view it on GitHub
<
#204 (comment)

.

—
Reply to this email directly or view it on GitHub
#204 (comment)
.

[voellm]

This benchmark has been reworked by @yuyantingzero and @cmccoy. We also now have cassandra_ycsb

Is this still relevant? Is so please reopen and explain what will be done. Thanks!

[cmccoy]

This is still relevant. If we want to revert to the defaults, we should remove these customizations.