a、在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。(跟击穿的第一个方案类似，但是这样是避免不了其它key去查数据库，只能减少查询的次数)b、可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存    不同的key，设置不同的过期时间，具体值可以根据业务决定，让缓存失效的时间点尽量均匀c、做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。(这种方式复杂点)

问题现象：db03节点故障导致集群不可用通过Xshell连接工具直接连接故障服务器，无法正常登录和执行命令；通过BMC界面执行linux相关命令都会报错，Too many open files in system，这个错误表明句柄数超出系统限制。应急措施：1、可以连到故障节点执行命令，可以通过命令停止故障节点的实例。omm 用户登录集群任一节点source $BIGDATA_HOME/mppdb/.mppdbgs_profilecm_ctl stop -n nodeid -mi   nodeid替换为对应节点编号。2、如果无法连接节点执行命令，可通过BMC重启异常节点服务器恢复。问题分析：文件句柄是打开文件的唯一识别依据，8月8日6:51日志中看到文件句柄数已达到上限，导致cm_agent出现读取不到gauss.state文件情况，cm_agent无法确认DN实例状态。10:24 cm_agent开始持续读取不到gauss.state文件。cm_agent检查DN连接，连接不上；检查DN存在，于是上报了unknown状态。10:25cm_sever上获取的db03主DN状态为unknown，对于unknown状态的DN cm_server不会进行仲裁，需要人为干预。问题原因：cm_server执行dn仲裁流程时，需要获取cm_agent上报的DN实例状态。cm_agent根据dn进程的情况判断其状态：(1) dn进程存在时，如果cm_agent可成功连接dn，则通过执行sql语句获取dn状态；如果cm_agent无法连接，则读取dn数据目录下的gaussdb.state文件获取dn状态。(2) dn进程不存在，直接上报dn为Down状态出现的dn无法仲裁的现象，对应上面第一种场景中，dn进程存在但无法连接的情况。但由于文件句柄异常，cm_agent读取gaussdb.state文件失败，导致无法正确判断dn所处的状态，因此上报Unknown状态（即未知状态）。综上分析，是因文件句柄数超限导致cm_agent无法读取DN实例状态，上报了DN unknown状态，cm_server因cm_agent上报的unknown状态无法做仲裁，备DN没有进行升主操作。

因为 cpu 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 cpu 又不会成为瓶颈，那就顺理成章地采用单线程的方案了。关于 Redis 的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。而且单线程并不代表就慢 nginx 和 nodejs 也都是高性能单线程的代表。

场景：某容器部署的程序经常偶发性消失，触发了健康检查重启。  发生时没有接收过任何请求，消失的时间时间也是毫无日志打印。 检查：给容器配置的内存是1个G然后容器内启动的web进程的jvm参数如下，可以看到最大堆内存为768M。按开发该服务部署业务的部门同事说， 这符合  1/4的配比。但是看监控几乎已经满了容器内执行free -g没什么效果，看不出内存不足的情况个人猜测是超出内存限制，导致进程被杀掉了所以没有任何日志留下。想问下 1G/ 768M的配比是不是有问题，   是的话有什么办法去确认和排查。

 1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。        2. 再说一下IO，Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。        3. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。        4. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。        5. 还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

我现在需要在MDC上跑一个目标检测和车道线检测模型，需要使用两个NPU单元，但是我没找到如何去指定NPU处理某个模型的文档，请问在那个文档或则教程有这块内容。

