【问题现象】GaussDB A 8.0.0.5当前针对集群节点是suse 12 sp3版本的操作系统直接安装LVS会报版本不支持。查看LVS支持的操作系统来看又说是支持该版本的。查看部署负载均衡章节说LVS部署就是将IPVS模块加到内核中，而在x86平台下，SUSE 11 sp1/sp2/sp3/sp4和SUSE 12 sp0/sp1/sp2/sp3内核中是不带ipvs模块的。针对现在的情况想知道：SUSE 12 SP3是否真的支持安装部署LVS。如果是支持的话，那就是说需要安装ipvs模块，那这个ipvs模块又该如何获取？

【功能模块】我们的ODS项目建立在gaussdb上，挡墙碰到一个性能问题：每半小时通过外表从hadoop同步数据到gaussdb 内表，再将内表的数据取最新变化数据插入到 列存的内部表，插入3000条数据，需要耗时30秒以上。这只是其中一张表的情况，大概同步了300张，差不多都是这个性能情况。如果改用行存表，插入会变快，但是会极大拖慢后续的跑批处理，而且因为是ODS项目，会频繁查询和统计贴源表。集群为：2个manager+6个数据节点。所以，请教各位老师的问题是：这个性能是否合理？有什么调优办法吗？【截图信息】

【操作步骤&问题现象】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。