kudu参数优化设置,让集群飞起来~

简介: kudu参数优化设置,让集群飞起来~

前言


根据数据体量,结合集群各节点的CPU、内存、磁盘的表现,合理优化设置kudu参数,让集群飞起来~

如有雷同,纯属借鉴~


正文


1.Kudu后台对数据进行维护操作,如写入数据时的并发线程数,一般设置为4,官网建议的是数据目录的3倍


  Kudu Tablet Server Maintenance Threads 这个参数决定了Kudu后台对数据进行维护操作,如写入数据时的并发线程数。并发数越大,吞吐量越高,但对集群计算能力的要求也越高。默认值为1,表示Kudu会采用单线程操作;对于需要大量数据进行快速写入/删除的集群,可以设置更大的值。该值可以设置跟计算节点的数据磁盘数量和CPU核数有关,一般来说,建议设置为4以获取比较均衡的性能,最大不超过8。

   参数:maintenance_manager_num_threads


2.分配给Kudu Tablet Server块缓存的最大内存量,建议是2-4G


   Kudu Tablet Server Block Cache Capacity Tablet的Block buffer cache,根据集群内存配置和数据量规模设置。一般建议至少2GB~4GB。

   参数:block_cache_capacity_mb


3.Tablet Server能使用的最大内存量,有多大,设置多大。


   tablet Server在批量写入数据时并非实时写入磁盘,而是先Cache在内存中, 在flush到磁盘。这个值设置过小时,会造成Kudu数据写入性能显著下降。

   对于写入性能要求比较高的集群,建议设置更大的值(一般是机器内存的百分之80) Kudu Tablet Server Hard Memory Limit Kudu的Tablet Server能使用的最大内存。

   参数:memory_limit_hard_bytes


4.参数决定了Kudu能够同时打开的操作系统文件数。不设置则使用系统的ulimits值,设置后会覆盖系统的设置。


   需要根据集群的规模及并发处理能力,非常谨慎的设置这个值。

   参数:Maximum Process File Descriptors


5.参数设置了每个Tablet的默认复制因子,默认值为3,表示每个表的数据会在Kudu中存储3份副本。


   我们可以根据需要修改这个全局默认值,也可以在建表语句中通过’kudu.num_tablet_replicas’属性来设置每个表的副本数,

   参数:kudu.num_tablet_replicas=1


6.tserver宕掉后,5分钟后没有恢复的情况下,该机器上的tablet会移动到其他机器


   参数:--follower_unavailable_considered_failed_sec=300


7.超过参数时间的历史数据会被清理,如果是base数据不会被清理。而真实运行时数据大小持续累加,没有被清理。


   参数:--tablet_history_max_age_sec=900


8.hash分区数量 * range分区数量不能超过60个(1.7.0版本之后没限制了)


9.设置block的管理器为文件管理器(默认是日志服务器)


   解释:并非所有文件系统格式都需要设置该选项。ext4、xfs格式支持hole punching(打孔),所以不需要设置block_manager=file,但是ext3 格式需要。可以通过df -Th命令来查看文件系统的格式。

   参数:--block_manager=file


10.设置ntp服务器的时间误差不超过20s(默认是10s)


   参数:max_clock_sync_error_usec=20000000


11.设置rpc的连接时长(默认是3s,建议不要设置)


   参数:--rpc_negotiation_timeout_ms=300000


12.设置rpc一致性选择的连接时长(默认为1s,建议不要设置)


   参数:--consensus_rpc_timeout_ms=1000


13.记录kudu的crash的信息


   解释:

       Kudu在遇到崩溃时,使用Google Breakpad库来生成minidump。这些minidumps的大小通常只有几MB,即使禁用了核心转储生成,也会生成,

       生成minidumps只能在Linux上建立。

       minidump文件包含有关崩溃的进程的重要调试信息,包括加载的共享库及其版本,崩溃时运行的线程列表,处理器寄存器的状态和每个线程的堆栈内存副本,

       以及CPU和操作系统版本信息。

       Minitump可以通过电子邮件发送给Kudu开发人员或附加到JIRA,以帮助Kudu开发人员调试崩溃。为了使其有用,

       开发人员将需要知道Kudu的确切版本和发生崩溃的操作系统。请注意,虽然minidump不包含堆内存转储,但它确实包含堆栈内存,

       因此可以将应用程序数据显示在minidump中。如果机密或个人信息存储在群集上,请不要共享minidump文件。

   参数:

       --minidump_path=minidumps              

       --max_minidumps=9

       (默认是在设置的log目录下生成minidumps目录,里边包含最多9个以dmp结尾的文件,无法设置为空值,需要注意的是如果自定义minidump文件,

       在master不能启动的情况下,需要将该目录中的文件删除)


14.Stack WatchLog


   解释:每个Kudu服务器进程都有一个称为Stack Watchdog的后台线程,它监视服务器中的其他线程,以防它们被阻塞超过预期的时间段。

         这些跟踪可以指示操作系统问题或瓶颈存储。通过WARN日志信息的跟踪(Trace)可以用于诊断由于Kudu以下的系统(如磁盘控制器或文件系统)引起的根本原因延迟问题。


15.cdh设置多master


   参数:--master_addresses=cdh01:7051,cdh02:7051cdh03:7051


16.kudu出现启动速度特别慢


   解决办法:

       1、取消所有配置参数(除了资源、时间同步)

       2、升级版本到kudu1.6.0

       3、client必须停止(client不占用io的情况,3台机器,每台机器60G,127分区数量,启动速度3分钟)

       4、查看io使用情况 iostat -d -x -k 1 200


