问题现象：集群出现很多dn报内存不可用问题，导致大批作业中断。ERROR: dn_6217_6218 memory is temporarily unavailableDETAIL: Failed on request of size 54720 bytes under queryid 43341056.定位过程：1）分析内存视图pv_total_memory_detail，发现动态使用内存最大值dynamic_peak_memory 10675MB， 大于 max_dynamic_memory 10499,因此出现内存不足问题。2）动态内存主要有session使用的动态内存、多线程共享的动态内存和通信库使用内存组成     其中多线程共享的动态内存峰值 dynamic_peak_shrctx 926MB、通信库使用的内存峰值sctpcomm_peak_memory 801MB，而总的动态内存dynamic_peak_memory 10675MB，分析可知动态内存中主要由session占用达8948MB。 3）查看pv_session_memory_detail视图     select split_part(pv_session_memory_detail.sessid,'.',2),sum(totalsize),count(*) from pv_session_memory_detail group by split_part(pv_session_memory_detail.sessid,'.',2) order by sum(totalsize) desc;     查询后发现进程中存在千余session，单session使用内存最大不足900MB，但因session总量大，客户业务正在运行，使得占用的总值高。     查看dn /proc/pid/status信息，确认进程中含有1059线程，与pv_session_memory_detail相符。4）查看idle线程数量SELECT count(*) FROM pg_stat_activity WHERE state=’idle’;返回结果700+5）结论Dn中总共1000余线程，idle线程700+，idle线程过多，虽然有利于连接复用，但会持有过多资源。应急措施：清理idle线程。gsql -d postgres -p 25308 -c "clean connection to all for database xxx;"清理后，查看结果SELECT count(*) FROM pg_stat_activity WHERE state=’idle’;返回结果0查看pv_total_memory_detail视图，dynamic_used_memory 2G+，大幅下降。

【集群版本】GaussDB A 6.5.1【问题描述】集群重启后，备cm_server 进程down，cms无法启动【机制说明】cm_server进程的启动是由cm_agent拉起，在cm_server的listen端口被占用时cm_agent会等待端口占用解除后自动拉起恢复；cm_server简称cms；cm_agent简称cma；【问题分析】1. 用户进行的DN guc参数修改，用户执行重启集群操作，发现集群有告警，集群有cms down现象2. 分析当前节点cma的日志发现，cm_server进程需要listen 的端口号被占用，导致无法拉起，日志如下：StartAndStop WARNING: port:25302 already in use. /proc/net/tcp:  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode  14: 7C04240B:62D6 00000000:0000 0A 00000000:00000801 02:00000011 00000000  2000        0 197292192 2 ffff88017c952580 100 0 0 10 03. 进一步分析，发现是gs_check占用了此listen端口，通过kill掉gs_check进程，cm_server进程顺利恢复 netstat -anpo| grep 25302 kill -9  23666 kill后cms恢复正常。【问题根因】cms的进程listen端口被其他进程占用，导致cms无法被拉起【触发条件】gs_check等其他进程占用cm_server listen端口时会触发。【恢复方案】kill 占用cm_server listen端口占用进程恢复cms进程。

