【操作步骤&问题现象】1、发现DN内存不足，查看进程发现有个线程占用了一半内存，就大佬讲解下这个线程正常么。select pg_catalog.gs_wlm_readjust_user_space_with_reset_flag('0000', false);

GaussDB针对泰山服务器做了很多加固配置，必须要做这些加固配置才能保证GaussDB的性能以及稳定性。1. 分析过程1）集群的网络存在大量的网络重传.可以通过gsar.sh 脚本测试获得结果(gsar.sh已经在8.0版本随版本发布，放在gaussdb二进制所在同级目录的dfx_tool/gsar.sh)用法：sh gsar.sh + 网卡名2）Gaussdb进程持续占用内存过高，即使在没有压力的时候。2、解决方法按照操作指导来做加固配置：https://support.huawei.com/enterprise/zh/doc/EDOC1100120332?idPath=7919749%7C7941815%7C19942925%7C250430185%7C21407429https://support.huawei.com/enterprise/zh/bulletins-product/ENEWS2000007743

1、平常跑作业的时候，在并发比较高，作业量比较大的时候，会有”Memory unavailable”之类的错误。2、通过抓取典型慢SQL的performance信息，发现有“Temp File Num”的关键字。3、查看guc参数max_process_memory/shared_buffers/ cstore_buffers， 发现max_process_memory设置偏小，shared_buffers和 cstore_buffers设置过大。4、问题原因单个gaussdb进程的可用内存是受到 max_process_memory控制的，其中shared_buffers和cstore_buffers是预占式的。对于一些物化算子，比如Sort，Hash，HashAgg等，这些物化算子会把中间见过缓存到内存中，这部分内存占用的就是  max_process_memory-shared_buffers-cstore_buffers-其他一些内存  所剩余的内存，如果max_process_memory设置偏小，shared_buffers和 cstore_buffers设置过大，那么用于物化算子缓存结果集的内存就会很小，导致很容易出现结果集下盘，从而影响集群性能。5、解决办法调整guc参数max_process_memory/shared_buffers/ cstore_buffers。max_process_memory按照产品手册中的建议设置：物理内存大小*0.665/(1+主DN个数)shared_buffers是用于对行存表数据做缓存的内存大小，只会影响到行存表scan的性能。cstore_buffers是用于对列存表数据做缓存的内存大小，只会影响到列存表scan的性能。当集群中以行存表为主的时候，可以适当调大shared_buffers，以列存表为主的场景，可以适当调大cstore_buffers，但是也不宜过大。举例来讲：如果max_process_memory根据配置建议配置的是25GB，那么shared_buffers/cstore_buffers可以设置为2GB；如果max_process_memory根据配置建议配置的是50GB，那么shared_buffers/cstore_buffers可以设置为4GB。

【问题现象】            DWS集群监控面板不显示监控信息：即 数据仓库服务-》集群列表-》操作-》监控面板进入某个集群的监控页面，其中集群概览，监控-》主机监控，设置-》监控设置 长时间加载，F12查看status canceled，Timing 超时【分析过程】     登录CDK Master，登录monitor容器查看日志             #kubectl get pod -n dws            #kubectl -ti exec dms-monitoring-xxxxxx -n dws  bash            #vi logs/dms-monitoring.log             日志中大量出现"Failed to obtain JDBC Connection;nested exception is java.sql.SQLTransientConnectionException:HikariPool-l- Connection is not availiable,request timed out after 30000ms"        原因是monitor服务连接池的问题，具体是连接数不够，导致新的请求获取连接超时，所以可以通过人工干扰释放连接进行规避，具体操作可以重启monitor服务重新初始化连接池，这样新的请求就可以获取连接【解决方案】        1.重启monitor服务：         kebectl delete pod dmsmonitor-xxx -n dws 逐个删除dmsmonitor容器，等待重新拉起，再次刷新页面

GaussDB 200添加CN实例的逻辑是什么？为啥元数据越多越慢？

