[
https://issues.apache.org/jira/browse/CASSANDRA-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028291#comment-13028291
]
Peter Schuller commented on CASSANDRA-2594:
-------------------------------------------
If you wish to see how things are balanced on production systems, 'numactl -H'
should show you. For example:
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14
node 0 size: 24576 MB
node 0 free: 41 MB
node 1 cpus: 1 3 5 7 9 11 13 15
node 1 size: 24566 MB
node 1 free: 3573 MB
node distances:
node 0 1
0: 10 20
1: 20 10
> run cassandra under numactl --interleave=all
> --------------------------------------------
>
> Key: CASSANDRA-2594
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2594
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Peter Schuller
> Assignee: Peter Schuller
> Priority: Minor
> Attachments: CASSANDRA-2594-trunkk.txt
>
>
> By default, Linux attempts to be smart about memory allocations such that
> data is close to the NUMA node on which it runs. For big database type of
> applications, this is not the best thing to do if the priority is to avoid
> disk I/O. In particular with Cassandra, we're heavily multi-threaded anyway
> and there is no particular reason to believe that one NUMA node is "better"
> than another.
> Consequences of allocating unevenly among NUMA nodes can include excessive
> page cache eviction when the kernel tries to allocate memory - such as when
> restarting the JVM.
> With that briefly stated background, I propse the following patch to make the
> Cassandra script run Cassandra with numactl --interleave=all if numactl seems
> to be available.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