本文主要介绍使用Python调用ADB命令实现实时监控logcat关键字的功能采用多进程，可同时监控多个设备，监控多个关键字。 需要配置ADB环境，具体配置就不多介绍，随便搜一下一大把，直接上代码通过一个全局变量控制开启和关闭监控功能, INSTRUCTION 用于根据指令获取对应的方法名import os, threading, datetime# 获取当前文件所在目录，拼接出LOG路径LOG_PATH = os.path.join(os.path.dirname(os.path.abspath(__file__)), "log")# 配置需要监控的关键字KEYWORDS = ["ANR ", "NullPointerException", "CRASH", "Force Closed"]# 控制开启和关闭STOP_LOGCAT = True# 指令对应具体操作INSTRUCTION = {"1": "filter_keywords","2": "stop_filter_keywords","3": "exit"}def filter_keywords():global STOP_LOGCATSTOP_LOGCAT = Falsedevices = get_devices()  # 先获取所有连接的设备print("开始监控关键字")for device in devices:t = threading.Thread(target=filter_keyword, args=(device,))t.start()def stop_filter_keywords():global STOP_LOGCATif STOP_LOGCAT:print("没有正在执行的任务\n")else:STOP_LOGCAT = Trueprint("正在停止关键字监控\n")监控关键字主函数，def filter_keyword(device):print("设备%s关键字监控已开启" % str(device))sub = logcat(device)with sub:for line in sub.stdout: # 子进程会持续输出日志，对子进程对象.stdout进行循环读取for key in KEYWORDS:if line.decode("utf-8").find(key) != -1: # stdout输出为字节类型，需要转码message = "设备：%s 检测到：%s\n" % (device, key)# 设备：192.168.56.104:5555 检测到：ANRpath = get_log_path("bugreport") # 根据时间创建文件夹bugreport(device, path)# 拉取完整日志压缩包到创建的文件夹内send_message(message) # 这里可以换成自己要做的事情，比如发送邮件或钉钉通知if STOP_LOGCAT:breakprint("设备%s关键字监控已停止" % str(device))sub.kill()  通过 subprocess.Popen 创建进程执行命令，持续输出日志到 stdout# logcat持续输出日志def logcat(device):command = "adb -s " + str(device) + " logcat -v time"sub = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)return sub获取所有已连接设备的方法，执行"adb devices"后输出如下，通过对命令执行拿到的字符串切割获取所有设备号以列表方式存储# 获取所有devicedef get_devices():command = "adb devices"res = os.popen(command).read()devices = []res = res.split("\n")for i in res:if i.endswith("device"):devices.append(i.split('\t')[0])return devices# 打包下载所有日志到当前目录def bugreport(device, path):os.chdir(path)# bugreport会下载日志到当前文件夹，所以需要先切换到已经创建的目录command = "adb -s " + str(device) + " bugreport"subprocess.Popen(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=-1)print("设备：%s 日志路径：%s" % (str(device), path))以  当前文件所在目录/年/月/日 格式获取日志路径，如果不存在自动创建# 获取日志存放路径，如果不存在则按日期创建def get_log_path(tag):year = datetime.datetime.now().strftime('%Y')month = datetime.datetime.now().strftime('%m')day = datetime.datetime.now().strftime('%d')path = os.path.join(LOG_PATH, tag, year, month, day)if not os.path.exists(path):os.makedirs(path)return path main函数，循环接收指令，根据接收的指令拿到方法名，并通过eval()方法执行。def main():while True:print("-" * 100)print("1：开启关键字监控\n2：停止关键字监控\n3：退出")print("-" * 100)instruction = str(input("\n\n请输入要进行的操作号：\n"))print("-" * 100)while instruction not in INSTRUCTION.keys():instruction = str(input("\n\n输入无效，请重新输入:"))if int(instruction) == 9:exit()  # TODO 退出前需要判断是否有正在执行的monkey任务和关键字监控任务eval(INSTRUCTION[str(instruction)] + "()")if __name__ == '__main__':main()代码分段之后有点凌乱，看不明白可以把代码复制到一个文件里捋一下就明白了这里只写了开启日志监控和关闭的方法，中间有些处理可以根据自己需要实现，比如检测到关键字之后除了拉取所有日志外，可以发送邮件、钉钉之类的通知，根据自己需要去实现。原创不易，感觉本文有用可以点个赞，谢谢！