【功能模块】逻辑集群是对物理集群的一种数据划分，是物理集群的一部分，可理解为子集群。逻辑集群主要用来资源隔离。主要包括：数据隔离：不同业务的表创建在不同逻辑集群上，表数据物理上隔离；资源隔离：不同逻辑集群的CPU，内存，IO资源是隔离的；跨逻辑集群数据访问的资源是受控的；同一逻辑集群内部支持多租户隔离；权限隔离：访问其他逻辑集群的表和数据库对象需要授权。 逻辑集群是基于pgxc的NodeGroup实现。如下图所示，整个大集群包括8个物理节点（主机），逻辑集群1包括物理节点1、2、3；逻辑集群2包括物理节点4、5、6；弹性逻辑集群包括物理节点7、8。【操作步骤&问题现象】这么做的实际目的：  隔离资源但是又能方便访问(不用搬数据)；可以不断加入逻辑集群，而不用数据重分布 。   但是带来的问题是：  1.  大大降低了集群的运算能力(明明可以3倍计算能力，被划分成了三部分，对大SQL不友好)   ？  2.  如果需要JOIN的表分别在各个逻辑集群1,2,3 上，由于数据分布问题 ，会在各集群间传输大量数据  ？   感觉做这个功能的目的有一些矛盾 。 【截图信息】【日志信息】（可选，上传日志内容或者附件）

GaussDB A 8.0.0.0    操作系统：CentOS 7.2针对8.0.0.0版本的GaussBD物理集群，漏洞CVE-2021-3156对集群是否有影响？是否可参考网络上的修复教程进行漏洞修复？还有如果可以升级CentOS的sudo至sudo-1.9.5p2版本的话，那升级之后是否影响集群后期的变更（升级/扩容/补丁）及集群的正常使用？漏洞详情：Linux Sudo 堆缓冲区溢出致本地提权漏洞（CVE-2021-3156|CNNVD-202101-2221）Sudo 是一个功能强大的实用程序，大多数基于Unix 和Linux的操作系统都包含Sudo。它允许用户使用其他用户的特权运行程序。监测发现Sudo堆存在缓冲区溢出致本地提权漏洞。攻击者通过利用该漏洞，可获得主机的root 权限。Linux Sudo 堆缓冲区溢出致本地提权漏洞（CVE-2021-3156|CNNVD-202101-2221）影响版本：Sudo 1.8.2 - 1.8.31p2Sudo 1.9.0 - 1.9.5p1我看针对漏洞，华为云已经给出了答复，针对物理集群什么时候可以答复？http://3ms.huawei.com/hi/group/2029719/wiki_6353720.html

sql特点是2-3张表left join，然后通过select查询结果，执行计划如下：排查当前的IO，内存，CPU使用情况，没有发现资源占用高的情况查看慢sql的线程等待状态select * from pg_thread_wait_status where query_id=’149181737656737395’;根据线程等待状态，并没有出现都在等待某个DN的情况，初步排除中间结果集偏斜到了同一个DN的情况。到相应的实例节点上，打印等待状态为none的线程堆栈信息如下：gstack 14104通过反复打印堆栈信息，发现堆栈在变化，并没有hang死，所以初步判断该问题未性能慢的问题，堆栈中有VecNestLoopRuntime，以及结合执行计划，初步判断是由于统计信息不准，优化器评估结果集较少，计划走了nestloop导致性能下降。对表执行analyze后性能并没有太大改善对sql增加hint关闭索引，让优化器强行走hashjoin，发现hint功能没有生效，原因是hint无法改变子查询中的计划通过set enable_indexscan = off;执行计划被改变，走了Hash Left Join，慢sql在3秒左右跑出结果，满足客户需求。

简单的大表过滤的SQL语句中有一个“in 常量”的过滤条件，常量的个数非常多(约有2000多个)，基表数据量比较大，SQL语句执行不出来。Select * from test where col in(a,b,c,d,XXXX,);执行计划：执行计划中，in条件还是作为普通的过滤条件存在。这种场景下，最优的执行计划应该是将“in 常量”转化为join操作性能更好。问题原因执行计划中，in条件还是作为普通的过滤条件存在。这种场景下，最优的执行计划应该是将“in 常量”转化为join操作性能更好。解决办法qrw_inlist2join_optmode可以控制把“in 常量”转join的行为。默认是cost_base的。如果优化器估算不准，可能会出现需要转化的场景没有做转化，导致性能较差。这种情况下可以通过设置qrw_inlist2join_optmode为rule_base来规避解决。

