Cassandra 线上环境配置建议

JDK

使用最新的JVM 使用最新的64位Oracle Java Platfom标准的JDK8，或者OpenJDK8

同步时钟

同步所有节点上的时钟，使用NTP(网络时间协议)或者其他方法。 之所以需要是因为当机器在不同的地理位置时，Cassandra 会覆盖掉某一列当这列有个更新版本的时间戳

Cassandra 时间戳是按照微秒编码的，因为UNIX日期不带时区信息。Cassandra 所有写入的时间戳是形式是UTC，DataStax建议只有当需要输出给人看的时候，才转化为本地的一个时间。

TCP配置

为了处理Cassandra的成千上万的并发连接，以下Linux网络按以下配置。将这些配置加到/etc/sysctl.conf

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.optmem_max = 40960
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

让配置立即生效(取决于你的linux发行版本)

sudo sysctl -p /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.d/filename.conf

禁掉CPU调频

最近的linux系统都会包含一个模块叫做CPU调频，或者CPU速度调节。它允许一个机器时钟速度能够动态的调节，这样机器就可以在负载低的时候以低速度工作。这样可以降低机器电量的消耗，和散热（这会极大的影响制冷花费）。不幸的是，这种行为对于运行了Cassandra的机器有不利的影响，因为并发量会固定在一个低的速值。

在大部分的linux系统，CPUfreq基于定义的规则管理频率的调节，默认的ondemand调频器会在负载高的时候将时钟频率切换到最高，当系统空闲的时候讲时钟频率切换到最低。

不要使用默认的调频器来降低CPU频率。为了确保获得一个好的性能，使用performance 调频器来重新配置所有的CPUs。performance 调频器会将频率锁定在最大值。这种调频器不会切换频率，这就意味着不能节省电力但是机器可以一直在最大的并发量上运行。对于大部分的系统，按以下配置调频器

for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
    [ -f $CPUFREQ ] || continue
    echo -n performance > $CPUFREQ
done

