受server间通信带宽低的影响，传统数据并行叠加模型并行的这种混合并行模式的性能表现欠佳，需要引入流水线并行。流水线并行能够将模型在空间上按stage进行切分，每个stage只需执行网络的一部分，大大节省了内存开销，同时缩小了通信域，缩短了通信时间。流水线（Pipeline）并行是将神经网络中的算子切分成多个阶段（Stage），再把阶段映射到不同的设备上，使得不同设备去计算神经网络的不同部分。 在计算某些反向算子时，需要用到一些正向算子的计算结果，导致这些正向算子的计算结果需要驻留在内存中，直到依赖它们的反向算子计算完，这些正向算子的计算结果占用的内存才会被复用。这一现象推高了训练的内存峰值，在大规模网络模型中尤为显著。如：Dropout、Activations。在进行数据并行训练时，模型的参数更新部分在各卡间存在冗余计算，优化器并行通过将优化器的计算量分散到数据并行维度的卡上，在大规模网络上（比如Bert、GPT）可以有效减少内存消耗并提升网络性能。 传统的数据并行模式将模型参数在每台设备上都有保有副本，把训练数据切分，在每次迭代后利用通信算子同步梯度信息，最后通过优化器计算对参数进行更新。数据并行虽然能够有效提升训练吞吐量，但并没有最大限度地利用机器资源。其中优化器会引入冗余内存和计算，消除这些冗余是需关注的优化点。 

排查是否存在执行时间很久的SQL语句，并识别每个用户账号的并发数。 1) 排查是否存在执行时间很久的语句，可以杀掉执行时间很久的语句观察整体并发是否有下降； select * from pgxc_stat_activity where state != 'idle' and application_name not like'%cn_%' order by query_start limit 30; 2) 识别每个用户账号的并发数，可以通过锁定低优先级账号或锁定并发数异常的账号进行应急。 select count(*), usename from pgxc_stat_activity where state != 'idle' andapplication_name not like '%cn_%' group by 2;1) 当出现stream多的语句时，可观察探针性能，若探针关联查询性能劣化，则杀掉stream多的语句进行应急，并反馈给业务进行优化；若探针性能无劣化，则持续观察； 2) stream多的语句优化建议： 减少join数量； 减少union all数量； 减少子查询数量； 拆分语句。 

1) 查看详细锁等待信息； select * from pgxc_lock_conflicts order by locktype, relname, partname,transactionid::text, nodename; 2) 根据locktype、relname、partname、transactionid信息识别每一组持锁语句和等锁语句； locktype为relation的，relname相同的记录为同一组； locktype为partition的，relname与partname都相同的记录为同一组； locktype为transactionid 的，transactionid相同的记录为同一组，表示行级锁冲突。 3) 对每一组锁冲突语句依次分析，granted为t表示持锁正在跑的语句，granted为f表示正在申请锁被阻塞的语句； 4) 对于locktype为relatione和partition的，识别等锁语句和持锁语句后，若多个等锁语句被一个持锁语句阻塞，可通过杀掉持锁语句进行应急，并分析该语句长时间持锁跑不完的原因； 对于locktype为transactionid的，表示行级锁冲突，一般为并发更新(update/delete)场景，容易出现在列存场景下，此场景一般为多个update或delete频繁变化持锁和等锁状态，杀掉单个语句无法解决此问题，需要业务侧调整逻辑，避免列存并发更新。 5) 分布式死锁：对于locktype为relatione和partition的，如果出现在某个DN上语句A持锁，语句B等锁，另一个DN上语句B持锁，语句A等锁，这种现象称为分布式死锁；对于分布式死锁场景，可以通过杀掉其中任意一条语句使得另一条语句优先执行成功，再重新执行被杀掉的语句。 