1、首先观察SQL语句中有not in 语法2、执行计划中有NestLoop3、NestLoop是导致语句性能慢的主要原因。Hashjoin只能做等值关联。NestLoop的条件中有or条件，所以无法用Hashjoin求解。导致出现这个现象的原因是由not in的语义决定的(具体可以baidu下not in 和 not exists的介绍)。4、因此上述语句可以通过修改将not in 修改为not exists就可以解决这个问题。

obs桶对象均已配置成功，数据库服务器和obs服务器均在同一地区         创建外表未报错，出现如下问题，原因？

【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

1、通过explain verbose打印语句执行计划2、上述执行计划中有__REMOTE关键字，这就表明当前的语句是不下推执行的。3、不下推语句在pg_log中会打印不下推的原因。上述语句在CN的日志中会找到类似以下的日志：4、不下推函数的场景主要出现在自定义函数属性定义错误的场景。5、审视用户自定义函数的provolatile属性是否定义正确。如果定义不正确，要修改对应的属性，使它能够下推执行。pg_proc 具体判断方法可以参考如下说明：函数相关的所有属性都在pg_proc这张系统表中可以查到。其中与函数能否下推相关的两个属性是provolatile 和proshippable。其中provolatile是继承自PG的字段，他的本质含义是描述函数是IMMUTABLE/STABLE/VOLATILE的。以上三个属性中只有IMMUTABLE支持下推，STABLE/VOLATILE不支持下推，如果自定义函数不下推需要调整属性为IMMUTABLE。

