Nodes seem to freeze after some period of time in Apache Cassandra 

Some portion of the JVM is being swapped out by the Linux operating system.

Attention: DataStax Enterprise customers. Do not use the topics in this section. See Troubleshooting DataStax Enterprise.

Some portion of the JVM is being swapped out by the Linux operating system (OS).

Linux

Check your system.log for messages from the GCInspector. If the GCInspector is indicating that either the ParNew or ConcurrentMarkSweep collectors took longer than 15 seconds, there is a high probability that some portion of the JVM is being swapped out by the OS.

DataStax strongly recommends disabling swap entirely (sudo swapoff --all). Because Cassandra has multiple replicas and transparent failover, it is preferable for a replica to be killed immediately when memory is low rather than go into swap. This allows traffic to be immediately redirected to a functioning replica instead of continuing to hit the replica that has high latency due to swapping. If your system has a lot of DRAM, swapping still lowers performance significantly because the OS swaps out executable code so that more DRAM is available for caching disks. To make this change permanent, remove all swap file entries from /etc/fstab.

If you insist on using swap, you can set vm.swappiness=1. This allows the kernel swap out the absolute least used parts.

If the GCInspector isn't reporting very long GC times, but is reporting moderate times frequently (ConcurrentMarkSweep taking a few seconds very often) then it is likely that the JVM is experiencing extreme GC pressure and will eventually OOM. See Nodes are dying with OOM errors in Apache Cassandra.