基本知识         MDC 610提供4x4摄像头接口。从左到右依次为A、B、C、D，每个block 左上左下右上右下，依次为1、2、3、4，共计四个camera插口。其中A1-A4、B1-B4、C1-C4、D1-D2是摄像头接口，即视频输入接口，D3和D4是HMI接口，即视频输出接口。最多接入14路camera。         MDC 610设备支持的摄像头类型及其性能规格详细参见《产品文档》->平台软件调测->平台软件调测指南->配置传感器->配置传感器抽象->配置摄像头->背景信息->摄像头类型。 定位手段一、查看摄像头数据流我们可以通过两种方式来看摄像头数据流是否正常1、cat/proc/umap/venc主要查看VENC STREAM STAT节的 FrameRate 列,其意义为每一路的帧率,要是所有通路的帧率都不为0则表示正常    2、使用rtfevent工具进行查看（注意rtfevent工具必须使用root权限）         使用以下指令rtfevent list | grep camera 可以列出所有摄像头抽象数据rtfevent hz xxx以上方式都无法查询到camera抽象数据则需要进行以下定位 二、确认配置正确1、首先确定配置文件"/opt/platform/mdc_platform/manual_service/camera_tool/conf"和实际摄像头接入方案是否一致（包括型号，数量、参数）2、确认配置加载工具(camera_tool)是否解析成功并下发到MDC设备上，配置解析下发过程中会对配置文件正确性进行检测并上报错误码（查看是否产生错误码）（错误码以及错误码对应的错误信息 详见于产品文档->平台软件调测->平台软件调测指南->配置传感器->配置传感器抽象->配置摄像头->背景信息->配置加载工具错误码信息）3、确认配置完成之后是否重启（下电或者reboot均可） 经过以上定位确认无误之后便可以确定是非配置问题，则需要进行以下方式定位三、日志分析确认以上步骤正确无误之后便可以进行一下定位（日志分析定位法），一般都通过清除下列路径下的camera相关日志，然后重启单板进行日志分析         主要分析以下两部分日志Camera日志Camera相关日志所在路径：/opt/log/aos_linux/platform_log/debug/如came_001_20200109234342.log解析后进行下列常见问题查询，解析命令如：mdc-tool log-convert came_001_20200109234342.log 常见错误信息    Camera日志 初始化失败出流失败常见问题示例问题一：某一camera模组初始化失败Venc情况：camera日志：原因：这种情况常见于配置文件与实际不匹配，亦可能是camera通路存在问题解决/处理方法：确认配置文件与摄像头接法是否一致（常见问题）确认camera通路是否正常，用万用表测量线缆是否有电，camera模组是否有温度如果是非1类问题，可通过逐个配置单个camera模组来找出有问题的模组，并进行相应替换 问题二：通过cat /proc/umap/venc查询camera帧率情况时仅最后的block有数据流，前三组block均无数据流这种情况一般是配置参数与单板不匹配导致的camera日志：初始化成功，出流失败 解决方法：进入到/opt/platform/mdc_platform/manual_service/camera_tool/conf/base目录下用common下的替换boardConf.json替换base目录下的boardConf.json文件，重新执行camera_tool该问题出现于013版本以前，后续对camera_tool加入了基于单板类型的配置文件自动适配，只需确认执行camera_tool就能实现正确的配置文件下发，无需替换boardConf.json文件。 问题三：camera进程无法自启动可能原因1：权限问题：/opt/platform/mdc_platform/conf/下的所有文件应为mdc权限解决方法：修改/opt/platform/mdc_platform/conf/下的所有文件权限：chown mdc:mdc ./* 问题四：Sample用例常见问题汇总Camera_mviz_sample:出现：上下位机通信建立失败解决方案  1、MDC配置文件中的ip设置错误，需要与上位机通道及ip一致：修改/opt/cfg/conf_run/viz/下的viz_address.conf文件，保证与rviz上的接收ip及端口号一致  2、是否是以虚拟机方式进行通信，此时需要同时修改虚拟机的设置。

部署了探针脚本，每10秒钟打印一次explain performance，观察语句的耗时情况，没有短查询高并发情况下，语句正常情况执行耗时100ms以内。前端高并发的场景，然后观察探针情况，发生了比较明显的劣化。单个语句劣化到10秒以上，其中协调节点（CN）到数据节点（DN）之间的建连耗时9.5秒。劣化原因：当前端当语句下发到协调节点（CN）上，由于执行操作都在数据节点（DN）上进行，协调节点（CN）和每个数据节点（DN）都要建立连接，协调节点（CN）会将连接请求下发给每个数据节点（DN）的PM线程，然后PM线程fork出一个子线程用来处理协调节点（CN）下发的语句，当系统处于高并发场景时，数据节点（DN）上的PM线程一直处于繁忙状态，无法及时响应协调节点（CN），导致建连时间变长。解决方案：1.把高并发短查询业务迁出到事务型数据库2.新上业务需要评估前端并发情况和语句类型，对于简单的点查并发，可以参考这个公式 点查并发数 =  (1000ms * (cpu core) / 50ms / 数据节点数)

【问题描述】某局点在配置完进程组之后所有的PG2服务器上模块起不来，但是PG0服务器上模块都是正常的。【使用版本】UAP9600 V100R005C00SPC005【可能原因】1.   MML脚本配置错误；2.   配置核数不正确；3.   PG2内部IP与NMU的加载IP不通；4.   后台加载模块有问题；5.   局点其他特殊原因；【定位过程】    步骤1：检查MML中关于进程组的配置ADD APP，此处该局点ADD APP没有问题；    步骤2：检查进程组的核数分配，服务器上分配的进程组核数之和不能大于实际服务器的逻辑核数，需要注意的是NMU与PMU合设情况下还需要算入给NMU分配的绑核数，此处该局点为分设情况，且PG2服务器实际32核只分配给进程组18核不存在超核情况；    步骤3：检查PG2的内部IP与NMU的加载IP网络互通情况，使用ping -I PMU内部IP NMU加载IP 命令长ping检查网络是否导通且是否有明显波动，其中PMU内部IP为问题服务器网卡上的172.0.节点号.33(或34.35.36…)IP，节点号通过CDE上 LST NODENET命令查出，NMU加载IP在混合模式部署下通过检查NMU网卡配置查出172.0.节点号.1，公有云模式部署下通过 LST NMUINNERIP命令查出load IP，该局点为公有云部署模式，长ping检查网络均正常；    步骤4：检查PG2的后台，执行ps –ef|grep tmp命令，检查进程文件是否都正常，如果全部正常说明与后台无关，如果有进程文件缺失，说明与后台的加载有关系，需要后台人员帮忙定位，该局点检查进程文件均正常；    步骤5：华为公有云服务器存在安全组设置策略问题，即使网络是导通的，但是PG2与NMU服务器不属于同一个安全组时，模块就会起不来，这也是为什么PG0能起来PG2起不来的原因，在一线将PG2的服务器安全组设置与NMU、PG0安全组设置相同后，执行RST SVR命令等待数分钟后，所有模块均被正常拉起。【解决方法】手动修改PG2服务器安全组设置策略与NMU、PG0相同后，RST SVR之后模块均被正常拉起。【问题根因】PMU服务器的安全组策略（可能跟防火墙类似）与NMU不同，导致即使网络导通NMU与PMU直接也不能正常通信。

1.    适用场景  当GaussDB A集群中Coordinator实例数量偏少时，可通过添加Coordinator实例来分担其它Coordinator实例的压力。  本方案仅适用于线下产品。2.    前提条件  添加Coordinator实例前，GaussDB A集群需处于“良好”状态。su - ommsource /opt/huawei/Bigdata/mppdb/.mppdbgs_profilecm_ctl query -Cv  2) 添加Coordinator前不能锁定GaussDB A集群。3) 一次仅允许添加一个Coordinator实例。 3.    注意事项1) 添加Coordinator前不能锁定GaussDB A集群。2) 一次仅允许添加一个Coordinator实例。3) 添加Coordinator实例需要在一个状态正常的物理节点上操作。4) 添加Coordinator实例操作不能与其它运维操作交叉执行。5) 在GaussDB A节点添加Coordinator实例需要提前创建好Coordinator实例相应目录。4.    对系统影响1) 增加CN过程中集群可以执行业务，特别说明：由于过程中会短暂锁集群，锁集群后用户下发的包含显式启动事务的DDL语句会出现等待，集群解锁后会报错或等待时间超过20分钟会报错。如包含创建临时表操作，在集群解锁后会报错（Don't support temp table when need reconnect pooler）。2) 增加、删除CN过程中系统将关闭“自动剔除故障CN”功能，在完成后系统再次打开该功能。5.    准备工作该部分工作可在增加CN操作开始前执行。5.1确认集群状态步骤1 按前提条件查询若balanced显示为No不影响增加CN操作。步骤2 如果不满足以上状态，则联系华为工程师处理。5.2检查正常CN目录是否正常步骤1 使用omm用户登录正常CN所在节点。步骤2 切换到CN目录下，检查是否有非omm用户文件。cd /srv/BigData/mppdb/data1/coordinator/ls -al红色斜体按CN具体所在目录替换步骤3 检查是否有不属于CN目录的超大文件（如core），如有移走。du -sh *移走超大文件，如无法确定该文件是否属于该目录，请及时联系华为工程师。5.3检查需添加CN的节点是否已有CN进程步骤1 登录需添加CN节点执行如下命令。ps -ef | grep coor | grep -v grep如无返回结果正常，否则kill -9 异常进程。5.4检查信号量是否不足步骤1 root用户登录需添加CN节点执行如下命令。cat /proc/sys/kernel/sem若结果为 250    6400000       1000      25600结束该检查否则执行 echo 250  6400000       1000      25600 > /proc/sys/kernel/sem5.5检查enable_stateless_pooler_reuse参数是否关闭8.0版本不涉及此问题，6.5.1版本需检查步骤1 使用omm用户登录任意数据节点，source Gauss环境变量，执行如下命令。su - ommsource /opt/huawei/Bigdata/mppdb/.mppdbgs_profilegs_guc check -Z coordinator -Z datanode -N all -I all -c "enable_stateless_pooler_reuse"步骤2 如显示enable_stateless_pooler_reuse=on 需关闭该参数并重启集群，显示enable_stateless_pooler_reuse=NULL或off跳过该项检查。gs_guc set -Z coordinator -Z datanode -N all -I all -c "enable_stateless_pooler_reuse=off"cm_ctl stop && cm_ctl start 6.  变更步骤6.1增加CN实例步骤1登录FusionInsight Manager系统，选择“集群 > 待操作的集群名称 > 服务 > MPPDB”。步骤2 单击“实例”，在实例列表中选择需添加CN节点对应的MPPDBServer。步骤3 单击“实例配置 > 全部配置”，在搜索框中输入参数名称“mppdb.coo.number”进行搜索。步骤4 将“mppdb.coo.number”的值设置为1，单击“保存”。步骤5 在弹出窗口中，单击“确定”。待界面提示“操作成功。”，单击“完成”，Coordinator实例添加成功。说明如果界面保存配置失败，需联系技术支持查找失败的原因，等待故障排除后，在界面将“mppdb.coo.number”的值改为1，单击“保存”，以确保和后台实际集群状态一致，再尝试执行步骤4&步骤5。 6.2更新lvs(如果有）步骤1 以root用户身份登录服务器，执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。步骤2 执行gs_loadbalance更新负载均衡配置。gs_loadbalance -t reload -U omm -X  ${BIGDATA_HOME}/FusionInsight_MPPDB_*/*_*_MPPDBServer/etc/mppdb-install-config.xml   --lvs-addr=10.146.156.101路径中红色斜体替换为实际版本路径参数说明-U：运行集群的操作系统用户名。必选。-X：集群配置文件。必选。--lvs-addr：后续供客户端连接的LVS IP地址。必选。 

