云服务器内容精选

  • 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 父主题: 性能调优
  • 源端优化 Mysql优化 表1 全量阶段 参数名 类型 默认值 说明 scan.incremental.snapshot.backfill.skip boolean true 全量阶段是否跳过读取binlog数据,默认为true。跳过读取binlog数据可以有效降低内存使用。需要注意的是,跳过读取binlog功能只提供at-least-once保证。 scan.incremental.snapshot.chunk.size int 50000 分片大小,决定了全量阶段单个分片最大数据的数据条数以及分片个数。分片大小越大,单个分片数据条数越多,分片个数越小。 当表的条数过多时,作业会划分较多的分片,从而占用过多的内存导致内存问题,请解决表的条数适当调整该值。 当scan.incremental.snapshot.backfill.skip为false时,实时处理集成作业会缓存单个分片的数据,此时分片越大,占用内存越多,引发内存溢出,在此场景下,可以考虑降低分片大小。 scan.snapshot.fetch.size int 1024 全量阶段抽取数据时,从Mysql侧单次请求抽取数据的最大条数,适当增加请求条数可以减少对Mysql的请求次数提升性能。 debezium.max.queue.size int 8192 数据缓存队列条数,默认为8192,当源表中单条数据过大时(如1MB),缓存过多数据会导致内存溢出,可以考虑减小该值。 debezium.max.queue.size.in.bytes int 0 数据缓存队列大小,默认为0,即表示缓存队列不考虑数据大小,只按照数据条数计算。在debezium.max.queue.size无法有效限制内存占用时,考虑显式设置该值来限制缓存数据的大小。 jdbc.properties.socketTimeout int 300000 全量阶段连接Mysql的socket超时时间,默认为5分钟。当Mysql负载较高,作业出现SocketTimeout异常时,考虑增大该值。 jdbc.properties.connectTimeout int 60000 全量阶段连接Mysql的连接超时时间,默认为1分钟。当Mysq负载较高,作业出现ConnectTimeout异常时,考虑增大该值。 表2 增量阶段 参数名 类型 默认值 说明 debezium.max.queue.size int 8192 数据缓存队列条数,默认为8192,当源表中单条数据过大时(如1MB),缓存过多数据会导致内存溢出,可以考虑减小该值。 debezium.max.queue.size.in.bytes int 0 数据缓存队列大小,默认为0,即表示缓存队列不考虑数据大小,只按照数据条数计算。在debezium.max.queue.size无法有效限制内存占用时,考虑显式设置该值来限制缓存数据的大小。 Oracle优化 表3 全量阶段 参数名 类型 默认值 说明 scan.incremental.snapshot.backfill.skip boolean true 全量阶段是否跳过读取Redo log数据,默认为true。由于Oracle初始化LogMiner 较慢,因此在Oracle场景下,跳过读取Redo log数据可以有效提升全量抽取的性能,同时减低内存的使用。需要注意的是,跳过读取binlog功能只提供at-least-once保证。 scan.incremental.snapshot.chunk.size int 50000 分片大小,决定了全量阶段单个分片最大数据的数据条数以及分片个数。分片大小越大,单个分片数据条数越多,分片个数越小。 当表的条数过多时,作业会划分较多的分片,从而占用过多的内存导致内存问题,请解决表的条数适当调整该值。 当scan.incremental.snapshot.backfill.skip为false时,实时处理集成作业会缓存单个分片的数据,此时分片越大,占用内存越多,引发内存溢出,在此场景下,可以考虑降低分片大小。 scan.snapshot.fetch.size int 1024 全量阶段抽取数据时,从Mysql侧单次请求抽取数据的最大条数,适当增加请求条数可以减少对Oracle的请求次数而提升性能。
  • 目的端写入慢 检查目的端负载是否已达到目的端数据源上限,如DWS、Doris,优先查看目的端监控指标,查看CPU、内存、IO等参数是否处于高负载状态。 在排除目的端负载的情况下,加大作业并发,以提高写入速度。 如果第2步也无法有效提升性能,请根据源端抽取慢排查源端的性能因素。 如果排除了源端的情况下,请根据目的端优化尝试进行参数优化。 如果上述步骤仍然无法提升作业速度,请联系技术支持人员协助解决。
  • 源端抽取慢 检查源端负载是否已到达源端数据源上限,如Mysql、Oracle、SqlServer数据源,优先查看源端数据源的监控指标,查看CPU、内存、IO等参数是否处于高负载状态。 在排除源端负载的情况下,如果源端是Mysql\Oracle\SqlServer\PostGres\OpenGauss等的全量+增量作业且作业处于全量抽取阶段,或者Kafka\hudi等数据源抽取速度慢,请优先尝试加大作业并发数,以提高作业的并发抽取速率。 Mysql\Oracle\SqlServer\PostGres\OpenGauss等关系型数据为保证事务有序,在增量阶段是单并发抽取,加大并发一般不会提升抽取性能。 如果第2步也无法有效提升性能,请根据源端优化尝试进行参数优化。 如果上述步骤仍然无法提升作业速度,请联系技术支持人员协助解决。
  • 单模型性能测试工具Mindspore lite benchmark 在模型精度对齐后,针对Stable Diffusion模型性能调优,可以通过AOE工具进行自助性能调优,进一步可以通过profiling工具对于性能瓶颈进行分析,并针对性的做一些调优操作。 可以直接使用benchmark命令测试mindir模型性能,用来对比调优前后性能是否有所提升。 # shell cd /home_host/work benchmark --modelFile=diffusers/scripts/mindir_models/text_encoder.mindir --device=Ascend 上述命令中:modelFile指定生成的mindir模型文件;device指定运行推理的设备。其他用法参考benchmark文档。 测试结果如下所示: 图1 测试结果 父主题: 性能调优
  • 问题排查步骤 登录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
  • 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