17.单hash分区最大是60


18.安装kudu过程中,会要求CPU支持ssc4.2指令集,但是我们的虚拟机cpu没有这个执行集,所以无法安装


19.设置client长连接过期时间


   参数:--authn_token_validity_seconds=12960000(150天)

   注意:设置到tserver的配置文件中


20.tserver和master的wal和data目录要分隔(或者是目录设置为lvm卷轴)


   原因:wal目录只能设置为1个

   参数:--fs_wal_dir_reserved_bytes

   解释:

       Number of bytes to reserve on the log directory filesystem for non-Kudu usage. The default,

       which is represented by -1, is that 1% of the disk space on each disk will be reserved.    

       Any other value specified represents the number of bytes reserved and must be greater than or equal to 0.

       Explicit percentages to reserve are not currently supported

       用于非kudu都使用的日志目录文件系统的字节数,默认情况下是-1,每个磁盘上的磁盘空间的1%将被保留,指定的任何其他值表示保留的字节数,必须大于或等于0。


21.设置用户权限,能移动tablet


   参数:--superuser_acl=*



【小编废话】


在日常开发中,还需要结合集群的实际情况,任务的差异性,结合任务日志,针对性的调整参数,两个原则:


原则1:当资源紧张时,重要任务优先(需结合调度时间优化)。


原则2:在保证原则1的前提下,提升整个集群的效率。当时效要求高时,尽量压缩总体运行时间;当稳定性要求更高时,错峰执行,负载均衡。



参数调优核心总结为两个字:平衡。


1、时效和稳定性的平衡;


2、资源的平衡,在某一时间点,集群的内存、io、cpu等负载均衡。

相关文章
|
3月前
|
资源调度 关系型数据库 MySQL
【Flink on YARN + CDC 3.0】神操作!看完这篇教程,你也能成为数据流处理高手!从零开始,一步步教会你在Flink on YARN模式下如何配置Debezium CDC 3.0,让你的数据库变更数据瞬间飞起来!
【8月更文挑战第15天】随着Apache Flink的普及,企业广泛采用Flink on YARN部署流处理应用,高效利用集群资源。变更数据捕获(CDC)工具在现代数据栈中至关重要,能实时捕捉数据库变化并转发给下游系统处理。本文以Flink on YARN为例,介绍如何在Debezium CDC 3.0中配置MySQL连接器,实现数据流处理。首先确保YARN上已部署Flink集群,接着安装Debezium MySQL连接器并配置Kafka Connect。最后,创建Flink任务消费变更事件并提交任务到Flink集群。通过这些步骤,可以构建出从数据库变更到实时处理的无缝数据管道。
304 2
|
3月前
|
资源调度 Java Scala
实时计算 Flink版产品使用问题之如何实现ZooKeeper抖动导致任务失败时,能从最近的检查点重新启动任务
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
5月前
|
SQL 缓存 Oracle
实时计算 Flink版产品使用问题之如何实现重启后直接跑最新的任务而不是根据checkpoint跑历史数据
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
分布式计算 Hadoop Shell
Ububtu18.04安装Hadoop3.1.3全分布集群-持续更新问题集(下)
Ububtu18.04安装Hadoop3.1.3全分布集群 摘要 Ububtu18.04安装 1.选择NAT网络 2.关闭防火墙 3.SSH连接 4.配置静态IP
Ububtu18.04安装Hadoop3.1.3全分布集群-持续更新问题集(下)
|
分布式计算 资源调度 Ubuntu
Ububtu18.04安装Hadoop3.1.3全分布集群-持续更新问题集(上)
Ububtu18.04安装Hadoop3.1.3全分布集群 摘要 Ububtu18.04安装 1.选择NAT网络 2.关闭防火墙 3.SSH连接 4.配置静态IP
Ububtu18.04安装Hadoop3.1.3全分布集群-持续更新问题集(上)
|
分布式计算 大数据 调度
Spark 原理_总体介绍_集群环境 | 学习笔记
快速学习 Spark 原理_总体介绍_集群环境
Spark 原理_总体介绍_集群环境 | 学习笔记
|
存储 负载均衡 NoSQL
分片集群使用及原理介绍(一)|学习笔记
快速学习分片集群使用及原理介绍
699 0
分片集群使用及原理介绍(一)|学习笔记
|
存储 负载均衡 NoSQL
分片集群使用及原理介绍(二)|学习笔记
快速学习分片集群使用及原理介绍
306 0
分片集群使用及原理介绍(二)|学习笔记
|
存储 缓存 分布式计算
Hadoop中HDFS的读写流程(面试重点)、为什么搜不到BlockPlacementPolicyDefault、网络拓扑-节点距离计算、机架感知(副本存储节点选择)
Hadoop中HDFS的读写流程(面试重点)、为什么搜不到BlockPlacementPolicyDefault、网络拓扑-节点距离计算、机架感知(副本存储节点选择)
Hadoop中HDFS的读写流程(面试重点)、为什么搜不到BlockPlacementPolicyDefault、网络拓扑-节点距离计算、机架感知(副本存储节点选择)
|
分布式计算 分布式数据库 Spark
Phoenix-基于HBase的低延迟操作 头歌——答案
Phoenix-基于HBase的低延迟操作 头歌——答案
432 0
下一篇
无影云桌面