云服务器内容精选
-
参考信息 被广播的表执行超时，导致任务结束。 默认情况下，BroadCastJoin只允许被广播的表计算5分钟，超过5分钟该任务会出现超时异常，而这个时候被广播的表的broadcast任务依然在执行，造成资源浪费。 这种情况下，有两种方式处理： 调整“spark.sql.broadcastTimeout”的数值，加大超时的时间限制。 降低“spark.sql.autoBroadcastJoinThreshold”的数值，不使用BroadCastJoin的优化。
-
操作步骤 参数入口：执行批量加载任务时，在BulkLoad命令行中加入表1中的参数。 表1 增强BulkLoad效率的配置项 参数 描述 配置的值 -Dimporttsv.mapper.class 用户自定义mapper通过把键值对的构造从mapper移动到reducer以提高性能。mapper只需要把每一行的原始文本发送到reducer，reducer解析每一行的每一条记录并创建键值对。 说明： 当该值配置为“org.apache.hadoop.hbase.mapreduce.TsvImporterByteMapper”时，只在执行没有HBASE_CELL_VISIBILITY OR HBASE_CELL_TTL选项的批量加载命令时使用。使用“org.apache.hadoop.hbase.mapreduce.TsvImporterByteMapper”时可以得到更好的性能。 org.apache.hadoop.hbase.mapreduce.TsvImporterByteMapper 和 org.apache.hadoop.hbase.mapreduce.TsvImporterTextMapper
-
性能调优总体原则和思路 PyTorch在昇腾AI处理器的加速实现方式是以算子为粒度进行调用（OP-based），即通过Python与C++调用CANN层接口Ascend Computing Language（AscendCL）调用一个或几个亲和算子组合的形式，代替原有GPU的实现方式，具体逻辑模型参考此处。 在PyTorch模型迁移后进行训练的过程中，CPU只负责算子的下发，而NPU负责算子的执行，算子下发和执行异步发生，性能瓶颈在此过程中体现。在PyTorch的动态图机制下，算子被CPU逐个下发到NPU上执行。一方面，理想情况下CPU侧算子下发会明显比NPU侧算子执行更快，此时性能瓶颈主要集中在NPU侧；另一方面，理想情况下NPU侧算子计算流水线一直执行，不会出现NPU等待CPU算子下发即NPU空转的场景，如果存在，则CPU侧算子下发存在瓶颈。 图1 Host算子下发和Device算子执行 综上所述，性能优化的总体原则为：减少Host算子下发时间、减少Device算子执行时间。 训练代码迁移完成后，如存在性能不达标的问题，可参考下图所示流程进行优化。建议按照单卡、单机多卡、多机多卡的流程逐步做性能调优。 图2 性能调优总体思路 为了便于用户快速进行迁移调优，降低调优门槛，ModelArts提供了MA-Adivisor性能自动诊断工具，用户采集性能profiling数据后，可通过该工具自动扫描profiling数据，工具分析完数据后会给出可能的性能问题点及调优建议，用户可以根据调优建议做相应的修改适配。目前该工具对CV类模型给出的调优建议较多，LLM类建议稍少，但是总体都有性能提升，实测大约可提升10%~30%的性能，并且已经在多个迁移性能调优项目中实际应用。 父主题： PyTorch迁移性能调优
-
单模型性能测试工具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 测试结果 父主题： 性能调优
-
源端抽取慢 检查源端负载是否已到达源端数据源上限，如Mysql、Oracle、SqlServer数据源，优先查看源端数据源的监控指标，查看CPU、内存、IO等参数是否处于高负载状态。 在排除源端负载的情况情况下，如果源端是Mysql\Oracle\SqlServer\PostGres\OpenGauss等的全量+增量作业且作业处于全量抽取阶段，或者Kafka\hudi等数据源抽取速度慢，请优先尝试加大作业并发数，以提高作业的并发抽取速率。 Mysql\Oracle\SqlServer\PostGres\OpenGauss等关系型数据为保证事务有序，在增量阶段是单并发抽取，加大并发一般不会提升抽取性能。 如果第2步也无法有效提升性能，请根据源端优化尝试进行参数优化。 如果上述步骤仍然无法提升作业速度，请联系技术支持人员协助解决。
-
源端优化 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步也无法有效提升性能，请根据源端抽取慢排查源端的性能因素。 如果排除了源端的情况下，请根据目的端优化尝试进行参数优化。 如果上述步骤仍然无法提升作业速度，请联系技术支持人员协助解决。
-
GaussDB (for MySQL)标准版数据库内存使用率过高怎么处理 对于用户核心业务相关的库 请扩容实例规格，具体请参见变更GaussDB(for MySQL)标准版实例的CPU和内存规格。 对于非用户核心业务相关的库 查看本地计算机的内存使用率，如果使用率曲线持续平缓，则无需处理。 对于用户核心业务相关但是数据库规格配置很高的库 在业务低峰期，将数据库参数“performance_schema”的值调整为“OFF”。 通过 CES 监控面板，观察实例的内存使用情况。具体请参见查看GaussDB(for MySQL)标准版实例监控指标。 如果实例的内存使用率仍持续保持较高： 请扩容实例规格。 调整数据库参数“innodb_buffer_pool_size”的值。参数建议值见表1，实际可修改的取值范围以控制台界面为准。 表1 不同内存规格对应的参数建议值 内存（GB） 5.7建议值 8.0建议值 2 536,870,912 Byte（512 MB） 536,870,912 Byte（512 MB） 4 1,073,741,824 Byte（1 GB） 1,073,741,824 Byte（1 GB） 8 4,294,967,296 Byte（4 GB） 5,368,709,120 Byte（5 GB） 16 8,589,934,592 Byte（8 GB） 9,663,676,416 Byte（9 GB） 32 22,548,578,304 Byte（21 GB） 21,474,836,480 Byte（20 GB） 64 47,244,640,256 Byte（44 GB） 47,244,640,256 Byte（44 GB） 128 94,489,280,512 Byte（88 GB） 94,489,280,512 Byte（88 GB） 192 146,028,888,064 Byte（136 GB） 146,028,888,064 Byte（136 GB） 256 193,273,528,320 Byte（180 GB） 193,273,528,320 Byte（180 GB） 384 300,647,710,720 Byte（280 GB） 300,647,710,720 Byte（280 GB） 512 412,316,860,416 Byte（384 GB） 412,316,860,416 Byte（384 GB） 768 618,475,290,624 Byte（576 GB） 618,475,290,624 Byte（576 GB） 1024 824,633,720,832 Byte（768 GB） 824,633,720,832 Byte（768 GB） 请根据业务实际情况，调整参数“innodb_buffer_pool_size”的值。 MySQL本身具有内存动态平衡机制，内存使用率在90%以下您可无需关注，同时建议内存使用率告警阈值设置不低于90%。 在业务运行中缓冲池内存会逐渐增大至“innodb_buffer_pool_size”的值，可通过监控指标“缓冲池利用率”查看缓冲池内存的增长趋势。 GaussDB(for MySQL)标准版的内存分配可划分为Engine层与Server层。 Engine层的内存包括InnoDB Buffer Pool、Log Buffer、Full Text Index Cache，其中InnoDB Buffer Pool为常驻内存，占用内存较大。 InnoDB缓冲池是一个内存区域，用于保存InnoDB表、索引和其他辅助缓冲区的缓存数据，可以通过参数“innodb_buffer_pool_size”定义缓冲池大小。 Server层的内存占用较高的包括Thread Cache、BinLog Cache、Sort Buffer、Read Buffer、Join Buffer等线程缓存，这类缓存非常驻内存，往往会随着连接关闭而释放。 以上内存的分配导致GaussDB(for MySQL)标准版实例运行时内存使用率在80%左右。 父主题： 性能调优
-
为什么会产生流复制冲突？ 当只读库正在执行某个表的查询（可能是业务应用产生，也可能是手动连接执行查询），这时主库执行了DROP TABLE操作，在该操作写入wal日志并同步到只读库后，为了保证数据一致性，只读库会迅速应用DROP TABLE操作，这时DROP TABLE和SELECT就会形成冲突。以下几种场景会产生流复制冲突： 只读库中对某个表正在进行查询（ACCESS SHARE），需要应用wal日志中的ACCESS EXCLUSIVE锁的操作。例如：DROP TABLE、TRUNCATE TABLE、大多数ALTER TABLE等操作。 主库vacuum清理死元组造成的冲突。若只读在主库执行vacuum之前就启动了一个查询，主库vacuum处理掉了只读库所需要的死元组时，就会产生冲突。
-
发生流复制冲突时怎么办？ 参数控制 PostgreSQL提供了以下参数用于控制流复制冲突： max_standby_streaming_delay 参数说明：参数默认为30秒，表示当只读库执行SQL时，有可能与正在应用的wal发生冲突，此查询如果30秒没有执行完成则被中止。 设置为“-1”表示遇到冲突时，直到只读库完成查询后，再继续进行wal回放。注意，“max_standby_streaming_delay”与取消之前一个查询能够运行的最长时间不同，它表示在从主库接收到 wal数据并立刻应用它能够被允许的最长总时间。因此，如果一个查询导致了明显的延迟，后续冲突查询只有更少的时间，直到只读库再次赶上进度。 缺点：该参数设置时间过长，或设置为“-1”时，若只读存在长事务，则会导致主库与只读库之间存在一定的数据时延。 hot_standby_feedback 参数说明：设置为“on”后只读库执行查询时会通知主库，在只读库执行查询过程中，主库不会清理只读库需要的数据，因此也不会发生因vacuum导致的流复制冲突。 缺点：设置为“on”时，可以解决因vacuum导致的流复制冲突，DROP等操作导致的冲突依然存在。同时若只读中存在长事务，会导致数据库中死元组不能及时清理，造成数据库膨胀。 优化建议 优化只读实例的SQL，将SQL查询时长控制在“max_standby_streaming_delay”值以内。 监控只读长事务，根据业务需求，超过一定时长（如30min）的长事务要强制终止。
-
什么是流复制冲突？ PostgreSQL的主库与只读库之间使用流复制进行数据同步，由于主库会不断产生wal日志，当这些wal日志同步到只读库，进行日志应用（Apply）过程中会与只读库的查询（Query）产生冲突。 简单来说，就是只读库查询（Query）与Wal日志应用（Apply）冲突。当只读库的恢复进程无法应用从主库同步过来的wal时，发生流复制冲突。 当发生流复制冲突时，我们会在只读库中看到以下错误日志： ERROR: canceling statement due to conflict with recovery
-
实例瓶颈 原因及现象 实例到达瓶颈的原因一般有如下几种： 业务量持续增长而没有扩容。 硬件老化，性能有损耗。 数据量一直增加，数据结构也有变化，导致原来不慢的SQL变成慢SQL。 您可以在控制台查看实例的资源使用情况。如果资源使用率各项指标都接近100%，可能是实例到达了瓶颈。具体操作，请参见查看实例运行情况。 解决方案 确认实例到达瓶颈后，建议升级实例规格。具体操作，请参见变更实例的CPU和内存规格。
-
定时任务 原因及现象 如果实例负载随时间有规律性变化，可能是存在定时任务。 您可以在控制台查看实例的Delete语句执行频率、Insert语句执行频率、Insert_Select语句执行频率、Replace语句执行频率、Replace_Selection语句执行频率、Select语句执行频率、Update语句执行频率等指标，判断是否有规律性变化。具体操作，请参见查看监控指标。 解决方案 调整定时任务的执行时间，建议在业务低峰期执行。
-
如何提高RDS数据库的查询速度 可以参考如下建议： 如果产生了慢日志，可以通过查看慢日志来确定是否存在运行缓慢的SQL查询，以及各个查询的性能特征，从而定位查询运行缓慢的原因。查询RDS for MariaDB日志，请参见查看或下载慢日志。 查看云数据库RDS的CPU使用率指标，协助定位问题。具体请参见查看监控指标。 可以创建只读实例专门负责查询，减轻主实例负载，分担数据库压力。 如果是实例规格较小但负载过高，您可以提高CPU/内存规格，具体请参见变更实例的CPU和内存规格。 多表关联查询时，关联字段要加上索引。 可以指定字段或者添加where条件进行查询，避免用select*语句进行全表扫描。 父主题： 性能调优
-
解决方法 连接/活跃连接数 若连接数或空闲连接数过多，可执行如下SQL释放当前数据库的所有空闲连接，使用连接池或配置客户端连接超时参数及时释放空闲的连接。若活跃连接数过多，可减少业务并发量，或扩大内存规格。 select pg_terminate_backend(pid) from pg_stat_activity where state = 'idle'; 慢SQL被大量执行 定位到导致内存消耗增加的SQL，对SQL进行优化，或扩大内存规格。 TPS事务数过高 降低事务数，或扩大内存规格。 长连接数量多/连接存活时长久 避免长连接，长连接的缓存可能较大，导致内存不足，建议定期释放长连接。
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
