云服务器内容精选

  • 查看SQL运行信息 获取当前用户有权限查看的所有的SQL信息(若有管理员权限或预置角色权限可以显示和所有用户查询相关的信息): 1 SELECT usename,state,query FROM PG_STAT_ACTIVITY WHERE DATNAME='数据库名称'; 如果state为active,则query列表示当前执行的SQL语句,其他情况则表示为上一个查询语句;如果state字段显示为idle,则表明此连接处于空闲,等待用户输入命令。回显如下: 1 2 3 4 5 6 usename | state | query ---------+--------+--------------------------------------------------------------------------- leo | idle | select * from joe.mytable; dbadmin | active | SELECT usename,state,query FROM PG_STAT_ACTIVITY WHERE DATNAME='gaussdb'; joe | idle | GRANT SELECT ON TABLE mytable to leo; (3 rows)
  • 查看连接信息 设置参数track_activities为on: SET track_activities = on; 当此参数为on时,数据库系统才会收集当前活动查询的运行信息。 通过以下SQL就能确认当前的连接用户、连接地址、连接应用、状态、是否等待锁、排队状态以及线程id。 1 SELECT usename,client_addr,application_name,state,waiting,enqueue,pid FROM PG_STAT_ACTIVITY WHERE DATNAME='数据库名称'; 回显如下: 1 2 3 4 5 6 usename | client_addr | application_name | state | waiting | enqueue | pid ---------+---------------+------------------+--------+---------+---------+----------------- leo | 192.168.0.133 | gsql | idle | f | | 139666091022080 dbadmin | 192.168.0.133 | gsql | active | f | | 139666212681472 joe | 192.168.0.133 | | idle | f | | 139665671489280 (3 rows) 中止某个会话连接(仅系统管理员有权限): 1 SELECT PG_TERMINATE_BACKEND(pid);
  • 性能调优总体原则和思路 PyTorch在昇腾AI处理器的加速实现方式是以算子为粒度进行调用(OP-based),即通过Python与C++调用CANN层接口Ascend Computing Language(AscendCL)调用一个或几个亲和算子组合的形式,代替原有GPU的实现方式,具体逻辑模型请参考PyTorch自动迁移。 在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迁移性能调优
  • 使用Advisor工具分析生成调优建议 关于Advisor使用及安装过程请参见昇腾社区Gitee。最后生成导出的各类场景的建议包含以下两种: Terminal日志信息的概览建议。 包含Detail信息及修改示例的HTML信息。 按照建议信息做如下修改: 亲和优化器使能,在train.py中修改优化器为apex混合精度模式下的DDP优化方式(修改点:注释第161和167行,增加第168~170行)。 二进制调优使能,减少算子编译耗时,在train.py头文件导入之后添加 (修改点:增加第37行)。 torch_npu.npu.set_compile_mode(jit_compile=False) AICPU算子调优 ,Double类型输入切换成为Float减少cast算子调用耗时,修改diffusion/gaussian_diffusion.py (修改点:注释第871行,增加第872行)。 父主题: 性能调优
  • 环境准备 迁移环境准备有以下两种方式: 表1 迁移环境准备方式 方式 说明 ModelArts Notebook 该环境为在线调试环境,主要面向演示、体验和快速原型调试场景。 环境开通指导请参考Notebook环境创建。 ModelArts Lite DevServer 该环境为裸机开发环境,主要面向深度定制化开发场景。 环境开通指导请参考DevServer资源开通;环境配置指导请参考Snt9B裸金属服务器环境配置指南。 本文基于ModelArts Lite DevServer进行操作,请参考上表说明在贵阳一环境开通和配置指导完成裸机和容器开发初始化配置。 镜像地址为swr.cn-southwest-2.myhuaweicloud.com/atelier/pytorch_2_1_ascend: pytorch_2.1.0-cann_8.0.rc2-py_3.9-hce_2.0.2312-aarch64-snt9b-20240727152329-0f2c29a。 请注意业务基础镜像选择Ascend+PyTorch镜像。
  • 场景介绍 DiT(Diffusion Transformers)模型是一种将Transformer架构引入扩散模型的新方法。传统的扩散模型通常使用U-Net架构,而DiT模型则用Transformer替代了U-Net,处理图像生成和去噪等任务。核心思想是通过Transformer的自注意力机制来捕捉序列中的依赖关系,从而提高生成图像的质量。研究表明,具有较高GFLOPs的DiT模型在图像生成任务中表现更好,尤其是在ImageNet 512×512和256×256的测试中,DiT-XL/2模型实现了2.27的FID值。 下文以Dit模型为例,介绍如何在昇腾设备上如何进行模型迁移,精度及性能调优。
  • 目的端写入慢 检查目的端负载是否已达到目的端数据源上限。优先查看目的端数据源的监控指标,查看CPU、内存、IO等参数是否处于高负载状态。 在排除目的端负载的情况下,加大作业并发,以提高写入速度。 如果第2步也无法有效提升性能,请根据源端抽取慢排查源端的性能因素。 如果排除了源端问题的情况下,请参考对应链路性能调优文档尝试进行参数优化。 如果上述步骤仍然无法提升作业速度,请联系技术支持人员协助解决。
  • 源端抽取慢 检查源端负载是否已到达源端数据源上限。优先查看源端数据源的监控指标,查看CPU、内存、IO等参数是否处于高负载状态。 在排除源端负载的情况下,如果源端是MySQL\Oracle\SQLServer\PostgreSQL\ GaussDB 等的全量+增量作业且作业处于全量抽取阶段,或者Kafka\Hudi等数据源抽取速度慢,请优先尝试加大作业并发数,以提高作业的并发抽取速率。 MySQL\Oracle\SQLServer\PostgreSQL\GaussDB等关系型数据为保证事务有序,在增量阶段是单并发抽取,加大并发一般不会提升抽取性能。 如果第2步也无法有效提升性能,请参考对应链路性能调优文档尝试进行参数优化。 如果上述步骤仍然无法提升作业速度,请联系技术支持人员协助解决。
  • 通用测试配置样例 以下提供的预估值为单台弹性 云服务器ECS 测试的结果。建议使用多台E CS 测试,以达到高性能弹性文件服务的性能指标。 本文以SFS Turbo性能型,云服务器规格如下为例说明。 规格:通用计算增强型 | c3.xlarge.4 | 4vCPUs | 16GB 镜像:CentOS 7.564bit fio命令: fio --randrepeat=1 --ioengine=libaio --name=test -output=output.log --direct=1 --filename=/mnt/nfs/test_fio --bs=1M --iodepth=128 --size=10240M --readwrite=rw --rwmixwrite=30 --fallocate=none 其中,“/mnt/nfs/test_fio”为待测试的目标文件的挂载路径,需具体到文件名,即这里要测试的是“/mnt/nfs”目录下的“test_fio”文件,请根据实际填写。 fio结果: fio命令: fio --randrepeat=1 --ioengine=libaio --name=test -output=output.log --direct=1 --filename=/mnt/nfs/test_fio --bs=1M --iodepth=128 --size=10240M --readwrite=rw --rwmixwrite=70 --fallocate=none 其中,“/mnt/nfs/test_fio”为待测试的目标文件的挂载路径,需具体到文件名,即这里要测试的是“/mnt/nfs”目录下的“test_fio”文件,请根据实际填写。 fio结果: 顺序读IOPS fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=read --bs=4k --size=1G --iodepth=128 --runtime=120 --numjobs=10 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果: 随机读IOPS fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=randread --bs=4k --size=1G --iodepth=128 --runtime=120 --numjobs=10 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果: 顺序写IOPS fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=write --bs=4k --size=1G --iodepth=128 --runtime=120 --numjobs=10 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果: 随机写IOPS fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=randwrite --bs=4k --size=1G --iodepth=128 --runtime=120 --numjobs=10 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果: 顺序读带宽 fio命令: fio --randrepeat=1 --ioengine=libaio --name=test -output=output.log --direct=1 --filename=/mnt/sfs-turbo/test_fio --bs=1M --iodepth=128 --size=10240M --readwrite=read --fallocate=none 其中,“/mnt/sfs-turbo/test_fio”为待测试的目标文件的挂载路径,需具体到文件名,即这里要测试的是“/mnt/sfs-turbo”目录下的“test_fio”文件,请根据实际填写。 fio结果: 随机读带宽 fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=randread --bs=1M --size=10G --iodepth=128 --runtime=120 --numjobs=1 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果: 顺序写带宽 fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=write --bs=1M --size=10G --iodepth=128 --runtime=120 --numjobs=1 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果: 随机写带宽 fio命令: fio --ioengine=libaio --direct=1 --fallocate=none --time_based=1 --group_reporting=1 --name=iops_fio --directory=/mnt/sfs-turbo/ --rw=randwrite --bs=1M --size=10G --iodepth=128 --runtime=120 --numjobs=1 其中,“/mnt/sfs-turbo/”为待测试的目标文件的挂载路径,需具体到文件名,请根据实际填写。 fio结果:
  • 文件系统性能数据 SFS Turbo文件系统的性能主要有IOPS和吞吐量等指标,具体各指标数据参见表1。 表1 性能数据表 参数 20MB/s/TiB 40MB/s/TiB 125MB/s/TiB 250MB/s/TiB 500MB/s/TiB 1000MB/s/TiB 最大容量 1PB 1PB 1PB 1PB 1PB 1PB 最大IOPS 25万 25万 100万 100万 400万 如需提高IOPS,请提交工单申请,最高可达1000万 400万 如需提高IOPS,请提交工单申请,最高可达1000万 最大吞吐量 8GB/s 如需提高吞吐能力,请提交工单申请,最高可达20 GBps 8GB/s 如需提高吞吐能力,请提交工单申请,最高可达20 GBps 20GB/s 如需提高吞吐能力,请提交工单申请,最高可达100 GBps 20GB/s 如需提高吞吐能力,请提交工单申请,最高可达100 GBps 80GB/s 如需提高吞吐能力,请提交工单申请,最高可达200 GBps 80GB/s 如需提高吞吐能力,请提交工单申请,最高可达200 GBps IOPS性能计算公式 IOPS=min(250000,600×容量) 其中,容量单位为TB IOPS=min(250000,1200×容量) 其中,容量单位为TB IOPS=min(1000000,6000×容量) 其中,容量单位为TB IOPS=min(1000000,12500×容量) 其中,容量单位为TB IOPS=min(4000000,25000×容量) 其中,容量单位为TB IOPS=min(4000000,50000×容量) 其中,容量单位为TB
  • 参数调优 数据库参数是数据库系统运行的关键配置信息,设置不合适的参数值可能会影响业务。本文列举了一些重要参数说明。更多参数的详细说明请参见MongoDB官网。 如需通过控制台界面修改参数值,请参见修改DDS实例参数。 enableMajorityReadConcern 该参数表示读取数据时,是否需要从大多数节点获取一致的数据后才返回结果。 默认值为“false”,表示读取数据时,不需要从大多数节点获取一致数据后返回结果,即从单个节点上读取数据就可以返回结果。 该参数设为true的时候,表示读取数据时,需要从大多数节点获取一致数据后才返回结果。该操作会导致LAS文件过大,进而造成CPU过高和磁盘占用大。 在DDS中,不支持设置majority级别的readConcern。对于需要majorityReadConcern的场景,可以将WriteConcern设置为majority,表示数据写入到大多数节点了,这样也就保证了大多数节点的数据一致了。然后通过读取单个节点的数据,就能保证用户读到的数据已经写入到大多数节点,而这样的数据不会发生回滚,避免了脏读的问题。 MongoDB可以通过writeConcern来定制写策略,通过readConcern来定制读策略。 当指定readConcern级别为majority时,能保证用户读到的数据已经写入到大多数节点,而这样的数据不会发生回滚,避免了脏读的问题。 failIndexKeyTooLong 默认值为“true”。 该参数不支持修改,避免过长索引Key。 net.maxIncomingConnections 该参数表示dds mongos或mongod可接受的最大同时连接数量。该参数依赖于实例的规格,实例规格不同对应其默认值也不同。因此,此参数在用户未设置前显示为“default”,表示该参数随内存规格变化。 security.javascriptEnabled 默认值为“false”。 该参数表示是否允许mongod上执行JavaScript脚本。为了安全考虑,默认值为“false”,表示不允许mongod上执行JavaScript脚本,mapreduce、group等命令也将无法使用。 disableJavaScriptJIT 默认值为“true”。 该参数表示是否禁用JavaScriptJIT编译技术。JavaScriptJIT编译技术实现了即时 (JIT) 编译以提高运行脚本时的性能。 “disableJavaScriptJIT”默认值为“true”,表示禁用JavaScriptJIT编译技术。如果需要启用JavaScriptJIT编译技术,可以将“disableJavaScriptJIT”的值设置为“false”。 operationProfiling.mode 默认值为“slowOp”。 该参数表示数据库分析器的级别。 该参数支持如下取值: 默认值为“slowOp”,表示对于耗时超过慢查询阈值的操作,采集器采集数据。 取值为“off”,表示分析器关闭,不收集任何数据。 取值为“all”,表示采集器采集所有操作的数据。 operationProfiling.slowOpThresholdMs 默认值为“500”,单位为ms。 该参数表示慢查询的时间阈值,单位为毫秒,超过该阈值的操作将被认为是慢操作。 如无特殊需求,建议使用默认值500ms。 maxTransactionLockRequestTimeoutMillis 默认值“5”,取值范围为5~100,单位为ms。 该参数表示事务等待获取锁的时间,超过该时间则事务回滚。 父主题: 性能调优
  • 调优流程 调优流程如图1所示。 图1 GaussDB(DWS)性能调优流程 调优各阶段说明,如表1所示。 表1 GaussDB(DWS)性能调优流程说明 阶段 描述 性能诊断 获取集群各节点的CPU、内存、I/O和网络资源使用情况,确认这些资源是否已被充分利用,是否存在瓶颈点。 系统调优 进行操作系统级以及数据库系统级的调优,更充分地利用机器的CPU、内存、I/O和网络资源,避免资源冲突,提升整个系统查询的吞吐量。 SQL调优 审视业务所用SQL语句是否存在可优化空间,包括: 通过ANALYZE语句生成表统计信息:ANALYZE语句可收集与数据库中表内容相关的统计信息,统计结果存储在系统表PG_STATISTIC中。执行计划生成器会使用这些统计数据,以确定最有效的执行计划。 分析执行计划:EXPLAIN语句可显示SQL语句的执行计划,EXPLAIN PERFORMANCE语句可显示SQL语句中各算子的执行时间。 查找问题根因并进行调优:通过分析执行计划,找到可能存在的原因,进行针对性的调优,通常为调整数据库级SQL调优参数。 编写更优的SQL:介绍一些复杂查询中的中间临时数据缓存、结果集缓存、结果集合并等场景中的更优SQL语法。
  • 注意事项 数据库调优是一个复杂和细致的过程,需熟悉数据库系统的内部工作原理和相关技术。它需要综合考虑硬件、软件、查询、配置和数据结构等多个方面的因素,以达到最佳的性能和效率。因此,要求调优人员应对系统软件架构、软硬件配置、数据库配置参数、并发控制、查询处理和数据库应用有广泛而深刻的理解。 性能调优过程有时需要重启集群,可能会中断当前业务。建议在业务低峰期进行需要重启集群的性能调优操作,避免业务异常中断。
  • 调优案例 某用户使用Hudi MOR表存储其设备的订单出借信息,可通过订单号查询订单详细信息,每天订单量相对稳定,部分节假日可能存在小高峰,该场景存在以下特点: 订单号作为唯一值,并且80%以上的查询场景使用订单号进行等值查询,SQL形如select * from table where order_id = 'id1'; 每天订单量稳定,可采用天作为分区键。 历史分区更新不频繁,主要数据更新在新分区。 调优建议: 使用Bucket索引建表(Spark-SQL),并且索引键为订单ID, 分区键为日期。 定期使用compaction合并日志,提高查询性能。 SQL示例: set hoodie.compact.inline=true;set hoodie.schedule.compact.only.inline=true;set hoodie.run.compact.only.inline=false;create table hudi_mor (order_id int, comb int, col1 string, col2 string, dt int)using hudipartitioned by(dt)options(type='mor', primaryKey='order_id', preCombineField='comb',hoodie.index.type = 'BUCKET',hoodie.bucket.index.num.buckets=100,hoodie.bucket.index.hash.field = 'order_id')
  • 基于序列化性能尽量使用POJO和Avro等简单的数据类型 使用API编写Flink程序时需要考虑Java对象的序列化,大多数情况下Flink都可以高效的处理序列化。SQL中无需考虑,SQL中数据都为ROW类型,都采用了Flink内置的序列化器,能很高效的进行序列化。 表1 序列化 序列化器 Opts/s PojoSeriallizer 813 Kryo 294 Avro(Reflect API) 114 Avro(SpecificRecord API) 632