内存问题常用定位视图目前，GaussDB DWS对外提供诸多系统视图，可以用来辅助内存问题的分析定位，常用视图及用法说明如下表所示。（☆代表常用程度）pv_total_memory_detail ☆☆☆☆☆查询当前实例上整体内存使用状态和信息，可以看到各类型内存使用情况，来对当前实例上内存使用情况做一个概要的判断。SELECT * FROM pv_total_memory_detail;返回结果如下：表1 Memorytype中各类型含义名称描述max_process_memory实例可用最大内存阈值。由guc参数max_process_memory控制。process_used_memory实例当前已使用的内存值，从OS top命令RES列取得。如process_used_memory已经或马上要超过max_process_memory，说明当前内存使用已经超限，或马上就要超限。max_dynamic_memory实例可使用的最大动态内存dynamic_used_memory实例当前已使用的动态内存dynamic_peak_memory实例从启动后到目前为止的动态内存峰值dynamic_used_shrctx当前已使用的共享内存上下文内存量，也记录在dynamic_used_memory内dynamic_peak_shrctx共享内存上下文峰值。如减去sctpcomm_peak_memory后超过1G，说明共享内存没有释放，存在泄漏。max_shared_memory最大共享内存，主要为shared_bubffers。shared_used_memory实例当前已使用的共享内存，从OS top命令SHR列取得max_cstore_memory列存buffer可使用的最大内存，由guc参数cstore_buffers控制。cstore_used_memory实例当前已使用的列存buffer.max_sctpcomm_memory通信模块可使用的最大内存。sctpcomm_used_memory通信模块已使用的最大内存sctpcomm_peak_memory通信模块峰值内存other_used_memory其他内存占用，为OS  RES- dynamic_used_memory- shared_used_memory- cstore_used_memory后的值。一般为系统中不受memory context管理的第三方组件所占用的内存。如果过大，也有可能是内存泄漏。 pv_session_memory_detail ☆☆☆☆☆查看内存上下文级别的内存占用详细信息SELECT * FROM pv_session_memory_detail ORDER BY totalsize desc LIMIT 100;视图中各字段含义如下：名称类型描述sessidtext线程标识+线程启动时间。使用substr可以将线程号过滤出来，方便和上述其他视图进行关联。sesstypetext线程名称。contextnametext内存上下文名称。levelsmallint当前内存上下文的层级。parenttext父内存上下文名称。totalsizebigint当前内存上下文的内存总数，单位字节。指的是分配给当前内存上下文的内存总数，为freesize+usedsize之和。freesizebigint当前内存上下文中已释放的内存总数，单位字节。是指当前你内存上下文中预留的内存，只有这个内存上下文可以使用，其他线程及其他内存上下文都不能使用，实际还是当前内存上下文中占用的。usedsizebigint当前内存上下文中已使用的内存总数，单位字节。内存问题定位方法及解决措施Memory is temporary unavailable问题当出现memory is temporary unavailable报错后，首先确认是哪个实例报错，是CN还是DN。使用gsql登录到报错的实例上，查询pv_total_memory_detail，重点查看以下信息：当前是否还存在内存不足问题。方法为查看process_used_memory和max_process_memory的关系，如已经大于或比较接近，则说明当前内存使用已经或即将超限。如明显小于，则说明占用内存大的语句已经跑完或者被杀掉。当前系统已经恢复。这时可查看对应的peak_memory值，如peak_memory值过高，说明确实曾经出现过内存使用过大。当前是哪个类型的内存过大。最常见的是dynamic_used_memory过大，说明动态申请的内存过大，这类问题可能和客户正在运行的SQL强相关。如通过2发现当前内存占用仍过高，则进一步使用pv_session_memory_detail继续分析，看内存占用过高是哪个内存上下文引起的。视图中有线程号信息及内存上下文信息，通过这些信息可以判定是什么语句的什么操作占用了过多内存，进而可以cancel此语句，并给客户提出语句优化建议常见语句问题为：SQL不下推。如内存问题在CN上出现，很大程度上是因为某个SQL的不下推导致。通过explain确认语句不下推后，将语句进行修改使其下推。中间结果集倾斜。GaussDB DWS在进行表关联时，优先使用hash join，需要对一张表创建哈希表，当哈希表大小超过work_mem限制时，会进行下盘避免内存占用过多，但如果原始表里或中间结果集中在join列上存在大量重复数据，是无法下盘的，必须全部载入内存中进行计算，会造成内存大量占用。如pv_session_memory_detail中占用内存最大的内存上下文为hash context，则大概率是此问题。这时应对客户的表和SQL进行分析，对重复值进行处理后，再进行关联。如通过3没有发现内存占用过高的单个语句，但系统整体内存占用仍过高，则问题原因为参数配置不合理或用户语句并发设置不合理。局点上线后，或局点业务量增大后频繁报内存不足，很可能是因为max_active_statements设置过高，高并发的语句加起来后超出了系统可用内存上线，此时如检查第一点中参数都合理后，应将max_active_statements调小，让语句排序进行，避免一起运行时报错。局点新上业务后报内存不足，很可能是因为新业务较为复杂，有多个表join、sort或group by。此时如分析不存在中间结果集倾斜，则需要将并发调小，或将work_mem调小。以上操作都可能导致业务响应时间变长，需要和客户确认。max_process_memory设置过小，导致内存不能充分利用而提前报错。shared_buffer/cstore_buffer设置过大：shared_buffer设大可以增大缓存空间，提高数据读取效率，但如设置过大，会导致语句运行时无法申请到足够的动态内存，导致报错。work_mem/maintainence_work_mem设置过大：在高并发场景下，work_mem设置过大可能导致所有语句的work_mem加起来超过可用动态内存的最大值，从而导致报错。参数配置不合理。需评估系统关键内存参数是否设置合理。如用户将POC环境直接转为生产。POC环境为了追求极致性能，一般内存参数设置比较激进。而生产系统需要长期稳定运行，内存参数设置应相对保守，此时应调整相关参数。语句并发设置不合理。此问题与参数配置不合理问题相关。语句并发高，则内存参数配置应较小；反过来说，如内存参数配置较大，则可支撑的语句并发也就相应的要变低。如分析时已没有现场，则有3个方法来确认什么语句导致了问题。 到报错的节点日志中搜索全部memory is temporary unavailable报错，分析可能是哪个语句导致的。重新让客户运行业务，或等下次业务高峰期时进行分析。打开active sql。打开后会将内存相关信息记到系统表中。执行如下语句打开active sql开关来分析某一时间段并发量和单个sql执行使用的内存信息（如果enable_resource_track和enable_resource_record为off表示该功能关闭）。gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_track =on' ; gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_record =on' ;Active sql分析方法如下： 查询2018-11-9峰值内存使用top10的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' ORDER BY nodename,max_peak_memory DESC limit 10;查询2018-11-9CPU使用top10的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' ORDER BY nodename,total_cpu_time DESC limit 10;查询2018-11-9查询时间最长的top10的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' ORDER BY nodename,duration DESC limit 10;查询2018-11-9SQL执行失败，错误信息为“memory is temporarily unavailable”且最大峰值内存超过1G的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-1%' and status='aborted' and abort_info like '%memory is temporarily unavailable%' and max_peak_memory >1000 ORDER BY max_peak_memory desc;查询不下推的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' and query_plan like ‘%_REMOTE_TABLE_QUERY_ %’;查询不下盘的SQL。SELECT * FROM pgxc_wlm_session_info WHERE start_time like '%2018-11-9%' and warning like‘%spill%’;操作系统OOM问题查看/var/log/messages目录下的OS日志，搜索oom-killer，确认是否为gaussdb进程触发的OOM。分析数据库内存参数，确认设置是否合理，特别是max_process_memory。查看集群配置情况和关键参数常用语句集群每个物理节点内存、每个节点dn个数。SELECT sessid, contextname, level,parent,totalsize,freesize,usedsize,  datname,query_id  FROM pv_session_memory_detail a , pg_stat_activity b  WHERE  split_part(a.sessid,'.',2) = b.pid and b.state='active' ORDER BY usedsize desc limit 20 ;监控session total memory size占用最多的TOP20 session 。SELECT sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid  ORDER BY sum_total desc limit 20 ) a , pg_stat_activity b  WHERE  split_part(a.sessid,'.',2) = b.pid;监控session中占用内存最多的context TOP20 session。SELECT sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),  datname,query_id, query  from pv_session_memory_detail a , pg_stat_activity b  WHERE  split_part(a.sessid,'.',2) = b.pid  order by totalsize desc limit 20 ;监控当前实例总totalsize memroy大小。SELECT pg_size_pretty(sum(totalsize)) FROM pv_session_memory_detail;监控当前实例总usedsize memroy大小。SELECT pg_size_pretty(sum(usedsize)) FROM pv_session_memory_detail;监控当前实例内存总体使用情况。SELECT * FROM pg_total_memory_detail;监控共享内存实时使用情况。SELECT * FROM pg_shared_memory_detail;

【活动主题】来源: 【获奖名单公示~】免费学习大师课，打卡互动赢好礼~活动已结束本期免费学习大师课，13天带您get数仓全技能！学习打卡活动已经结束，感谢各位小伙伴的参与！获得本期活动奖励的名单如下，恭喜以下小伙伴~【获奖名单公示】请获奖小伙伴于2021年3月23日前私聊微信小助手（扫描下方二维码或者微信搜索“GaussDBDWS”添加），反馈您的收获信息，逾期礼品作废哦^_^ 奖项名称获奖用户（昵称）奖品学神奖千江有水千江月华为手环标兵奖真爱无敌华为mini蓝牙音箱勤奋奖谭涟漪华为云定制T-shirt勤奋奖bzhtoot华为云定制T-shirt勤奋奖Hello Digger华为云定制T-shirt没有中奖的小伙伴不要气馁，培训课程打卡活动第二期已经开始，欢迎大家前往参与互动哦>>【打卡互动赢大奖】DWS王者挑战赛【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT 【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【培训视频汇总】华为云数仓GaussDB(DWS) 培训视频汇总（持续更新中）扫码关注我哦，我在这里↓↓↓