云服务器内容精选
-
源端优化 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
-
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维度位于左边，那么排序后的数据分区范围较大，压缩效率较低。
-
查询性能调优 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”的详细描述。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