节点文件描述符耗尽可能引起GaussDB实例重启造成集群不可用，本文主要讨论如何快速恢复集群以及后续如何预防。以下图为例，文件由于文件描述符耗尽导致实例异常状态如下：前提：如何确定实例异常是由于文件描述符耗尽影响的呢？可以查看主dn对应日志是否有以下日志出现，如上图所示对应为6045为主实例（对端实例6046目前状态为standby promoting状态能够说明该实例故障之前为备实例，那么6045肯定为主实例）有以上日志出现可以继续按照以下步骤进行修复。1、集群现场修复：方案一：1）查看从备日志是否有以下报错：2）此场景下一般是由于从备wal槽位残留造成备机升主时连接从备失败，此时登录从备实例所在节点kill该实例即可。方案二：方案一修复失败的话可以考虑使用该方案1）确认从备实例pg_xlog与base/dummy_standby/是为空，若不为空的话可以手动将其移动到其他路径（该场景下基本都为空）2）手动停止处于standby promoting的实例：cm_ctl stop -n nodeId -D 实例目录3）kill原主实例（实例状态为need repair）,登录该实例所在节点执行以下命令，让其升主：kill pid; sleep 4; gs_ctl notify -M primary -D2、文件描述符耗尽预防：1）查看并修改文件描述符大小（集群内每台机器都需要修改，防止其他节点也出现该问题）    cat /etc/sysctl.conf |grep file-max    fs.file-max = 65536002）定期观察文件描述符使用情况：    查看机器整体文件描述符使用情况：lsof -u omm|grep urandom| wc -l    查看具体进程文件描述符使用情况：lsof -p pid|grep urandom| wc -l （pid 通过ps -ux查看，只关注gaussdb进程即可）3）若监控到文件描述符使用达到90%左右在业务低峰期可以考虑手动kill该进程释放资源。

    GaussDB(DWS)可以支持很大并发的连接数量同时连接，有时候会出现资源利用率过高，节点上cpu使用率飙升的情况，本次介绍一种情况，当连接数过多的时候，可能有一个进程导致单个cn节点cpu高。【判断问题】    1.CPU使用率单节点很高。    2.当前是不是cn：    ps -ef | grep coo    如果有进程，那么就是cn    3.为什么CPU高：top 看是否有大量getClientInfo进程，有的话直接走到处理步骤【处理问题】在CPU高的节点执行：ps -ef | grep getClientInfo | awk '{print $2}' | xargs kill -9ps -ef | grep getClientInfo，找到对应文件路径，修改其中main函数为直接return.

2020-08-29：进程线程的区别，除了包含关系之外的一些区别，底层详细信息？

【鲲鹏数据库】【操作步骤&问题现象】1、ps -ef | grep mysql缺失下面两个进程2、/usr/local/mysql/bin/mysql -uroot -p -S /tmp/mysql.sock【截图信息】【日志信息】（可选，上传日志内容或者附件）

我们目前在开发过程中，device侧常偶发调用DVPP接口(eg: DvppCtl ， HIAI_DVPP_DMalloc)失败，reason为"no memory"，所以在考虑优化graph结构来改善内存分配及利用效率。目前我们项目中，存在几个类似如下的Graph结构，下面说一下我的怀疑点以及我的改进想法，想请你帮忙评估一下我的想法是否正确目前我们Graph的结构，基本都是这种5层结构，SrcEngine --> PreProcessEngine -->InferenceEngine --> PostEngien --> DstEngine1. SrcEngine会发送相同的数据给所有 PreProcessEngine，走不同细类属性分支做不同细类属性分析，后续Engine中处理过程中，原始输入的数据为只读不做修改--> 这里我的想法，是不是每个PreProcess 都保存一份数据，导致系统内部数据量扩大了 N倍 ?假如在device侧增加一层 DeviceSrcEngine(介于 SrcEngine 和 PreEngine之间)，这样后面所有Engine都只访问同一个地址的device侧的原始数据，实现节省device侧内存效果2. 参照高性能应用编程手册，--> 这里我的想法，我们graph结构图中是不是应该把 PostEngine改到Device侧，避免 InferenceEngine直接往host发送数据？3. 此外，我们目前一个进程使用一个chip，但在这一个chip上会同时创建并运行多个(目前为6个)不同功能的Graph(结构类似)，是不是将所有Graph合并为一个Graph也会对device侧内存有改善？改善会很明显吗？(了解到 你们提供的profiler工具只适用一个chip对应一个进程一个Graph的场景，所以有想法把多个Graph合并为一个)如果还有其他改善意见想法，也请指导一下，感谢 ：）

【功能模块】Atlas200dk 【操作步骤&问题现象】1、改写Atlas200dk yolov3例子,使用多线程同时推理多张图片,2、代码报错,错误码显示是单线程没问题,多线程一跑就报错,有使用所线程案例可以参考下么【截图信息】日志信息截图如下【日志信息】（可选，上传日志内容或者附件）

