想问下大家,怎么优化cassandra写入性能
本问题来自阿里云开发者社区的【11大垂直技术领域开发者社群】。 https://developer.aliyun.com/article/706511 点击链接欢迎加入感兴趣的技术领域群
1.1. 添加节点到集群中 1.1.1. 添加非seed单节点 1.在新节点上安装Cassandra,但不要启动
2.修改cassandra.yaml文件:
cluster_name – 新节点加入集群名称
listen_address/rpc_address – 新节点IP
seed_provider – 集群seeds列表
3.启动新节点Cassandra
4.使用nodetool status验证节点是否启动完毕:状态为UN
5.运行nodetool cleanup(或OpsCenter)在集群节点上:移除脏数据(建议在低峰执行)
1.2. 添加非seed单节点案例: 已经存在Cassandra集群:
cluster_name = ‘Test Cluster’ xxx_address = 192.168.92.148 seed_provider = 192.168.92.148 wKiom1cppL3B4g3eAAAi2QSK7_A312.png
添加新节点192.168.92.149:
1.安装Cassandra
参考《Cassandra教程》
wKioL1cppdWBh1E0AAAqS7BJjj8685.png
2.修改cassandra.yaml
cluster_name:
wKiom1cppRyQgL1OAAAJH-7ICJM624.png
seed_provider
wKiom1cppTGRTNDYAAAFzgKBsxI614.png
listen_address:
wKiom1cppUKSINlaAAARH9Y2M4k195.png
rpc_address:
wKioL1cppiuSXaHTAAAwhOPL0cU905.png
3.启动Cassandra
wKiom1cppWrQEh_ZAAAHfko1RTA314.png
4.验证新节点192.168.92.149是否启动完毕
wKioL1cpplGjOAObAAAwiZhPyqs058.png
5.删除192.168.92.148上的脏数据
wKioL1cppnDRvX69AAAJU_XNzH8484.png
或者
wKiom1cppa6zkjcMAAEQ_CWmkCk571.png
1.1.3. 添加非seed多个节点 步骤参考1.1.1,唯一不同点步骤3,启动Cassandra需要同时启动,避免数据多次迁移。
wKiom1cppcXgG_yVAAATIyr-29o972.png
wKioL1cppqqx_7fCAAAJIH1hzKU774.png
1.1.4. 添加seed节点 由于seed需要修改cassandra.yaml文件,所以需要重启所有节点
1.先将seed作为非seed节点安装启动,完成数据迁移操作
步骤参考1.1.1
2.修改所有节点的cassandra.yaml文件,添加seed
3.重启所有节点
1.2. 替换一个dead节点 由于一些硬盘损坏等原因,需要执行替换dead节点
1.确保dead节点状态为DN,使用nodetool status:
wKioL1cppsGzufqHAADpeBCNoHM141.png
注意Address需要在下面步骤用到
2.修改新节点cassandra.yaml文件:参考1.1.1
3.启动新节点,使用replace_address选项:
$ sudo bin/cassandra -Dcassandra.replace_address=address_of_dead_node
删除节点:参考1.4(建议72小时之后操作,确保gossip删除掉了老节点)
1.3. 替换一个running节点 由于升级新硬件等原因,需要使用新节点替换
添加新节点到集群中,参考步骤1.1.1
确保替换running节点状态为UN,使用nodetoolstatus:
wKiom1cpphiDrWPlAAA1B_i8fJk015.png
4.删除running节点,参考1.4
1.4. 删除节点 1.4.1. 删除UN状态节点 运行nodetooldecommission删除UN节点
wKioL1cppv_j7ZivAAAH3iGF5ks849.png
或者:
wKiom1cppjmTCRaaAAE-5vBVfQI416.png
1.4.2. 删除DN状态节点 运行nodetoolremovenode命令
wKiom1cppkrQRrCpAAAItR3PQ6g995.png
注意 如果以上步骤无法删除,可能是由于节点存在脏数据,请运行nodetool assassinate,强制删除
1.5. 修改ReplicationFactor 1.5.1. ReplicationFactor减少 运行nodetool cleanup,删除脏数据
或者:
wKioL1cpp0Situ8oAAEQ_GnCSZU529.png
1.5.2. ReplicationFactor增加 运行nodetool repair,迁移数据
或者:
wKioL1cpp2bw3WA-AAEwA_ieu7E092.png
2.1.2. 安装NTP (略) 2.1.3. Commit log和data目录在独立硬盘 wKioL1cpp6PyIWveAAAvC7KYWAI807.png
wKiom1cppt2gKIqAAAAhpSf2WaI010.png
2.1.4. 硬盘类型 硬盘类型
SSD(微秒)
SAS(毫秒)
SATA(秒)
延迟
100~120
8~40
15
2.1.5. Linux优化 1.文件操作符
/etc/security/limits.conf
– as unlimited /etc/security/limits.d/90-nproc.conf
2.Swap
/etc/sysctl.conf
vm.max_map_count = 131072 #最大限度使用物理内存 vm.swappiness = 0 使之生效
sysctl -p
永久关闭swap
swapoff –a /etc/fstab:注释掉swap
wKiom1cppyKA6sJrAAAzLjQpz9o105.png
3.NUMA
echo 0 > /proc/sys/vm/zone_reclaim_mode 4.文件系统类型
EXT4 2.1.6. 磁盘阵列RAID优化 使用高效性能RAID0 sudo blockdev --setra 128 /dev/ 2.1.7. cassandra-evn.sh配置建议 JVM配置在cassandra-evn.sh中
MAX_HEAP_SIZE
生产环境建议8G
wKiom1cpp1GwzHp0AACEXhULvLs062.png
HEAP_NEWSIZE
一般设置为MAX_HEAP_SIZE的1/4
添加cassandra压缩线程级别,减少其资源占用
-Dcassandra.compaction.priority=1 打开JVM压缩,减少内存占用,适用于64位JVM
-XX:+UseCompressedOops wKiom1cpp4KxPqHZAABZY1Ttqvc623.png
2.1.8. cassandra.yaml配置建议 concurrent_reads:16 * number_of_drives concurrent_counter_writes:16 * number_of_drives concurrent_writes:8 * number_of_cores #使用Memory Mapped File IO,性能超过Standard IO,64位 disk_access_mode: mmap #write性能提升5% memtable_allocation_type: offheap_objects
2.2. 安装后监控——定位——优化 2.2.1. nodetool tpstats 线程池使用统计,看是否有积压线程
wKiom1cpp6nTmTMAAABUQAaTpeo434.png
或者使用OpsCenter
wKioL1cpqJCz6-lvAAA-lJo_EU0610.png
wKioL1cpqKWDALVwAAAmDlC-FsU281.png
2.2.2. Read Requests/Write Requests 结合CPU和Disk使用监控,来判断系统每秒可以支持的操作数量
wKiom1cpp_DQtQE8AABRdkfpp3w679.png
wKioL1cpqMbC1TDwAAA-wD4PguY526.png
2.2.3. total Memtable size 与内存使用比较,确保大的memtable不会导致内存竞争,大的memtable有利于写多读少情况
wKioL1cpqOKCHLMgAAAk_7lutxM979.png
2.2.4. SSTable count 确保sstablecount比较低(个位数),每次读操作会检查所有sstable,太多的sstable影响read性能
wKioL1cpqPaDs7LMAAAncf0Pt6g071.png
2.2.5. total bytes compacted 确保不会发生频繁操作
wKioL1cpqQiwB3gFAAA_LtjQpYs529.png
2.2.6. read latency/write latency 确保延迟在可接受范围之内,不包含网络延迟
wKioL1cpqSPCdxQWAAAnjLcjGm4907.png
wKiom1cpqE6TT1WAAAAnQwgF-7o431.png
出问题后定位
writelatency写响应平均时长(以毫秒为单位)。依赖于consistency level和replication factor,也包含了写replicas的网络延迟
read latency受到硬盘,网络和应用程序读的方式等影响。比如,使用二级索引,读请求数据大小,client需要的consistencylevel都将影响readlatency。I/O的争用也会增加read latency。当SSTables有很多碎片,compaction跟不上写负载则读也会变慢。
2.2.7. partition size 监控表分区大小,确保max不超过100M
wKiom1cpqG2zVpQaAAAl8484Yio823.png
2.2.8. cell count 监控表cell count,确保不超过20亿
wKioL1cpqVeCp-SOAAAkXqDKpLU110.png
2.2.9. write Read active 读写请求数
wKioL1cpqWnjxZXkAAAqG5kF0pA383.png
2.2.10. OS系统监控 监控CPU、Memory、Disk的使用率、饱和度。
wKioL1cpqYzy_ASAAAAhDAPQE1U728.png
wKiom1cpqLjjAFHLAAAlkQpGBhY571.png
wKioL1cpqY3QeNSrAAAhZsQei-k449.png 转载于:https://blog.51cto.com/eric100/1770036
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。