1.    适用场景        DN状态异常（down）        CN处于deleted或down状态2.    前提条件1) GaussDB A集群安装成功，且处于已启动状态。2) DN环的主、备实例不能同时损坏，DN环的主、从备实例不能同时损坏，DN环的备、从备实例不能同时损坏，即一个DN环中只能损坏一个实例。3) GaussDB A集群内如下实例至少存在一个正常运行的：◾CMServer◾CMAgent◾GTM◾Coordinator4) 如果某个GTM实例存在故障，则要求实例修复前另外一个GTM实例必须为最高可用模式。3.    注意事项1) 操作要在正常节点执行，不能在被修复节点执行2) 在前一次修复结束后才能再次执行修复。2) 修复前不能锁定GaussDB A集群。3) 修复故障实例过程中系统将关闭“自动剔除故障CN”功能，完成后系统再次打开该功能。因此建议在开始修复前确认故障的CN已经被自动剔除（即故障的CN状态为Deleted），否则在修复过程中用户执行DDL会报错。4) 实例修复前用户手动在故障实例上配置的guc参数、pg_hba.conf配置的白名单会丢失，需要提前备份。5) gs_replace不涉及cn的，可以在线执行；gs_replace涉及cn的，8.0版本之前，必须离线执行；gs_replace涉及cn的，8.0版本之后，只要保证被修复的cn没有DDL业务即可4.    对系统影响由于过程中会短暂锁集群，锁集群后用户下发的包含显式启动事务的DDL语句会出现等待，集群解锁后会报错或等待时间超过20分钟会报错。如包含创建临时表操作，在集群解锁后会报错（Don't support temp table when need reconnect pooler）。5.    准备工作5.1检查集群状态步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，查看GaussDB A集群当前状态cm_ctl query -Cv查看具体故障实例所在节点：实例不是“Normal”状态，且持续5分钟没有自恢复[   Cluster State   ] cluster_state   : Degradedredistributing  : Nobalanced        : Yes [  Datanode State   ] node         instance state            | node         instance state            | node         instance state--------------------------------------------------------------------------------------------------------------------------1  redhat1-1 6001  P Down Disk damaged | 2  redhat1-2 6002     S Standby Normal | 3  redhat1-3 3002     R Secondary Normal1  redhat1-1 6003     P Primary Normal | 3  redhat1-3 6004     S Standby Normal | 2  redhat1-2 3003     R Secondary Normal2  redhat1-2 6005     P Primary Normal | 3  redhat1-3 6006     S Standby Normal | 1  redhat1-1 3004     R Secondary Normal2  redhat1-2 6007     P Primary Normal | 1  redhat1-1 6008     S Standby Normal | 3  redhat1-3 3005     R Secondary Normal3  redhat1-3 6009     P Primary Normal | 1  redhat1-1 6010     S Standby Normal | 2  redhat1-2 3006     R Secondary Normal3  redhat1-3 6011     P Primary Normal | 2  redhat1-2 6012     S Standby Normal | 1  redhat1-1 3007     R Secondary Normal步骤4以上查询结果为例，故障实例所在节点名称为redhat1-15.2关闭集群通信白名单（需要离线时做）注意：若被修复节点上没有cn，在没有IO压力的情况下可以在线操作。如果被修复节点有cn，则必须离线操作！步骤 1  现场实施人员知会并确认用户已完成数据库业务停止操作。步骤 2  以omm用户登录第一个正常的CN节点，执行如下命令注释用户白名单       以默认CN实例目录/srv/BigData/mppdb/data1/coordinator为示例，现场需根据实际情况进行调整。source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile  gs_ssh -c "hostname && if [ -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf ]; then cp -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf /srv/BigData/mppdb/data1/coordinator/pg_hba.conf_comment; fi "  gs_ssh -c "hostname && if [ -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf ]; then sed -i '/^[^#].*sha256.*/s/\(.*\)/#@#@#\1/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf; fi "  gs_ssh -c "hostname && if [ -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf ]; then sed -i '/^[^#].*md5.*/s/\(.*\)/#@#@#\1/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf; fi "步骤 3  以omm用户登录第一个正常的CN节点，关闭MPPDB实例节点下的后台访问连接和应用连接。具体操作如下：source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile gs_ssh -c "ps ux |grep -w gsql |grep -v grep |awk '{print \$2}' |xargs -r kill -9" gs_ssh -c "ps ux |grep -w ap_agent |grep -v grep |awk '{print \$2}' |xargs -r kill -9"步骤 4  以omm用户登录每一个正常CN节点，执行如下命令重启CN。执行以下命令，获取到CN的进程Pidps -ef | grep /srv/BigData/mppdb/data1/coordinator | grep -v grep执行以下命令，杀死CN进程kill -9 Pid执行以下命令，观察CN被重新拉起，并且Pid与之前获取的Pid不同ps -ef | grep /srv/BigData/mppdb/data1/coordinator | grep -v grep6.    变更步骤6.1清理残留文件步骤1 以omm用户登录被修复的节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 使用如下命令在需要修复实例的主机上清理可能存在的残留文件。此命令仅在上次修复故障实例执行失败的情况下需要执行。if [ -f $PGHOST/GaussReplace.dat ];then rm $PGHOST/GaussReplace.dat;fi 说明该文件为替换故障实例、替换主机中产生的用于记录执行步骤的临时文件，如果在上次执行过程中出现宕机或网卡中断等，可能会导致该文件残留。在替换故障实例前检查该文件是否存在，且生成时间非本次替换故障实例的时间，则可判断为上次执行的残留文件，删除该文件后，继续执行替换故障实例。6.2修改原cn目录名称（被修复节点有cn时做）步骤1 以omm用户登录需要被修复的节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 使用如下命令修改原cn目录名称，防止修失败回退后误拉起损坏的cn。mv /srv/BigData/mppdb/data1/coordinator /srv/BigData/mppdb/data1/coordinator_bak 6.3配置实例步骤1 以omm用户登录GaussDB A集群的健康节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，完成故障实例所在节点配置操作gs_replace -t config -h redhat1-1 说明配置操作会清理替换实例的空间，初始化替换实例，配置替换实例。如果收到提示：“GAUSS_50201: The XXX does not exist.”，则请检查对应的实例数据目录是否存在。如果不存在，请重新创建目录后再次执行上述命令。如果指定主机的表空间所在磁盘出现故障，从而导致表空间中的数据损坏，更换新磁盘后,需要指定“--force”参数对该主机强制进行表空间数据的恢复。如果在config阶段指定“--force”参数，则在start阶段也必须指定“--force”参数。6.4还原cn的白名单（被修复节点有cn时做）如果有配置lvs，每个cn的白名单相同，可跳过此小节。步骤1 以omm用户登录需要被修复的节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 使用如下命令将备份的白名单还原，操作前确认备份的白名单文件没有损坏。cp /srv/BigData/mppdb/data1/coordinator_bak/pg_hba.conf /srv/BigData/mppdb/data1/coordinator/ 6.5恢复集群通信白名单（需要离线时做）步骤1   以omm用户登录第一个正常的CN节点，执行如下命令注释用户白名单       以默认CN实例目录/srv/BigData/mppdb/data1/coordinator为示例，现场需根据实际情况进行调整。source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile  gs_ssh -c "hostname &&  sed -i '/^#@#@#.*/s/#@#@#\(.*\)/\1/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf && rm -f /srv/BigData/mppdb/data1/coordinator/pg_hba.conf_comment "6.6启动实例步骤1 以omm用户登录GaussDB A集群的健康节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，完成故障实例所在节点启动操作gs_replace -t start -h redhat1-1启动操作会启动集群替换实例的主机gs_replace -t start -h redhat1-1Starting.======================================================================Successfully started instance process. Waiting to become Normal.======================================================================.======================================================================Start succeeded on all nodes.Start succeeded.6.7重置实例参考主备均衡方案实施。cid:link_06.8更新lvs(被修复节点有cn时做)步骤1 以root用户身份登录服务器，执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。步骤2 在主备lvs节点和所有cn节点执行gs_loadbalance更新负载均衡配置。gs_loadbalance -t reload -U omm -X  ${BIGDATA_HOME}/FusionInsight_MPPDB_*/*_*_MPPDBServer/etc/mppdb-install-config.xml   --lvs-addr=10.146.156.101路径中红色斜体替换为实际版本路径参数说明-U：运行集群的操作系统用户名。必选。-X：集群配置文件。必选。--lvs-addr：后续供客户端连接的LVS IP地址。必选。7.    验证步骤7.1确认结果1)后台集群状态验证步骤1 以omm用户登录GaussDB A集群的第一个正常的cn节点步骤2 执行以下命令，启用环境变量source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile步骤3 执行以下命令，查看GaussDB A集群当前状态cm_ctl query如下则为正常[   Cluster State   ] cluster_state  :  Normalredistributing : Nobalanced       : Yes2)客户业务验证验证方案需包括DDL和DML语句

什么是多线程？　　在单片机上学习RT-Thread的多线程之前，要先把“进程”这个概念先放一边，因为单片机是没有多进程概念的。单片机运行操作系统，不管多少个任务，他们都是多个（或单个）线程之间进行处理这些任务，单片机一般不涉及多进程。　　什么是多线程？在哪些情况下要用到多线程？先来举一个音乐播放器的例子，这个音乐播放器要做以下这些基本的工作：读取音乐文件并播放、读取歌词并显示、读取MV文件并播放。　　如果这三个基本的工作不用多线程来完成，单片机使用裸机的方式去做这三个工作的话，必然会造成音乐播放卡顿，歌词显示不同步，MV视频播放与音乐不同步。　　因为单片机做这三件事情的时候，是Step by Step的，必须完成一件事情之后，再去做下一件事情，这三件事情是有先后顺序的，并且不断循环重复，如下图所示。　　而如果采用多线程这种方式来完成这个工作，这个过程就变得相对简单了，比如针对音乐播放器这个场景，可以设计这几个线程来处理：音乐文件读取线程，歌词文件读取线程，MV文件读取线程，音视频和歌词显示线程。　　（此处只为举例描述多线程的概念，不考虑音视频编解码的复杂过程，不考虑线程同步，实际上音乐播放器的实现比此处描述更复杂）　　音乐文件读取线程只负责从磁盘读取音乐文件，歌词文件读取线程和MV文件读取线程也是同样的道理，它们只做文件读取工作，而音视频和歌词显示线程，是负责把读取到的数据进行显示。这几个线程的工作过程，如下图所示。　　如上图所示，这几个任务看上去是“同时”进行的，每个任务都只完成自己的事情，通过多线程，就可以把原本串行完成的任务改为并行完成，大大提高了工作效率。　　所以，通俗地对多线程进行理解，就是把一个比较大型的任务，拆分为多个小型的任务，然后通过合理的调度方式，让这几个小型的任务“同时”运行，当这几个小型任务完成后，大型的任务也随之完成，这样可以大大提高任务的完成效率。多线程的几种状态　　对于运行RT-Thread操作系统，线程都处于以下五种状态的其中一种（初始状态、就绪状态、运行状态、挂起状态、关闭状态），通过调用操作系统提供的接口函数，可以让线程在这五种状态中进行来回切换。　　关于这五种线程状态的描述，如下表所示：多线程的API函数　　如上图的状态机所示，多线程可以通过调用系统提供的函数接口，在多个状态之间进行切换。这些API函数在官方提供的参考文档里面都有详细的说明描述，以下列举一些比较常用的函数接口。多线程的应用示例　　多线程的应用示例，主要是为了验证以上的多线程API接口函数，并且通过实验现象观察多线程的运行情况，主要有以下三个示例：　　示例源码下载链接：https://github.com/embediot/rtthread_study_notes1、线程动态创建与静态创建、线程退出示例。　　这个示例主要是通过动态方式创建线程1，,通过静态方式创建线程2，线程1的优先级比线程2的优先级低，因此可以被线程2抢占。线程2运行10次后就会主动退出，初始化代码如下图所示。2、相同优先级线程的时间片轮转调度示例。　　这个示例主要是通过动态方式创建线程1和线程2，这两个线程都是相同的优先级，并且共用一个线程入口函数，主要是通过传入不同的线程参数以区分线程1和线程2。线程2运行所占用的时间片比线程1要少，因此线程2运行的时间比较短，初始化代码如下图所示。3、线程调度器的钩子函数使用示例。　　这个示例主要测试了线程在进行调度时，关于钩子函数的调用情况。通过线程调度器的钩子函数，打印出线程间的切换信息，初始化的代码如下图所示。多线程应用的注意事项　　在使用RT-Thread实时操作系统进行多线程应用开发的时候，应该要注意以下事项：1、RT-Thread的线程调度器是抢占式的，也就是能够保证就绪队列里面，最高优先级的任务总能获得CPU的使用权，在任务设计的时候，要充分考虑好任务的优先级。2、在硬件中断服务程序运行期间，如果有高优先级的任务就绪，那么被中断的低优先级任务将被挂起，高优先级的任务将会获得CPU的使用权。3、每个线程都有独立的线程栈，用来保存线程调度时上下文的信息，因此在创建线程分配栈空间的时候，要充分考虑栈的大小。4、在线程的循环体里面，应该要设置某些条件，在必要的时候主动让出CPU的使用权，特别对于高优先级的线程，如果程序里面有死循环操作而又不主动让出CPU使用权，那么这个线程将会一直占用CPU，并且低优先级的线程永远不会被调度执行。5、对于没有一直循环执行的线程，线程执行完毕后，资源的回收情况实际上是在空闲线程里面进行的，线程变为关闭状态后，不代表资源马上被回收。6、系统空闲线程是最低优先级且永远为就绪状态的，空闲线程是一个死循环，永远不会被挂起，但可以被其他高优先级任务抢占，空闲线程主要执行僵尸线程的资源回收工作。7、空闲线程也可以设置钩子函数，用来进行功耗管理，看门狗喂狗等工作。8、通过动态方式创建的线程，需要设置好系统堆内存的大小，而通过静态方式创建的线程，线程栈和线程句柄在程序编译的时候就已经确定，不能被动态分配，也不能被释放。9、大多数线程都是在不断循环执行的，无需进行删除，一般不推荐主动删除线程。线程运行完毕后，系统调度器将会自动把线程加入僵尸队列，资源回收工作将在空闲线程里面进行。

关键字：         句柄不回收；空间不释放；deleted；磁盘满；磁盘使用率高；现象：         磁盘使用率高，df -h和du -sh查看数据目录，发现大小不同，差别很大。lsof查看发现有大量的文件处于deleted状态：这类文件分三种，按照下面命令可以统计这类不回收文件的数量1. base 目录下数据文件：lsof|grep deleted |grep base| wc -l2. pg_xlog目录下的xlog文件；lsof|grep deleted |grep pg_xlog| wc -l3. cm和om目录下的各种目录文件，这类文件句柄查出来有很多重复的，一般情况不用处理；通过lsof|grep deleted |grep '.log'| wc -l规避措施：1. base目录下数据文件和pg_xlog下xlog文件可以采用以下方法之一进行处理：方法一：kill dn实例。具体操作步骤如下：gsql 连接CN, 执行checkpoint；在空间不回收的实例上杀掉dn进程; 这里27620是上图中dn的进程号，实际操作请替换给对应的进程号：         kill -9 27620影响：kill DN实例会导致当前业务执行报错，请确认后操作;方法二：在线清理句柄。具体操作如下：连接CN执行checkpoint；连接CN清理每个库的空闲连接：        clean connection to all for database xxxx;这里xxxx是数据库名称，通过 \l 命令可以查看当前所有数据库。对每个库都做同样的清理。该动作知会清理idle连接，不影响业务。如果前面两步执行完，空间依旧不释放，说明可能存在长连接，连接空间不释放的实例，找出这些连接，全部杀掉即可。查询语句如下：select now()-query_start as ctime, * from pg_stat_activity where state='idle' order by ctime desc;杀语句方法：select pg_terminate_backend(pid) from pg_stat_activity where state='idle' order by ctime desc;2. cm和om日志，这部分使用空间不大，一般只有几十MB，可以不用处理。但是部分异常情况下，日志没有分割，导致占用空间比较大：规避措施分两步：查看om日志持续上涨的原因，这里27709是上图中的进程号，3是文件句柄：tailf /proc/27709/fd/3根据报信息找研发处理对应报错；清理存量数据cat /dev/null > /proc/27709/fd/3注释：该方法不会释放文件句柄，只是释放空间，并保证空间不会上涨。

【问题现象】通过iotop观察主OMS节点 stats collector 进程占用的IO非常高，导致该节点的性能下降。【规避办法】1. 切换到数据库用户，例如su - ommdba2. cd $GAUSSDATA3. vi postgresql.conf4. 文件末尾添加：stats_temp_directory='/dev/shm/pg_stat_tmp'5. 保存后退出6. 执行该命令令其生效：gs_ctl reload然后可以iotop 观察，可以明显看到io降下去了【原理说明】stats_temp_directory参数说明：设置存储临时统计数据的目录。参数类型：SIGHUP将其设置为一个基于RAM的文件系统目录会减少实际的I/O开销并可以提升其性能。

【问题现象】drop表的语句，hang住，无法执行。【问题分析】(1) 先通过这个语句查询pgxc_stat_activity，找到这个语句的query_id。select query_id from pgxc_stat_activity where query like '%drop table %';(2) 查找等待视图，发现这个语句在等DN上的锁。(3)连接到DN6075上，找到锁冲突的线程。select oid,* from pg_class where relname='表名'；select * from pg_locks where relation = 94747；(4) 连接到DN6075上,根据pid 找到冲突语句的query_idselect query_id from pg_stat_activity where pid  = 'xxxx';(5) 在CN上，创建下面的存储过程，根据query_id，批量的杀掉 各个DN上残留的线程。CREATE OR REPLACE PROCEDURE pgxc_terminate_query(IN queryId TEXT)AS    nodeName TEXT;    kpid TEXT;    query_str TEXT;BEGIN    FOR nodeName, kpid IN  SELECT node_name, tid  FROM  pgxc_thread_wait_status WHERE query_id = queryId LOOP        query_str  = 'EXECUTE DIRECT ON ('|| nodeName||') '' SELECT  PG_TERMINATE_BACKEND('''''||kpid||''''')'';';        --dbms_output.put_line(query_str);        EXECUTE query_str;    END LOOP;END;/select pgxc_terminate_query(query_id);注意： 如果通过上面的语句无法杀掉DN上残留的语句，可以先通过kill DN的方式进行规避。