Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie How do we manage more than one thousand of Pegasus clusters - backend part
Ähnlich wie How do we manage more than one thousand of Pegasus clusters - backend part (20)
Mehr von acelyc1112009
Mehr von acelyc1112009 (11)
How do we manage more than one thousand of Pegasus clusters - backend part
- 4. www.sensorsdata.cn 业务特点 • 私有部署的集群⾮常多 • 运维难度⼤ • 部分集群的规模⼩，机器配置低 • 单机部署 • 内存⼩，磁盘性能不⾼ • 每台机器部署的服务多 • 需要限制内存 • 存在⽐较极端的故障 • 机房着⽕、断电
- 5. www.sensorsdata.cn 版本演进 2020.02：引⼊1.12.2，并开始⼆次开发 2020.05：引⼊1.12.3，并cherry-pick已有commits 2020.05：内部版本0.1.0 主要解决单机部署、内存控制等上线前必须解决的问题 2020.09：内部版本0.3.0 持续改善内存使⽤，Kerberos认证，C++ Client的优化等 2020.11： 内部版本0.4.0 部署⽬录的标准化 2021.05：内部版本0.5.0 冷备，指标采集，Meta Server内存泄露，Java Client的优化等 2021.08：内部版本0.6.0 新的⽇志策略，aio增加重试机制
- 6. www.sensorsdata.cn 重要特性 ⾮功能性改进 • 优化batchGet2接⼝ • 控制Pegasus对内存的使⽤ 功能性改进 • ⽀持Pegasus的单节点部署 • 冷备 • ZooKeeper Client⽀持Kerberos认证 • ⽀持修改表的副本个数 • 新的⽇志策略 • 版本⼀致性 • BugFix
- 7. 功能性改进
- 8. www.sensorsdata.cn ⽀持Pegasus的单节点部署 • 不少客户的集群是单节点的 • PacificA协议⽀持单副本 • Pegasus Shell放开 • 冷备
- 9. www.sensorsdata.cn 冷备 • 需求（只有单节点部署时才需要冷备） • 需要⽀持备份到指定的本地路径 • ⽀持即时备份，即⽤户执⾏命令后⻢上开始备份，且只备份⼀次 • Pegasus 1.12.3的冷备 • 只⽀持备份到配置⽂件中的路径 • 只⽀持类似crontab似的周期性备份策略，⽆法即时备份 • 如果备份周期⼩于1⼩时，会⼀次接⼀次地备份
- 14. www.sensorsdata.cn ZooKeeper Client⽀持Kerberos认证（4） • C和Java Client中的State不完全⼀样 • Meta Server退出时core dump • 现象：core在 VMThread上（析构C++部分的对象时） • 原因：JVM内部线程启动时不可能到rDSN注册（因此tls_dsn.magic也没有被设置） • ⽅案：让JVM不处理kill信号，析构操作还是在C++做
- 15. www.sensorsdata.cn ⽀持修改表的副本个数 • 初期单节点或双节点部署，后期需要扩节点 • Pegasus Shell端增加指令，向Meta Server发出RPC请求 • get_replica_count • set_replica_count • Meta Server处理RPC请求 • 收到请求后需要检查合法性（⽬前只增不减） • 修改元数据中的max_replica_count • Meta Server线程定期检测，修补副本数量（达到max_replica_count） • 线程检查周期由lb_interval_ms来配置，⼀般设置为10s • 从元数据完成修改到副本修补完成，中间经过的时间最⻓为10s
- 17. www.sensorsdata.cn 新的⽇志策略 • log_dir可配：按照部署规范，需要有独⽴的⽇志⽬录 • ⽇志⽂件命名：带有⻆⾊名称（meta/replica）和创建时间戳（结束时间戳看修改时间即可） • max_log_file_bytes：单个⽇志⽂件最⼤字节数 • 复⽤max_number_of_log_files_on_disk • 按照⽂件前缀和修改时间淘汰旧⽇志⽂件（借鉴Kudu策略） • ⼀个⼩问题：时间戳1970问题，https://github.com/XiaoMi/rdsn/pull/517
- 19. www.sensorsdata.cn 服务端版本⼀致性 • Meta Server/Replica Server的版本是否⼀致 • 很难强制要求（⽐如在线升级） • 通过版本监控来保障
- 20. www.sensorsdata.cn 服务端/客户端版本兼容性 • 服务端/客户端版本很难做到完全匹配 • 保证服务端的向后兼容性：新版服务端兼容旧版客户端 • 客户端先升级：新版客户端访问旧版服务端 • 客户端的新接⼝，需要判断服务端的版本 • 客户端openTable时，通过query_cfg_operator获取服务端版本 • 如果旧版服务端确实缺少新版客户端所需的接⼝，可以使⽤其他替代⽅案
- 21. www.sensorsdata.cn BugFix（1） • Meta Server内存泄露 • 3节点部署时，Primary Meta Server每天泄露⼤约60MB左右 • Replica Server通过UDP向Meta Server发ping包时没有释放内存 • https://github.com/XiaoMi/rdsn/pull/477 • Prometheus采集指标时，发⽣core dump • 处理带下划线的表名时存在bug
- 22. www.sensorsdata.cn BugFix（2） • IO频繁打满，Replica Server会频繁core掉 • aio队列资源不⾜时，io_submmit返回 -EAGAIN（-11） • 如果aio写⼊的是slog，就会core dump • ⽅案：aio增加重试机制，休息20微秒后重试，最多重试200次 • copy_data后发现新⽬的表和源表数据量不⼀致 • copy_data不⽀持保持TTL，源表部分数据因过期被清理 • https://github.com/apache/incubator-pegasus/pull/752
- 23. www.sensorsdata.cn BugFix（3） • batchMultiGet2卡死 • 硬件配置低导致的极端情况 • ReplicaSession的超时任务，被调度到了初始化时绑定的不同线程⽽导致死锁 • ⽅案：每个ReplicaSession初始化的时候，超时线程和io线程指定为同⼀个 • Primary Replica转移后scanner⽆异常退出（⽆任何错误提示） • 原因：服务端将full scan的断点误以为是按hashKey扫描 • ⽅案1：客户端抛出异常，⾄少告诉⽤户需要重新扫描 • ⽅案2：rocksdb_filter_type从prefix改为common • ⽅案3："治本"，即服务端正确处理full scan的断点
- 24. ⾮功能性改进
- 27. www.sensorsdata.cn 优化batchGet2接⼝（3） • 引⼊⼀个新接⼝：batchGet3 • 新增⼀个RPC接⼝：RPC_RRDB_RRDB_BATCH_GET • 如果服务端版本低，不⽀持新接⼝，则改为调⽤batchGet2（客户端版本兼容性）
- 30. www.sensorsdata.cn 控制RocksDB对内存的使⽤ •Block Cache⼤⼩可控 •控制MemTables和Index & Filter Blocks对内存的使⽤
- 31. www.sensorsdata.cn 控制MemTables对内存的使⽤ •将MemTables纳⼊Block Cache：引⼊Write Buffer Manager •https://github.com/apache/incubator-pegasus/pull/646 •rocksdb_block_cache_capacity •rocksdb_total_size_across_write_buffer
- 32. www.sensorsdata.cn Bulk Load模式下遇到的问题 •⼤量碎⽂件（多达数万个sst⽂件，⼩的只有1KB） •Replica Server因为"Too many open files"挂掉
- 33. www.sensorsdata.cn MemTables Flush规则 • WAL⼤⼩超过max_total_wal_size（Pegasus未使⽤WAL） • 单个MemTable超过write_buffer_size • Mutable MemTables总量过⼤（Flush最⼤的⼀个MemTable） • 超过rocksdb_total_size_across_write_buffer的7/8 • MemTables总量过⼤（Flush最⼤的⼀个MemTable） • 超过rocksdb_total_size_across_write_buffer • 且Mutable MemTables总量超过rocksdb_total_size_across_write_buffer的1/2
- 34. www.sensorsdata.cn 存在问题的参数 & 测试（1） • rocksdb_total_size_across_write_buffer：480MB • write_buffer_size • 普通模式：20MB • Bulk Load模式：80MB • max_write_buffer_number • 普通模式：2 • Bulk Load模式：6 • max_open_files：-1（进程级的限制⼀般是65536） • 单机活跃写⼊的分⽚数：32
- 35. www.sensorsdata.cn 存在问题的参数 & 测试（2） • 13GB数据写到了65063个sst⽂件中，每个sst⽂件约211KB • 每秒约Flush46次 • 同时伴有⼤量Write Stalls（约62次/秒）
- 36. www.sensorsdata.cn 参数设置的改进 • rocksdb_total_size_across_write_buffer不能过⼩，分⽚数越多应当设置得越⼤ • 使⽤经验公式⾃动计算，使之尽可能的⼤ • Bulk Load模式下参数不宜扩张得过⼤ • 限制max_open_files • 同样使⽤经验公式预估
- 37. www.sensorsdata.cn 改进后的参数 & 测试（1） • rocksdb_total_size_across_write_buffer：480MB → 6GB • write_buffer_size • Bulk Load模式：80MB → 40MB • max_write_buffer_number • Bulk Load模式：6 → 4 • max_open_files：-1 → 256（进程级的限制⼀般是65536） • 单机活跃写⼊的分⽚数：32
- 38. www.sensorsdata.cn 改进后的参数 & 测试（2） • 52GB数据写到了1961个sst⽂件中，每个sst⽂件约27MB • ⼤约每2秒Flush 1次 • 没有发⽣过Write Stalls
- 42. www.sensorsdata.cn 控制Index & Filter Blocks对内存的使⽤（1） • 将Index & Filter Blocks纳⼊Block Cache：cache_index_and_filter_blocks=true • https://github.com/apache/incubator-pegasus/pull/646 • RocksDB官⽅建议版本 ≥ 5.15 • Pegasus 1.12.3使⽤的RocksDB版本=5.9.2 • 运⾏⼀段时间后，在线上出现core dump，定位与此有关 • Pegasus最新版本使⽤的RocksDB版本=6.6.4 • 不控制Index & Filter Blocks的内存 • 每个Replica Server的Index & Filter Blocks的内存使⽤ ∝ 活跃分⽚数 * max_open_files
- 43. www.sensorsdata.cn 控制Index & Filter Blocks对内存的使⽤（2） • 以3副本部署的3张表（分⽚数为8、64、256）的使⽤情况
- 44. www.sensorsdata.cn 控制rDSN对内存的使⽤ • log_private_block_bytes：plog的块⼤⼩可配 • 对内存profile时，发现log file buffer占⽤⼤量内存 • Pegasus原⼤⼩为1MB • ⼀般设置为256KB • 去掉TLS Memory Allocator • 社区也去掉了：https://github.com/XiaoMi/rdsn/pull/749
- 45. www.sensorsdata.cn 使⽤jemalloc • 优秀的性能表现，redis, clickhouse, rocksdb等都⽀持jemalloc • 丰富的操作指令 • ⼿动GC，⽐如tcache的flush和arena的decay-based purge • 查看当前的配置参数、状态以及各项指标 • 修改部分配置参数 • 控制内存profile • 主分⽀已⽀持⽕焰图分析
- 46. www.sensorsdata.cn 加快jemalloc的内存回收速度 • dirty_decay_ms调⼩ • muzzy_decay_ms调⼩ • background_thread • 使⽤专⻔的线程来GC • 改善⽤户线程的尾延迟 • 改善内存分配不频繁时，内存的延迟归还
- 47. www.sensorsdata.cn 加快tcmalloc的内存回收速度 • tcmalloc_release_rate调⼤ • mem_release_enabled=true • mem_release_check_interval_ms调⼩ • mem_release_max_reserved_mem_percentage调⼩ • tcmalloc.aggressive_memory_decommit=1 • core dump，暂未定位
- 48. www.sensorsdata.cn jemalloc/tcmalloc性能测试 • RocksDB的所有内存（包括Memtable和Index & filter blocks的内存）都由Block Cache管 理 • Block Cache：12GB（其中给MemTables最多8GB） • 写⼊测试：10个sort key（单hash key），单条数据320B，单客户端48线程single put 8000万+条数据，总⼤⼩约29GB • 读取测试：10个sort key（单hash key），单条数据320B，单客户端96线程single get 8000万+条数据
- 49. www.sensorsdata.cn jemalloc的配置 • jemalloc配置1（默认配置） • background_thread: false • dirty_decay_ms: 10000 • muzzy_decay_ms: 0 • jemalloc配置2（使⽤bg thread回收） • background_thread: true • dirty_decay_ms: 10000 • muzzy_decay_ms: 0
- 50. www.sensorsdata.cn tcmalloc的配置 • tcmalloc配置1（加速内存回收） • tcmalloc_release_rate: 10.0 • mem_release_enabled: true • mem_release_check_interval_ms: 10000 • mem_release_max_reserved_mem_percentage: 0 • tcmalloc配置2（不加速内存回收） • tcmalloc_release_rate: 1.0 • mem_release_enabled: false
- 53. www.sensorsdata.cn jemalloc vs. tcmalloc（物理内存） • put + get
- 54. www.sensorsdata.cn jemalloc vs. tcmalloc（物理内存） • scan + put
- 55. www.sensorsdata.cn 控制Pegasus对内存使⽤的结论 • 将Memtable和Index & filter blocks的内存都纳⼊到Block Cache管理下，内存基本可控 • 可以加快tcmalloc/jemalloc对内存的回收（归还给OS），当然代价是性能的降低以及 CPU使⽤率的提⾼ • 使⽤jemalloc，可以在加快内存回收的同时，可能会带来10%左右的性能提升
- 56. www.sensorsdata.cn 未来展望 • 引⼊2.0.0/2.2.0，合⼊已有commits（正在进⾏时） • 整理已有改进点，逐步回馈社区 • 在性能、架构层⾯，深度参与社区建设