列族系列 · 第 07 篇——调优实战:内存、压缩与监控

把列族集群的性能与稳定性调到最佳

目 录

一、导读

[二、JVM 与内存调优](#二、JVM 与内存调优)

[2.1 Cassandra 堆内存](#2.1 Cassandra 堆内存)

[2.2 HBase RegionServer 内存划分](#2.2 HBase RegionServer 内存划分)

[2.3 原则](#2.3 原则)

三、写入与压缩调优

[3.1 批量写入](#3.1 批量写入)

[3.2 压缩(Compaction)](#3.2 压缩(Compaction))

[3.3 合理利用 TTL](#3.3 合理利用 TTL)

四、压测与监控体系

[4.1 压测:cassandra-stress](#4.1 压测:cassandra-stress)

[4.2 nodetool 巡检](#4.2 nodetool 巡检)

[4.3 全链路监控](#4.3 全链路监控)

五、系统层调优

六、本篇小结

一、导读

前几讲解决了「能跑、能高可用、能避坑」,本讲聚焦「跑得快、看得清、扛得住」:从 JVM 与内存、写入与压缩、监控体系到系统层调优,把调优方法论落到可执行的命令与指标上。

二、JVM 与内存调优

2.1 Cassandra 堆内存

Cassandra 性能高度依赖 JVM 配置,堆内存默认按 min(1/2 内存, 上限) 计算,生产建议显式设置并配合 G1 GC(G1 不需要单独设新生代):

|---------------------------------------|
| # conf/cassandra-env.sh |
| MAX_HEAP_SIZE="16G" |
| HEAP_NEWSIZE="4G" # 用 CMS 时设置;G1 无需设置 |
| # JVM 关键参数 |
| -XX:+AlwaysPreTouch |
| -XX:+HeapDumpOnOutOfMemoryError |
| -XX:+UseTLAB |

2.2 HBase RegionServer 内存划分

HBase 把 RegionServer 堆内内存划分为写缓存(MemStore)与读缓存(BlockCache),分配不合理会互相挤占:

|------------------------------------------------|
| # hbase-site.xml:MemStore 与 BlockCache 各占约 40% |
| hbase.regionserver.global.memstore.size=0.4 |
| hbase.regionserver.blockcache.size=0.4 |

2.3 原则

  • 内存过小触发频繁 GC;过大堆增加 Full GC 停顿。
  • 按读写比例调整 MemStore 与 BlockCache:写多调大 MemStore,读多调大 BlockCache。

三、写入与压缩调优

3.1 批量写入

用批量写(Batch)或并发写入提升吞吐,配合合理的一致性级别(ONE / QUORUM / ALL)在可用性与一致性间取舍:

|--------------------------------------------------------------|
| // CQL 批量写入 |
| BEGIN BATCH |
| INSERT INTO logs (ts, level, msg) VALUES (..., "info", "a"); |
| INSERT INTO logs (ts, level, msg) VALUES (..., "warn", "b"); |
| APPLY BATCH; |

3.2 压缩(Compaction)

压缩合并 SSTable、清理墓碑与重复数据、回收磁盘,是保持读性能的关键。运行节点数据多 / 墓碑多时,及时触发或规划压缩:

|-----------------------------------------------|
| bin/nodetool compact keyspace table # 触发指定表压缩 |
| bin/nodetool flush # 把内存表刷到 SSTable |

3.3 合理利用 TTL

对有时效的数据(日志、时序)设 TTL,让数据到期自动清理,避免无限增长占用磁盘与墓碑堆积。

四、压测与监控体系

4.1 压测:cassandra-stress

Cassandra 自带 cassandra-stress 压力测试工具,可模拟指定模型的读写压测:

|---------------------------------------------------|
| cassandra-stress write n=1000000 -rate threads=50 |
| # 在独立客户端运行,观察吞吐与延迟 |

4.2 nodetool 巡检

|------------------|---------------|
| 命令 | 作用 |
| nodetool status | 节点状态(UN / DN) |
| nodetool info | 内存、负载、分区数 |
| nodetool tpstats | 线程池与队列,看堆积 |
| nodetool repair | 反熵修复副本 |
| nodetool cleanup | 清理不再属于本节点的数据 |

4.3 全链路监控

生产推荐 Prometheus + Grafana:Cassandra 通过 JMX Agent(Datastax MCAC,默认抓取端口 9103)暴露指标,Prometheus 抓取、Grafana 绘制大盘并告警;HBase 可用 Ambari / Grafana 大盘与 hbase shell 查看 Region 分布与负载。

  • 节点状态:node up / down、复制延迟。
  • 负载:读 / 写吞吐、线程池队列、GC 停顿。
  • 存储:数据量、磁盘占用、压缩进度。

五、系统层调优

|------------|-----------------------------|--------------------------|
| 方向 | 手段 | 说明 |
| 内存 | vm.swappiness=0 | 避免频繁换页影响性能 |
| 句柄 | ulimit -n 65535 | 防止文件句柄不足 |
| 存储 | SSD + 合理 IO 调度器 | SSD 用 noop,机械盘用 deadline |
| 网络 | 调大 TCP 缓冲 | 提升节点间复制吞吐 |
| 写入 | 批量 / 并发写 | 减少往返,提升吞吐 |
| Region | HBase 预分区 + 合理 max.filesize | 避免单 Region 过大 |

六、本篇小结

调优是一套「先量化 → 再优化 → 后验证」的方法论:JVM 与内存看堆配置与缓存划分,写入靠批量与压缩,监控靠 nodetool / cassandra-stress / Prometheus 组合。调优目标是让列族集群稳定、可控、可观测。

相关推荐
IT大白鼠11 天前
图数据库系列 · 第 08 篇——面试收官:高频题与全景总结
数据库·面试·职场和发展·nosql·图数据库
IT大白鼠12 天前
图数据库系列 · 第 06 篇——避坑汇总:经典生产问题
数据库·nosql·图库数据库
IT大白鼠13 天前
图数据库系列 · 第 02 篇——架构拆解:原生图存储到因果集群
数据库·架构·nosql
IT大白鼠15 天前
搜索系列 · 第 08 篇——面试收官:高频题与全景总结
elasticsearch·面试·nosql
IT大白鼠15 天前
搜索系列 · 第 06 篇——避坑汇总:经典生产问题
elasticsearch·nosql
IT大白鼠16 天前
搜索系列 · 第 07 篇——调优实战:写入、查询与监控
elasticsearch·nosql
IT大白鼠17 天前
搜索系列 · 第 04 篇——部署实操:内网集群落地
运维·elasticsearch·nosql
IT大白鼠19 天前
搜索系列 · 第 01 篇——认知入门:Elasticsearch 是什么
elasticsearch·nosql
此时不提桶,更待何时20 天前
05-03-B-ClickHouse与OLAP面试与生产事故实战
clickhouse·面试·nosql