问题描述gaussdb进程持续占CPU过高，需找到占用CPU过高的sql语句问题处理找一个gaussdb进程，确认进程号和对应dn的端口号（进程号32089）执行ps H -eo pid,tid,pcpu | sort -n -k 3 | grep 32089，可以查到进程内各个线程占用CPU的情况最后几条结果如下：32089    48369    81.932089    41335    82.332089    10596    85.6连续执行多次，发现占用CPU高的线程没有变过连接到此dn（注意端口号搞对）select query_id from pg_thread_wait_status where lwtid = 10596;查到query_id 为95174458select * from pg_stat_activity where query_id = 95174458;即可查到对应语句和客户业务侧确认，该语句是临时新增业务，不是跑批业务，杀掉该语句进行规避，业务侧进行语句优化或者业务流程调整

【功能模块】【操作步骤&问题现象】1、运行mindstudio.sh脚本，mindstudio软件并没有打开。2、查看进程ps -ef|grep idea，有看到对应的进程，但是没看到界面。

【功能模块】C#多线程调用OCR通用文字识别，通过Token请求【操作步骤&问题现象】1、C#多线程调用API，连续执行到第四五十次的时候会抛异常，异常信息：操作超时。2、设置System.Net.ServicePointManager.DefaultConnectionLimit的值大于4之后，在GetResponse()的位置抛异常。异常信息远程服务器返回错误：（429）Too Many Requests。【截图信息】【日志信息】（可选，上传日志内容或者附件）

【问题影响】vAG服务不可用，用户无法通过自助维护平台进行维护，不能在WI界面上查看用户计算机的启动过程。【可能原因】IP地址存在冲突。IP发生变化，该IP产生的告警需要手工清除。vAG服务器没有正常运行。网络问题。【处理步骤】1、使用管理员帐号登录产生告警的服务器，运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否有IP冲突。是，执行步骤 2。否，执行步骤 4。返回信息类似如下所示，则无IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Sent 3 probes (3 broadcast(s)) Received 0 response(s) （注：以上IP仅为举例，应以实际IP为准）     返回信息类似如下所示，则存在IP冲突。ARPING 192.168.162.11 from 0.0.0.0 eth0 Unicast reply from 192.168.162.11 [12:6E:D4:AB:CD:EF]  1.022ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) （注：以上IP和MAC地址仅为举例，应以实际IP和MAC为准）    2、登录造成IP冲突的机器，关闭该机器或更换其IP。在产生告警的服务器上再次运行arping -c 3 -f -D -I eth0 产生告警的服务器IP，查看是否还存在IP冲突。是，联系技术支持处理。否，执行步骤 3。3、在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 4。否，处理完毕。4、使用gandalf帐号登录ITA服务器，查看与vAG服务器的网络是否正常。输入ping -c 3 vAG服务器的业务IP，查看通信是否正常。是，执行步骤 7。否，执行步骤 5。返回信息类似如下所示，则通信正常。PING 192.168.190.2 (192.168.190.2) 56(84) bytes of data. 64 bytes from 192.168.190.2: icmp_seq=1 ttl=64 time=0.047 ms 64 bytes from 192.168.190.2: icmp_seq=2 ttl=64 time=0.057 ms 64 bytes from 192.168.190.2: icmp_seq=3 ttl=64 time=0.058 ms （注：以上IP仅为举例，应以实际IP为准）     5、根据现场具体情况定位和排除网络故障。6、等待5分钟后，在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，执行步骤 7。否，处理完毕。7、重启vAG服务。使用gandalf帐号登录vAG服务器。执行命令pkill -9 vncgate结束vncgate进程，vncgate进程会被HA进程拉起。8、执行命令ps -ef | grep vncgate，查看进程是否已正常运行？是，执行步骤 9。否，联系技术支持处理。9、等待5分钟，在“FusionAccess > 监控 > 告警”上查看告警是否还存在？是，联系技术支持处理。否，处理完毕。

起集群发生备DN启动失败，DN日志内容包含 Address already in use字段，且提示出明确的端口号。定位步骤：1. 查找日志中提示的冲突端口号，例：备DN端口号25152（同时确认IP是否合法且未被占用）。2. 执行命令：netstat -anop|grep 25152 查找占用该端口号的进程PID。3. 执行ps ux | grep 10213，利用PID找到该进程。4. 分析占用进程内容。例：进程为主DN，且查找主DN的postgresql.conf文件，发现主DN和备DN都使用了25152端口。解决方案：确认该进程无需继续使用，则kill掉占用端口号的进程。否则修改备DN的postgresql.conf文件，更换冲突的端口号为未被占用的端口号。