[了解更多信息](https://support.datastax.com/hc/en-us/articles/115003018063\）

确保重启后新的配置生效

注意：

取决于你的环境，下面的一些配置可能在重启机器后不生效，和你系统管理员确认，确保这些配置在你的环境生效

SSDs调优

在大部分的linux系统中，默认的SSD配置不是最优的，按照下面的步骤确保SSDs的最佳配置

确保SysFS 转动标志设置为false(0)

这样可以覆盖操作系统的任何检测，确保磁盘始终是被当做SSD

将从SSD存储中创建的任何块设备的转动标志都设置为false

将IO 调度器设置为 deadline 或者 noop:

设置块设备的readahead值为8KB

这个设置是告诉操作系统不要读取多余的字节，这样可以提高IO时间，而且可以冲掉那些不被用户请求的缓冲字节。

例如，如果SSD是/dev/sda,在/etc/rc.local

$ echo deadline > /sys/block/sda/queue/scheduler

OR…

echo noop > /sys/block/sda/queue/scheduler
touch /var/lock/subsys/local
echo 0 > /sys/class/block/sda/queue/rotational
echo 8 > /sys/class/block/sda/queue/read_ahead_kb

最佳效果–setra setting for RAID on SSD

SSDs(亚马逊EC2)上面的RAID 的readahead配置是8KB,和非RAID SSDs配置是一样的。

在NUMA 系统上禁止zone_reclaim_mode

Linux 内核在 zone_reclaim_mode 允许/禁入的设置不一致，这样可能会导致奇怪的性能问题

为了确保zone_reclaim_mode是禁止的

echo 0 > /proc/sys/vm/zone_reclaim_mode

[更多信息](http://docs.datastax.com/en/landing_page/doc/landing_page/cstarTroubleshooting/zoneReclaimMode.html\

用户资源限制

使用 ulimit -a 命令查看当前的限制。尽管使用这命令可以临时的设置限制，DataStax建议这些改变能够持久化。

确保下面的配置在/etc/security/limits.d/cassandra.conf文件中:

<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited

在RHEL 6.x版本中，确保/etc/security/limits.conf中下面这些设置

<cassandra_user> - memlock unlimited
<cassandra_user> - nofile 100000
<cassandra_user> - nproc 32768
<cassandra_user> - as unlimited

如果你以root用户允许Cassandra，一些Linux系统比如Ubuntu,需要为root而不是cassandra_user明确指定这些限制

root - memlock unlimited
root - nofile 100000
root - nproc 32768
root - as unlimited

对于RHEL 6.x-based 系统，也要在/etc/security/limits.d/90-nproc.conf中设置nproc 限制

cassandra_user - nproc 32768

对于大部分的安装，在/etc/sysctl.conf中添加下面行

vm.max_map_count = 1048575

对于Debian,Ubuntu操作系统，pam_limits.so 模块默认是不开启的，编辑/etc/pam.d/su 文件，去掉下面这行的注释

session required pam_limits.so
这个PAM配置文件的改变确保系统读取/etc/security/limits.d目录下面的文件。

确保上述改变生效，重启机器或者允许下面命令

sudo sysctl -p

为了确保这些限制能够应用到Cassandra进程，运行下面的命令，其中pid是当前运行的Cassandra进程的pid号

cat /proc/pid/limits

[更多信息](http://docs.datastax.com/en/landing_page/doc/landing_page/cstarTroubleshooting/insufficientResources.html\

禁止swap

不禁掉swap会严重降低性能。因为Cassandra有多个副本和透明的失败机制，对于一个副本，但内容很低的时候最好的是立马kill掉，而不是进入swap。这样能够允许请求能够立马被转发到其他副本上，而不是继续命中到这个副本，这个副本因为swapping，会导致高延迟。如果系统有很多的DRAM,swapping 仍然会显著降低性能，因为OS 换出了可执行的代码，这样更多的DRAM可以被caching 磁盘使用。

如果你坚持使用swap，可以设置vm.swappiness=1。这样允许内核swap out 绝对最小的被使用部分

sudo swapoff --all

为了确保改变持久化，将所有的swap文件从/etc/fstab中移除

[更多信息](http://docs.datastax.com/en/landing_page/doc/landing_page/cstarTroubleshooting/nodeFreeze.html\

检查Java Hugepages 设置

许多现代的Linux系统默认都开启了Transparent Hugepages。当Linux 使用透明大页时，内核会尝试将内存分配大的chunk(通常是2MB）,而不是4K。这样可以通过降低CPU需要跟踪的页的数量来提高性能。然而，一些应用仍然按照4K每页分配内存，当Linux尝试碎片整理2MB页时，这样会造成可观察到的性能问题。

更多信息查看Cassandra Java大页和RedHat和[RedHat) bug报告](http://docs.datastax.com/en/landing_page/doc/landing_page/cstarTroubleshooting/zoneReclaimMode.html\

为了解决这个问题，将hugepages的defrag 禁掉

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
更过信息，包括一个临时的修复，请看[没有Cassandra进程，CPU使用很高](http://docs.datastax.com/en/landing_page/doc/landing_page/cstarTroubleshooting/highCPU.html\

设置堆大小和DataStax企业版的可选垃圾回收期

DataStax Enterprise version	Garbage collector
5.0 (Java 8 required)	G1
4.8 using Java 8	G1
4.8 using Java 7	Concurrent-Mark-Sweep (CMS)
4.7 (Java 7 required)	CMS

注: DataStax不建议在Java7中使用G1因为G1类卸载有问题，在Java7中，PermGen(内存永久保存区域)会不定期的被填满直到一次full GC。

堆大小一般是系统的1/4到1/2大小。不要将所有的内存都分配给堆，因为一般堆外缓存和文件系统缓存也需要使用。

为你环境中设置最佳的堆内存大小最简单的方法是:

将单个节点的cassandra-env.sh文件中的MAX__HEAP__SIZE
设置为一个高的任意值

看一下这个节点的堆使用

开启GC logging，通过logs看下趋势

在OpsCenter中使用List view

使用这个值作为集群中的heap siez

注:这种方法会降低测试节点的性能，但是总的来说，不会显著降低集群性能。

调节堆大小当使用CMS垃圾回收期的时候

当调节CMS,有很多细微的区别。这个需要时间，专家和重复的测试来获取最好的结果。http://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsTuneJVM.html

Apply optimum blockdev –setra settings for RAID on spinning disks

通常，readahead 推荐值为128

检查来确保setra没有被设置

sudo blockdev --report /dev/spinning_disketra

设置值

sudo blockdev --setra 128 /dev/spinning_disk

欢迎关注我的个人公众号，第一时间了解NoSQL技术