1) 识别是高并发排队还是内存估算导致的ccn排队； select count(1), usename, enqueue from pgxc_stat_activity where state != 'idle'and application_name not like '%cn_%' and enqueue != 'no waiting queue' andenqueue is not null group by 2,3; 2) 如果排队主要是waiting in global queue，说明主要是高并发导致排队，需要排查是否存在执行时间很久的SQL语句，并识别每个用户账号的并发数； a) 排查是否存在执行时间很久的语句，可以杀掉执行时间很久的语句观察整体并发是否有下降； select * from pgxc_stat_activity where state != 'idle' and application_name not like'%cn_%' order by query_start limit 30; b) 识别每个用户账号的并发数，可以通过锁定低优先级账号或锁定并发数异常的账号进行应急。 select count(*), usename from pgxc_stat_activity where state != 'idle' andapplication_name not like '%cn_%' group by 2; 3) 如果排队主要是wait in ccn，说明是ccn排队，需要排查当前估算内存最大的语句top5，可以杀掉估算内存最大的语句进行应急； select * from pgxc_wlm_session_statistics order by estimate_memory desc limit 20; 4) 杀掉该语句后，可以根据上一步的查询结果确认语句实际占用内存与估算内存是否接近，若实际使用内存不高，估算内存高，可通过对表做analyze尝试规避，或session级设置query_mem参数进行规避；若语句实际使用内存很高，则需要对语句进行优化。

在实际的生产环境中，难免会出现一些突发情况，导致查询语句出现异常中断、阻塞时间长等情况，如果当时没能记录下来，那么事后就要投入更多的人力以及时间成本去对错误进行定位和解决，有时还往往定位不到错误出现的地方。为了解决这种情况，DWS提供了历史TOPSQL和实时TOPSQL功能，用以查看sql语句级别的性能开销。TOPSQL中会记录作业运行时的资源使用情况，包括内存、下盘、CPU时间、执行总时间、排队时间等信息，并且会打印性能告警信息，同时也会记录语句对应的执行计划信息。其中，实时TOPSQL会显示当前正在运行的语句的执行情况，语句执行完成后，这些信息会转储到历史TOPSQL中。使用TOPSQL功能需要在管控面上设置如下参数： enable_resource_track: on（表示开启topsql功能）； enable_resource_record: on（表示开启topsql的转储功能，可以查到历史topsql）； enable_track_record_subsql: on（表示可以记录存储过程中的内部语句）； resource_track_cost: 0（执行代价大于resource_track_cost的作业会被记录，设置为0表示除特殊数据定义语句外（SET、SHOW、ALTER、DROP等），可以记录所有DML/SELECT等语句）； resource_track_duration: 0（执行时间大于resource_track_duration的作业会被记录，设置为0表示除特殊数据定义语句外（SET、SHOW、ALTER、DROP等），可以记录所有DML/SELECT等语句）

存储过程是在大型数据库系统中为了完成特定功能而封装的一组SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名称并设置参数（如果该存储过程带有参数）来执行它。关于存储过程的使用，议论很多，褒贬不一，这里列出主要的优缺点。缺点 ：开发演进难，应用开发完成后，随着用户需求变化、数据结构变化、数据量变化，存储过程的迭代修改、验证难度会非常大。 优点 ：可重复使用，功能使用存储过程封装可以减少数据库开发人员的开发工作量。 调试困难，相比一般的应用SQL开发，存储过程的开发缺少有效的调试工具。 相对安全性，可以隐藏执行逻辑，只暴露名称和参数。 维护困难，随着SQL行数的增加，维护复杂度呈线性提升。 移植问题，参加过数据库迁移的同学都应该知道，最难莫过于超大存储过程的迁移。 综上存储过程的优缺点，建议如下： 存储过程不建议大规模使用； 针对业务流程相对简单的功能，可以使用存储过程封装，因逻辑简单，可以快速调整演进和验证，即使碰到问题也能快速定位修复； 针对业务流程相对复杂的功能，不建议使用存储过程，因为无论是调试、演进还是维护的难度都会让所谓的优点不值一提。

