云服务器内容精选

  • RDS支持的最大IOPS是多少 华为云关系型数据库服务支持的IOPS取决于云硬盘(Elastic Volume Service,简称EVS)的IO性能,具体请参见《云硬盘产品介绍》中“磁盘类型及性能介绍”的内容。 RDS for MariaDB本地SSD盘的IOPS如下: 表1 x86通用型规格对应的IOPS vCPU 内存(GB) 读IOPS 写IOPS 2 4 2000 2000 2 8 4000 4000 4 8 5000 5000 4 16 7000 7000 8 16 8000 8000 8 32 12000 12000 16 64 14000 14000 表2 独享型规格对应的IOPS vCPU 内存(GB) 读IOPS 写IOPS 4 16 4500 4500 4 32 9000 9000 8 32 9000 9000 8 64 18000 18000 16 64 18000 18000 16 128 36000 36000 32 128 36000 36000 32 256 72000 72000 64 512 144000 144000 父主题: 性能调优
  • Flink作业运行异常,如何定位 在“Flink作业”管理页面,对应作业“操作”列单击“编辑”按钮,在作业运行界面确认作业是否勾选“保存作业日志”参数。 图1 保存作业日志 是,则执行3。 否,则运行日志不会转储OBS桶,需要先执行2保存作业运行日志。 在作业运行界面勾选“保存作业日志”,在“OBS桶”参数选择存储运行日志的OBS桶。单击“启动”重新运行作业。作业重新运行完成后再执行3及后续步骤。 在Flink作业列表单击对应作业名称,进入作业详情页面,选择“运行日志”页签。 单击OBS桶,获取对应作业的完整运行日志。 图2 查看运行日志 下载最新“jobmanager.log”文件,搜索“RUNNING to FAILED”关键字,通过上下文的错误栈,确认失败原因。 如果“jobmanager.log”文件中的信息不足以定位,可以在运行日志中找到对应的“taskmanager.log”日志,搜索“RUNNING to FAILED”关键字,确认失败原因。 父主题: Flink作业性能调优类
  • 问题排查步骤 登录ClickHouse客户端,需要排查是否存在异常的Merge。 select database, table, elapsed, progress, merge_type from system.merges; 业务上建议insert频率不要太快,不要小批量数据的插入,适当增大每次插入的时间间隔。 数据表分区分配不合理,导致产生太多的区分,需要重新划分分区。 如果没有触发Merge,或者Merge较慢,需要调整参数加快Merge。 加速Merge,需要调整如下参数,请参考加速Merge操作: 配置项 参考值 max_threads CPU核数*2 background_pool_size CPU核数 merge_max_block_size 8192的整数倍,根据CPU内存资源大小调整 cleanup_delay_period 适当小于默认值 30
  • 配置场景 SparkSQL在进行shuffle操作时默认的分块数为200。在数据量特别大的场景下,使用默认的分块数就会造成单个数据块过大。如果一个任务产生的单个shuffle数据块大于2G,该数据块在被fetch的时候还会报类似错误: Adjusted frame length exceeds 2147483647: 2717729270 - discarded 例如,SparkSQL运行TPCDS 500G的测试时,使用默认配置出现错误。所以当数据量较大时需要适当的调整该参数。
  • 配置描述 参数入口: 在应用提交时通过“--conf”设置这些参数,或者在客户端的“spark-defaults.conf”配置文件中调整如下参数。 表1 参数说明 参数 说明 默认值 spark.executor.memoryOverhead 用于指定每个executor的堆外内存大小(MB),增大该参数值,可以防止物理内存超限。该值是通过max(384,executor-memory*0.1)计算所得,最小值为384。 1024
  • HetuEngine元数据缓存介绍 当HetuEngine访问Hive数据源时,需要访问Hive metastore获取元数据信息。HetuEngine提供了元数据缓存的功能,当首次访问Hive数据源的库或表时,会将该库或表的元数据信息(数据库名、表名、表字段、分区信息、权限信息等)缓存起来,后续访问时不需要再次访问Hive metastore,在Hive数据源的表数据变化不频繁的场景下,可以一定程度上提升查询的性能。
  • 操作步骤 优化GC。 调整老年代和新生代的比值。在客户端的“conf/flink-conf.yaml”配置文件中,在“env.java.opts”配置项中添加参数:“-XX:NewRatio”。如“ -XX:NewRatio=2”,则表示老年代与新生代的比值为2:1,新生代占整个堆空间的1/3,老年代占2/3。 开发Flink应用程序时,优化DataStream的数据分区或分组操作。 当分区导致数据倾斜时,需要考虑优化分区。 避免非并行度操作,有些对DataStream的操作会导致无法并行,例如WindowAll。 keyBy尽量不要使用String。
  • CarbonData查询流程 当CarbonData首次收到对某个表(例如表A)的查询任务时,系统会加载表A的索引数据到内存中,执行查询流程。当CarbonData再次收到对表A的查询任务时,系统则不需要再加载其索引数据。 在CarbonData中执行查询时,查询任务会被分成几个扫描任务。即,基于CarbonData数据存储的HDFS block对扫描任务进行分割。扫描任务由集群中的执行器执行。扫描任务可以并行、部分并行,或顺序处理,具体采用的方式取决于执行器的数量以及配置的执行器核数。 查询任务的某些部分可在独立的任务级上处理,例如select和filter。查询任务的某些部分可在独立的任务级上进行部分处理,例如group-by、count、distinct count等。 某些操作无法在任务级上处理,例如Having Clause(分组后的过滤),sort等。这些无法在任务级上处理,或只能在任务级上部分处理的操作需要在集群内跨执行器来传输数据(部分结果)。这个传送操作被称为shuffle。 任务数量越多,需要shuffle的数据就越多,会对查询性能产生不利影响。 由于任务数量取决于HDFS block的数量,而HDFS block的数量取决于每个block的大小,因此合理选择HDFS block的大小很重要,需要在提高并行性,进行shuffle操作的数据量和聚合表的大小之间达到平衡。
  • 压缩调优 CarbonData结合少数轻量级压缩算法和重量级压缩算法来压缩数据。虽然这些算法可处理任何类型的数据,但如果数据经过排序,相似值在一起出现时,就会获得更好的压缩率。 CarbonData数据加载过程中,数据基于Table中的列顺序进行排序,从而确保相似值在一起出现,以获得更好的压缩率。 由于CarbonData按照Table中定义的列顺序将数据进行排序,因此列顺序对于压缩效率起重要作用。如果低cardinality维度位于左边,那么排序后的数据分区范围较小,压缩效率较高。如果高cardinality维度位于左边,那么排序后的数据分区范围较大,压缩效率较低。
  • 数据加载性能调优 数据加载性能调优与查询性能调优差异很大。跟查询性能一样,数据加载性能也取决于可达到的并行性。在数据加载情况下,工作线程的数量决定并行的单元。因此,更多的执行器就意味着更多的执行器核数,每个执行器都可以提高数据加载性能。 同时,为了得到更好的性能,可在HDFS中配置如下参数。 表1 HDFS配置 参数 建议值 dfs.datanode.drop.cache.behind.reads false dfs.datanode.drop.cache.behind.writes false dfs.datanode.sync.behind.writes true
  • 查询性能调优 CarbonData可以通过调整各种参数来提高查询性能。大部分参数聚焦于增加并行性处理和更好地使用系统资源。 Spark Executor数量:Executor是Spark并行性的基础实体。通过增加Executor数量,集群中的并行数量也会增加。关于如何配置Executor数量,请参考Spark资料。 Executor核:每个Executor内,并行任务数受Executor核的配置控制。通过增加Executor核数,可增加并行任务数,从而提高性能。 HDFS block容量:CarbonData通过给不同的处理器分配不同的block来分配查询任务。所以一个HDFS block是一个分区单元。另外,CarbonData在Spark驱动器中,支持全局block级索引,这有助于减少需要被扫描的查询block的数量。设置较大的block容量,可提高I/O效率,但是会降低全局索引效率;设置较小的block容量,意味着更多的block数量,会降低I/O效率,但是会提高全局索引效率,同时,对于索引查询会要求更多的内存。 扫描线程数量:扫描仪(Scanner)线程控制每个任务中并行处理的数据块的数量。通过增加扫描仪线程数,可增加并行处理的数据块的数量,从而提高性能。可使用“carbon.properties”文件中的“carbon.number.of.cores”属性来配置扫描仪线程数。例如,“carbon.number.of.cores = 4”。 B-Tree缓存:为了获得更好的查询特性,可以通过B-tree LRU(least recently used,最近最少使用)缓存来优化缓存内存。在driver中,B-Tree LRU缓存配置将有助于通过释放未被访问或未使用的表segments来释放缓存。类似地,在executor中,B-Tree LRU缓存配置将有助于释放未被访问或未使用的表blocks。具体可参考表2中的参数“carbon.max.driver.lru.cache.size”和“carbon.max.executor.lru.cache.size”的详细描述。
  • 配置扫描仪线程 扫描仪线程属性决定了每个分割的数据被划分的可并行处理的数据块的数量。如果数量过多,会产生很多小数据块,性能会受到影响。如果数量过少,并行性不佳,性能也会受到影响。因此,决定扫描仪线程数时,需要考虑一个分割内的平均数据大小,选择一个使数据块不会很小的值。经验法则是将单个块大小(MB)除以250得到的值作为扫描仪线程数。 增加并行性还需考虑的重要一点是集群中实际可用的CPU核数,确保并行计算数不超过实际CPU核数的75%至80%。 CPU核数约等于: 并行任务数x扫描仪线程数。其中并行任务数为分割数和执行器数x执行器核数两者之间的较小值。
  • 操作步骤 参数入口: HBase角色相关的JVM参数需要配置在安装有HBase服务的节点的“${BIGDATA_HOME}/ FusionInsight _HD_*/install/FusionInsight-HBase-2.2.3/hbase/conf/”目录下的“hbase-env.sh”文件中。 每个角色都有各自的JVM参数配置变量,如表1。 表1 HBase相关JVM参数配置变量 变量名 变量影响的角色 HBASE_OPTS 该变量中设置的参数,将影响HBase的所有角色。 SERVER_GC_OPTS 该变量中设置的参数,将影响HBase Server端的所有角色,例如:Master、RegionServer等。 CLIENT_GC_OPTS 该变量中设置的参数,将影响HBase的Client进程。 HBASE_MASTER_OPTS 该变量中设置的参数,将影响HBase的Master。 HBASE_REGIONSERVER_OPTS 该变量中设置的参数,将影响HBase的RegionServer。 HBASE_THRIFT_OPTS 该变量中设置的参数,将影响HBase的Thrift。 配置方式举例: export HADOOP_NAMENODE_OPTS="-Dhadoop.security.logger=${HADOOP_SECURITY_ LOG GER:-INFO,RFAS} -Dhdfs.audit.logger=${HDFS_AUDIT_LOGGER:-INFO,NullAppender} $HADOOP_NAMENODE_OPTS"
  • 操作步骤 以root用户登录已安装Hive客户端的节点。 执行以下命令,进入客户端安装目录,例如“/opt/client”。 cd /opt/client 执行source bigdata_env命令,配置客户端环境变量。 在客户端中执行如下命令,执行登录操作。 kinit 用户名 执行以下命令登录Hive客户端。 beeline 指定静态分区或者动态分区。 静态分区: 静态分区是手动输入分区名称,在创建表时使用关键字PARTITIONED BY指定分区列名及数据类型。应用开发时,使用ALTER TABLE ADD PARTITION语句增加分区,以及使用LOAD DATA INTO PARTITON语句将数据加载到分区时,只能加载到静态分区。 动态分区:通过查询命令,将结果插入到某个表的分区时,可以使用动态分区。 动态分区通过在客户端工具执行如下命令开启: set hive.exec.dynamic.partition=true; 动态分区默认模式是“strict”,也就是必须至少指定一列为静态分区,在静态分区下建立动态子分区,可以通过如下设置开启完全的动态分区: set hive.exec.dynamic.partition.mode=nonstrict; 动态分区可能导致一个DML语句创建大量的分区,对应创建大量新文件夹,对系统性能可能带来影响。 在文件数量大的情况下,执行一个SQL语句启动时间较长,可以在执行SQL语句之前执行“set mapreduce.input.fileinputformat.list-status.num-threads = 100;”命令缩短启动时间。“mapreduce.input.fileinputformat.list-status.num-threads”参数需要先添加到Hive的白名单才可设置。
  • 操作场景 抢占任务可精简队列中的job运行并提高资源利用率,由ResourceManager的capacity scheduler实现,其简易流程如下: 假设存在两个队列A和B。其中队列A的capacity为25%,队列B的capacity为75%。 初始状态下,任务1发送给队列A,此任务需要75%的集群资源。之后任务2发送到了队列B,此任务需要50%的集群资源。 任务1将会使用队列A提供的25%的集群资源,并从队列B获取的50%的集群资源。队列B保留25%的集群资源。 启用抢占任务特性,则任务1使用的资源将会被抢占。队列B会从队列A中获取25%的集群资源以满足任务2的执行。 当任务2完成后,集群中存在足够的资源时,任务1将重新执行。