1-7-曹志佳-IoTDB 技术实践：IoTDB 系统调优从入门到精通.pdf

《1-7-曹志佳-IoTDB 技术实践：IoTDB 系统调优从入门到精通.pdf》由会员分享，可在线阅读，更多相关《1-7-曹志佳-IoTDB 技术实践：IoTDB 系统调优从入门到精通.pdf（48页珍藏版）》请在三个皮匠报告上搜索。

1、主讲人：曹志佳目录数据库系统的用户服务和架构演进挑战效率！效率！效率！IoTDB 可观测性发展概览Logging&Metrics&TracingIoTDB 监控模块负载视角&资源视角&引擎视角IoTDB 监控面板调优的“透视镜”典型案例分享性能调优&问题排查01效率！效率！效率用户服务和架构演进挑战用户服务挑战针对性调优可扩展调优容易导致调优的单点瓶颈形成可复制的调优方法论快速找到瓶颈点木板效应瓶颈可能出现在很多模块硬件环境 业务负载默认参数不总是最优架构演进挑战进一步演进性能确保 ROI 最大海量优化思路量化排列优先级确定典型业务场景典型场景典型特征工程问题学术问题调优不是“抱佛脚”，需要“

2、粮草先行”根据业务场景，提前规划集群节点数、存储类型、网络带宽等资源规划环境配置各模块内存配比、SDD与HDD磁盘的分配内存、磁盘调整包括 JVM 参数（如堆内存大小、GC 算法）、操作系统内核参数等02IoTDB 可观测性发展概览Logging&Metrics&Tracing可观测性Logging：离散事件Metrics：统计聚合Tracing：调用轨迹LoggingLogback 框架拆分不同级别和模块的日志记录离散事件Metrics算法库：Micrometer&DropWizard存储：Prometheus/IoTDB可视化：GrafanaTracing追踪：OpenTelemetry存

3、储：ElasticSearch可视化：GrafanaShow Region 请求调用链路03IoTDB 监控模块负载视角&资源视角&拓展视角&引擎视角建设思路 负载分析 资源分析自顶向下的负载视角客户端写入 IoTDB 流程拆解IoTDB 的写入请求延迟拆解自底向上的资源视角磁盘比 iostat 命令更丰富网络比 sar 命令更丰富CPUJVM区分操作系统和进程区分进程内部不同模块和不同线程池统计进程内部线程池的关键参数堆内堆外内存大小观测不同状态的线程个数观测GC 情况观测性能演进 版本：1.0.0-2.0.0 监控指标个数：134-1500+监控模块 CPU 开销：11.34%-5.81%

4、对读写性能影响：G1 GC 参数调优：延缓并发标记阈值提升 MixedGC 吞吐控制单次 GC 耗时软上限调优结果：写入吞吐稳定，不再发生 Full GC写入性能提升约 50%案例 2：某车联网场景-写入性能尖刺调优案例 3：某测试场景-磁盘瓶颈形成木桶效应我们可以量化算出升级硬件带来的潜在性能收益用以选择收益最高的硬件升级方案不知道如何升级硬件收益最高怎么办？案例 3：某测试场景-磁盘瓶颈形成木桶效应测试架构：1C1D 单节点集群（高配机器）2 个客户端机器压测该单节点集群性能测试问题：写入吞吐仅为 1.2 GB/s案例 3：某测试场景-磁盘瓶颈形成木桶效应CPU 和网络并未到瓶颈磁盘到达了

5、瓶颈，限制了整体吞吐需升级磁盘案例 3：某测试场景-磁盘瓶颈形成木桶效应理想情况实际情况案例 3：某测试场景-磁盘瓶颈形成木桶效应磁盘和网络并未到瓶颈写入吞吐从 1.2GB/s 提升到 2.8GB/sCPU 成为了新的瓶颈案例 4：某周测场景-写入性能波动变大IoTDB 监控模块内置了操作系统，进程，线程池和模块 CPU 利用率监控我们可以根据它们的细微波动给出调优建议服务器 CPU 利用率出现波动不知道如何排查怎么办？案例 4：某周测场景-写入性能波动变大现象描述：发现 1.2.0 rc5 写入吞吐相比之前 6.22 commit fea4cef 的波动更大案例 4：某周测场景-写入性能波动

6、变大排查操作系统及进程 CPU 监控：发现 1.2.0 rc5 CPU 利用率波动更大1.2.0 rc56.22 commit fea4cef案例 4：某周测场景-写入性能波动变大排查线程池 CPU 利用率监控：发现 1.2.0 rc5 中后台执行的合并线程池利用率波动更大1.2.0 rc56.22 commit fea4cef案例 4：某周测场景-写入性能波动变大排查存储引擎 TsFile 层级监控：发现 1.2.0 rc5 存储引擎合并速度更快，文件状态更健康1.2.0