低效类型 语句不下推（分布式） 语句特征：含不下推函数、语法。 计划特征：含_REMOTE_TABLE_QUERY_关键字。 子查询不提升（内部多次执行） 语句特征：含not exists、notin等。 计划特征：含SubPlan关键字。 优化方法 通过topsql或CN找到不下推因素并整改。 改写SQL消除SubPlan。 资源消耗类（CPU） 语句特征：含多个UNION ALL、聚集操作等。 固定数据使用中间表，减少过程中CPU消耗。 资源消耗类（IO） 计划特征：含多个agg、append等算子。 语句特征：行存大表全表扫描、COUNT等。 计划特征：Seq Scan数据量大，Temp file下盘等。 根据业务场景，使用索引、列存等手段降IO。 资源消耗类（内存） 语句特征：关联、聚集操作多，数据量大。 计划特征：join、agg层数据量大固定数据使用中间表，减少过程中内存消耗。 资源消耗类（网络） 语句特征：表关联条件不包含分布列。 计划特征：Stream层数据量大。 调整表的分布列或者调整关联条件列，减少Stream通信数据量。  语句特征：like操作、or操作等。 等价修改为精确匹配、and操作。

索引可以用来提高数据库查询性能，但是不恰当的使用将导致数据库性能下降。建议仅在匹配如下某条原则时创建索引。 经常作为where子句的过滤条件上的字段； 经常作为连接条件的字段，对于存在多字段连接的查询，建议在这些字段上建立组合索引； 例如， select * from t1 join t2 on t1.a=t2.a and t1.b=t2.b，可以在t1表上的a，b字段上建立组合索引。 经常出现在order by、 group by后的字段； 经常作为查询返回结果的字段，distinct、max后的字段； 创建组合索引时，区分度高（DISTINCT值多）的列放前面。 分析过程： 1) 每5min从上游同步一次数据 -> 高频实时入库场景，推荐使用行存表； 2) 表数据量10亿 -> 数据量较大，评估该表查询模型，是否涉及多表关联的分析型查询； 3) 查询性能要求高，涉及多表关联分析型查询 -> 需要列存提升性能。

索引之利 ：提供主键和唯一性约束，满足业务需要 索引之弊 ：索引页面占用额外空间，导致一定的磁盘膨胀 点查询提速显著，直接定位到需要的数据，减少无效IO 利用等值条件索引查询速度快的优势，结合nestloop提高多表join效率 影响数据增删改的性能，因都涉及索引更新操作 索引需要记录XLOG，更新索引会增加主备同步压力 利用索引天然有序的特质，加速排序、求max等操作性能 当统计信息收集不及时触发优化器误判选到不该选的索引计划，可能导致查询性能反向劣化 利用倒排索引加速全文检索 分区表上每个分区都有各自的索引，分区和索引过多会增加cache memory等公共资源的消耗btree 行存默认索引类型（列存也支持），适用于主键、点查场景 相比psort，无论是点查还是范围查询，性能均更优；略微不足的是磁盘空间的占用及对导入性能的影响比psort稍差。 psort 列存默认索引类型，适用于范围查询场景 性能提升效果比较中庸，在列存支持btree后，建议直接用btree索引 注意：列存表上创建索引不指定类型时默认是psort，所以建议在列存上创建索引时显示指定索引类型为btree。 通用倒排索引，适用于全文检索场景 特定场景使用 通用搜索树索引，适用于位置检索场景 特定场景使用

分区相当于把逻辑上的一张表根据分区键划分成几张小表进行分别存储，建议大表都考虑做分区，其好处主要有： 1) 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率； 2) 增强可用性：如果分区表的某个分区出现故障，表在其他分区的数据仍然可用； 3) 方便维护：定期删除数据的场景，可只针对特定分区做TRUNCATE PARTITION和DROP PARTITION，效率高且不产生脏数据，维护成本低。 （RangePartitioning） 根据分区键值的范围，将数据存储到不同的分区中，分区键范围连续但不重叠。 1、日期或者时间类的字段作为分区键 2、查询中大多包含分区键作为过滤条件 3、定期按照分区键清理数据 列表分区（ListPartitioning） 根据分区键值的列表进行分区，各分区的列表值不重复 1、特定数量的枚举值作为分区键值 2、查询中大多包含分区键作为过滤条件 

分布方式主要决定了数据的存储分布情况，同时也直接影响后续关联查询的计算效率。Hash：表数据按照分布列生成的hash值与 DN实例的映射关系，将数据分布到各DN实例。 优点：每个DN仅包含部分数据，占用整体空间小。 大表、事实表。 缺点：数据分布的均匀程度强依赖分布列的选择；JOIN关联条件不包含各自分布列的场景存在节点间数据通信的消耗。 RoundRobin 表数据按照轮询的方式依次分布到各DN实例。 优点：每个DN仅包含部分数据，占用整体空间小；数据轮询均匀分布，不依赖分布列，不存在数据存储倾斜问题。 缺点：无法通过分布列条件消除和减少节点间通信，此类场景性能不如Hash分布方式。 Replication 表中的全量数据在集群的每一个DN实例上保留一份。 优点：每个DN上都有此表的全量数据，JOIN操作中可以完全避免节点间数据通信，从而减小网络开销，同时减少了STREAM线程启停开销； 大表、事实表，无合适分布列的表。 

表是数据库中最基础的对象，其设计的好坏直接决定后续业务的稳定性。表设计的关键在于存储方式、分布方式、分区策略的选择，这些选择均和业务特征强相关，要结合业务实际特征来设计。 当前表的主要存储类型即行存和列存，存储方式和业务特征决定了数据占用的空间、膨胀的速度、查询性能的优劣和稳定。 DML增删改：UPDATE和DELETE操作多的场景。 DML查询：点查询(返回记录少，基于索引的简单查询)。 DML查询：统计分析类查询(group , join的数据量大的场景)。 DML增删改：INSERT批量导入场景（单次单分区入库量接近或大于6w* DN数）。 DML查询：统计分析类查询(group , join的数据量大的场景)。 DML增删改：UPDATE/DELETE多的场景、INSERT小批量插入的场景DML查询：高并发的点查询

如果用户在APP的开发中，使用了连接池机制，那么需要遵循如下规范： 如果使用连接池，需要确保应用侧连接池的空闲超时时间配置要不长于DWS中，SESSION_TIMEOUT时间，或者连接池中连接建连后设置关闭SESSION_TIMEOUT，否则可能导致业务从连接池获取的连接已在DWS中超时退出，从而出现报错。 如果使用连接池中的连接并设置了GUC参数，那么在将连接归还连接池之前，必须使用“SET SESSION AUTHORIZATION DEFAULT;RESET ALL;”将连接的状态清空，否则连接被其他业务复用时，可能会出现性能、业务报错等各类问题。 如果使用连接池中的连接创建了临时表，那么在将连接归还连接池之前，必须手动删除临时表，否则连接被其他业务复用时，可能出现临时表创建报错问题（临时表为 session 级别对象，使用同一个连接池连接，相当于在同一个session，临时对象也不能重名）。 应用侧有使用连接池的场景，如果在DWS侧通过GS_GUC RELOAD设置了全局的GUC参数，需要重启应用侧连接池才能够享受该参数变化，因该设置只针对新建的连接生效，针对连接池中已有的老连接不生效。 在应用中的复杂作业和简单作业场景，建议单独划分连接池，避免作业间公共资源消耗的影响（如IDLE连接内存消耗）。 在应用侧连接数不受控的场景，可以借助连接池机制控制应用侧接入的的活跃会话数。

保证业务连接均匀分布到各CN，参考29.1.3配置负载均衡，避免单CN出现并发瓶颈； 应用程序使用连接完成作业任务之后，需及时主动CLOSED连接，避免IDLE空闲连接持续占位增长，导致无法新建连接； 应用程序尽量使用自动提交方式（默认autocommit），如需关闭 autocommi时则需应用程序确保事务手动提交，避免造成大量“idle in transaction”的连接； 引用通过JDBC连接数据库时，应该保证下面三个时区设置一致： a) JDBC客户端所在主机的时区。 b) GaussDB(DWS) Server所在主机的时区。 c) GaussDB(DWS)集群配置中时区（例如：SET TIME ZONE 'UTC-8'）。规划数据库用户是规划整个业务模型的一部分，建议根据各业务模块进行用户划分，合理的用户划分能够帮助DBA从服务侧更有效的区分业务优先级，以及不同业务类型的精确管控，同时便于做更精确的资源管控。

cm_ctl、gs_ctl、gs_om好像都可以管理集群，有什么区别啊，用哪个更好呀