Linux开发中，命令行操作可是必不可少的技能，简单便捷的操作，比图形界面操作要优雅许多，也是事半功倍，感觉用到什么去学就行了，不用刻意去学习，那现在来看看有哪些常用命令吧。一.文件和目录cd命令，用于切换当前目录，它的参数是要切换到的目录的路径，可以是绝对路径，也可以是相对路径。cd /home    进入 '/ home' 目录cd ..            返回上一级目录 cd ../..         返回上两级目录 cd               进入个人的主目录 cd ~user1   进入个人的主目录 cd -             返回上次所在的目录pwd命令，显示工作路径[root@mailvip ~]# pwd/rootls命令，查看文件与目录的命令，list之意ls 查看目录中的文件 ls -l 显示文件和目录的详细资料 ls -a 列出全部文件，包含隐藏文件ls -R 连同子目录的内容一起列出（递归列出），等于该目录下的所有文件都会显示出来  ls [0-9] 显示包含数字的文件名和目录名cp命令，用于复制文件，copy之意，它还可以把多个文件一次性地复制到一个目录下-a ：将文件的特性一起复制-p ：连同文件的属性一起复制，而非使用默认方式，与-a相似，常用于备份-i ：若目标文件已经存在时，在覆盖时会先询问操作的进行-r ：递归持续复制，用于目录的复制行为 //经常使用递归复制-u ：目标文件与源文件有差异时才会复制mv命令，用于移动文件、目录或更名，move之意-f ：force强制的意思，如果目标文件已经存在，不会询问而直接覆盖-i ：若目标文件已经存在，就会询问是否覆盖-u ：若目标文件已经存在，且比目标文件新，才会更新rm命令，用于删除文件或目录，remove之意-f ：就是force的意思，忽略不存在的文件，不会出现警告消息-i ：互动模式，在删除前会询问用户是否操作-r ：递归删除，最常用于目录删除，它是一个非常危险的参数二、查看文件内容cat命令，用于查看文本文件的内容，后接要查看的文件名，通常可用管道与more和less一起使用cat file1 从第一个字节开始正向查看文件的内容 tac file1 从最后一行开始反向查看一个文件的内容 cat -n file1 标示文件的行数 more file1 查看一个长文件的内容 head -n 2 file1 查看一个文件的前两行 tail -n 2 file1 查看一个文件的最后两行 tail -n +1000 file1  从1000行开始显示，显示1000行以后的cat filename | head -n 3000 | tail -n +1000  显示1000行到3000行cat filename | tail -n +3000 | head -n 1000  从第3000行开始，显示1000(即显示3000~3999行)三.文件搜索find命令，用来查找系统的find / -name file1 从 '/' 开始进入根文件系统搜索文件和目录 find / -user user1 搜索属于用户 'user1' 的文件和目录 find /usr/bin -type f -atime +100 搜索在过去100天内未被使用过的执行文件 find /usr/bin -type f -mtime -10 搜索在10天内被创建或者修改过的文件 whereis halt 显示一个二进制文件、源码或man的位置 which halt 显示一个二进制文件或可执行文件的完整路径删除大于50M的文件：find /var/mail/ -size +50M -exec rm {} ＼;四.文件的权限 - 使用 "+" 设置权限，使用 "-" 用于取消chmod命令，改变文件/文件夹权限ls -lh 显示权限 chmod ugo+rwx directory1 设置目录的所有人(u)、群组(g)以及其他人(o)以读（r，4 ）、写(w，2)和执行(x，1)的权限 chmod go-rwx directory1  删除群组(g)与其他人(o)对目录的读写执行权限chown命令，改变文件的所有者chown user1 file1 改变一个文件的所有人属性 chown -R user1 directory1 改变一个目录的所有人属性并同时改变改该目录下所有文件的属性 chown user1:group1 file1 改变一个文件的所有人和群组属性11.chgrp命令，改变文件所属用户组chgrp group1 file1 改变文件的群组五.文本处理grep命令，分析一行的信息，若当中有我们所需要的信息，就将该行显示出来，该命令通常与管道命令一起使用，用于对一些命令的输出进行筛选加工等等grep Aug /var/log/messages  在文件 '/var/log/messages'中查找关键词"Aug" grep ^Aug /var/log/messages 在文件 '/var/log/messages'中查找以"Aug"开始的词汇 grep [0-9]  /var/log/messages 选择 '/var/log/messages' 文件中所有包含数字的行 grep Aug -R /var/log/* 在目录 '/var/log' 及随后的目录中搜索字符串"Aug" sed 's/stringa1/stringa2/g' example.txt 将example.txt文件中的 "string1" 替换成 "string2" sed '/^$/d' example.txt 从example.txt文件中删除所有空白行paste命令paste file1 file2 合并两个文件或两栏的内容 paste -d '+' file1 file2 合并两个文件或两栏的内容，中间用"+"区分sort命令sort file1 file2 排序两个文件的内容 sort file1 file2 | uniq 取出两个文件的并集(重复的行只保留一份) sort file1 file2 | uniq -u 删除交集，留下其他的行 sort file1 file2 | uniq -d 取出两个文件的交集(只留下同时存在于两个文件中的文件)comm命令comm -1 file1 file2 比较两个文件的内容只删除 'file1' 所包含的内容 comm -2 file1 file2 比较两个文件的内容只删除 'file2' 所包含的内容 comm -3 file1 file2 比较两个文件的内容只删除两个文件共有的部分六、打包和压缩文件tar命令，对文件进行打包，默认情况并不会压缩，如果指定了相应的参数，它还会调用相应的压缩程序（如gzip和bzip等）进行压缩和解压-c ：新建打包文件-t ：查看打包文件的内容含有哪些文件名-x ：解打包或解压缩的功能，可以搭配-C（大写）指定解压的目录，注意-c,-t,-x不能同时出现在同一条命令中-j ：通过bzip2的支持进行压缩/解压缩-z ：通过gzip的支持进行压缩/解压缩-v ：在压缩/解压缩过程中，将正在处理的文件名显示出来-f filename ：filename为要处理的文件-C dir ：指定压缩/解压缩的目录dir压缩：tar -jcv -f filename.tar.bz2 要被处理的文件或目录名称 查询：tar -jtv -f filename.tar.bz2 解压：tar -jxv -f filename.tar.bz2 -C 欲解压缩的目录bunzip2 file1.bz2 解压一个叫做 'file1.bz2'的文件 bzip2 file1 压缩一个叫做 'file1' 的文件 gunzip file1.gz 解压一个叫做 'file1.gz'的文件 gzip file1 压缩一个叫做 'file1'的文件 gzip -9 file1 最大程度压缩 rar a file1.rar test_file 创建一个叫做 'file1.rar' 的包 rar a file1.rar file1 file2 dir1 同时压缩 'file1', 'file2' 以及目录 'dir1' rar x file1.rar 解压rar包zip file1.zip file1 创建一个zip格式的压缩包 unzip file1.zip 解压一个zip格式压缩包 zip -r file1.zip file1 file2 dir1 将几个文件和目录同时压缩成一个zip格式的压缩包七.系统和关机（关机、重启和登出）shutdown -h now 关闭系统(1) init 0 关闭系统(2) telinit 0 关闭系统(3) shutdown -h hours:minutes & 按预定时间关闭系统 shutdown -c 取消按预定时间关闭系统 shutdown -r now 重启(1) reboot 重启(2) logout 注销 time 测算一个命令（即程序）的执行时间 八、进程相关的命令jps命令，显示当前系统的java进程情况，及其id号jps(Java Virtual Machine Process Status Tool)是JDK 1.5提供的一个显示当前所有java进程pid的命令，简单实用，非常适合在linux/unix平台上简单察看当前java进程的一些简单情况。ps命令，用于将某个时间点的进程运行情况选取下来并输出，process之意-A ：所有的进程均显示出来-a ：不与terminal有关的所有进程-u ：有效用户的相关进程-x ：一般与a参数一起使用，可列出较完整的信息-l ：较长，较详细地将PID的信息列出ps aux # 查看系统所有的进程数据ps ax # 查看不与terminal有关的所有进程ps -lA # 查看系统所有的进程数据ps axjf # 查看连同一部分进程树状态kill命令,用于向某个工作（%jobnumber）或者是某个PID（数字）传送一个信号，它通常与ps和jobs命令一起使用命令格式 : kill[命令参数][进程id]命令参数:-l  信号，若果不加信号的编号参数，则使用“-l”参数会列出全部的信号名称-a  当处理当前进程时，不限制命令名和进程号的对应关系-p  指定kill 命令只打印相关进程的进程号，而不发送任何信号-s  指定发送信号-u  指定用户实例1：列出所有信号名称 命令：kill -l 输出：[root@localhost test6]# kill -l 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL 5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE 9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR213) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGSTKFLT17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU25) SIGXFSZ     26) SIGVTALRM   27) SIGPROF     28) SIGWINCH29) SIGIO       30) SIGPWR      31) SIGSYS      34) SIGRTMIN35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3  38) SIGRTMIN+439) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+843) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+1247) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-1451) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-1055) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7  58) SIGRTMAX-659) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-263) SIGRTMAX-1  64) SIGRTMAX说明：只有第9种信号(SIGKILL)才可以无条件终止进程，其他信号进程都有权利忽略。   下面是常用的信号：HUP    1    终端断线INT     2    中断（同 Ctrl + C）QUIT    3    退出（同 Ctrl + \）TERM   15    终止KILL    9    强制终止CONT   18    继续（与STOP相反， fg/bg命令）STOP    19    暂停（同 Ctrl + Z）实例2：得到指定信号的数值[root@localhost test6]# kill -l KILL[root@localhost test6]# kill -l SIGKILL[root@localhost test6]# kill -l TERM[root@localhost test6]# kill -l SIGTERM[root@localhost test6]#实例3：先用ps查找进程，然后用kill杀掉命令：kill 3268[root@localhost test6]# ps -ef|grep vim root      3268  2884  0 16:21 pts/1    00:00:00 vim install.logroot      3370  2822  0 16:21 pts/0    00:00:00 grep vim[root@localhost test6]# kill 3268 实例4：彻底杀死进程命令：kill –9 3268   // -9 强制杀掉进程killall命令，向一个命令启动的进程发送一个信号，用于杀死指定名字的进程命令格式 : killall[命令参数][进程名]命令参数：-Z 只杀死拥有scontext 的进程-e 要求匹配进程名称-I 忽略小写-g 杀死进程组而不是进程-i 交互模式，杀死进程前先询问用户-l 列出所有的已知信号名称-q 不输出警告信息-s 发送指定的信号-v 报告信号是否成功发送-w 等待进程死亡--help 显示帮助信息--version 显示版本显示示例1：杀死所有同名进程    killall nginx    killall -9 bash2.向进程发送指定信号    killall -TERM ngixn  或者  killall -KILL nginxtop命令，是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。如何杀死进程：（1）图形化界面的方式（2）kill -9 pid  （-9表示强制关闭）（3）killall -9 程序的名字（4）pkill 程序的名字查看进程端口号：netstat -tunlp|grep 端口号原文来自：http://r6d.cn/wnzC邮箱：tjulitianyi@163.com

VDEC支持多个channel为什么VENC一个进程只支持一个channel。

非阻塞IO(non-blocking IO)Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是用户就可以在本次到下次再发起read询问的时间间隔内做其他事情，或者直接再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存（这一阶段仍然是阻塞的），然后返回。    也就是说非阻塞的recvform系统调用调用之后，进程并没有被阻塞，内核马上返回给进程，如果数据还没准备好，此时会返回一个error。进程在返回之后，可以干点别的事情，然后再发起recvform系统调用。重复上面的过程，循环往复的进行recvform系统调用。这个过程通常被称之为轮询。轮询检查内核数据，直到数据准备好，再拷贝数据到进程，进行数据处理。需要注意，拷贝数据整个过程，进程仍然是属于阻塞的状态。    所以，在非阻塞式IO中，用户进程其实是需要不断的主动询问kernel数据准备好了没有。非阻塞IO实例：#服务端 from socket import * import time s=socket(AF_INET,SOCK_STREAM) s.bind(('127.0.0.1',8080)) s.listen(5) s.setblocking(False) #设置socket的接口为非阻塞 conn_l=[] del_l=[] while True:     try:         conn,addr=s.accept()         conn_l.append(conn)     except BlockingIOError:         print(conn_l)         for conn in conn_l:             try:                 data=conn.recv(1024)                 if not data:                     del_l.append(conn)                     continue                 conn.send(data.upper())             except BlockingIOError:                 pass             except ConnectionResetError:                 del_l.append(conn)         for conn in del_l:             conn_l.remove(conn)             conn.close()         del_l=[] #客户端 from socket import * c=socket(AF_INET,SOCK_STREAM) c.connect(('127.0.0.1',8080)) while True:     msg=input('>>: ')     if not msg:continue     c.send(msg.encode('utf-8'))     data=c.recv(1024)     print(data.decode('utf-8'))但是非阻塞IO模型绝不被推荐。    我们不能否则其优点：能够在等待任务完成的时间里干其他活了（包括提交其他任务，也就是 “后台” 可以有多个任务在“”同时“”执行）。    但是也难掩其缺点：#1. 循环调用recv()将大幅度推高CPU占用率；这也是我们在代码中留一句time.sleep(2)的原因,否则在低配主机下极容易出现卡机情况 #2. 任务完成的响应延迟增大了，因为每过一段时间才去轮询一次read操作，而任务可能在两次轮询之间的任意时间完成。这会导致整体数据吞吐量的降低。此外，在这个方案中recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。

分代垃圾回收器分代回收器有两个分区：老生代和新生代，新生代默认的空间占比总空间的 1/3，老生代的默认占比是 2/3。新生代使用的是复制算法，新生代里有 3 个分区：Eden、To Survivor、From Survivor，它们的默认占比是 8:1:1，它的执行流程如下：把 Eden + From Survivor 存活的对象放入 To Survivor 区；清空 Eden 和 From Survivor 分区；From Survivor 和 To Survivor 分区交换，From Survivor 变 To Survivor，To Survivor 变 From Survivor。每次在 From Survivor 到 To Survivor 移动时都存活的对象，年龄就 +1，当年龄到达 15（默认配置是 15）时，升级为老生代。大对象也会直接进入老生代。老生代当空间占用到达某个值之后就会触发全局垃圾收回，一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。207. 说一下 jvm 调优的工具？JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。jconsole：用于对 JVM 中的内存、线程和类等进行监控；jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等。

 jvm 的垃圾回收器Serial：最早的单线程串行垃圾回收器。Serial Old：Serial 垃圾回收器的老年版本，同样也是单线程的，可以作为 CMS 垃圾回收器的备选预案。ParNew：是 Serial 的多线程版本。Parallel 和 ParNew 收集器类似是多线程的，但 Parallel 是吞吐量优先的收集器，可以牺牲等待时间换取系统的吞吐量。Parallel Old 是 Parallel 老生代版本，Parallel 使用的是复制的内存回收算法，Parallel Old 使用的是标记-整理的内存回收算法。CMS：一种以获得最短停顿时间为目标的收集器，非常适用 B/S 系统。G1：一种兼顾吞吐量和停顿时间的 GC 实现，是 JDK 9 以后的默认 GC 选项。

发生版本【GaussDB A】【8.0.0.1】问题描述重分布完成一部分表之后终止数据重分布，重新启动跑批任务，出现如下几种报错现象：1、  应用程序连接数据库报错negative bitmapset member not allowed；2、  Cn频繁core重启，堆栈如下： 3、  Cn日志中有ERROR：invalid coordinator number: -1, NumCoords: 0报错。问题分析重分布完成一部分表之后终止数据重分布，此时集群还处于重分布Y模式下，如果使用JDBC作为客户端连接，且JDBC的URL带schema信息时，数据库中建立连接时没有初始化CN，DN handles信息导致上述三种报错。解决方案实际业务中很难彻底保证无跟表相关的ddl、跟表关联的对象的ddl、函数返回值带表类型的ddl等操作，所以建议使用方案一，最好不要使用方案二。方案一：1、停止重分布进程；1)omm用户登录第一个cn节点；2)找到gs_redis进程并将其kill -9 杀掉ps -ef |grep gs_redis|grep -v grep找到重分布进程pidkill -9 pid 杀掉重分布进程ps -ef |grep gs_redis|grep -v grep确认进程已被kill掉3)连接第一个cn，将数据重分布活跃语句全部终止掉SELECT pg_terminate_backend(pid);2、修改业务，JDBC的URL中去掉schema，把后面用户表都显式带上schema；3、运行业务；4、停止业务，重新调起重分布。source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilegs_expand -t redistribute --fast-redis --parallel-jobs=12 --redis-mode=read-only方案二：1、停止重分布进程；1)omm用户登录第一个cn节点；2)找到gs_redis进程并将其kill -9 杀掉ps -ef |grep gs_redis|grep -v grep找到重分布进程pidkill -9 pid 杀掉重分布进程ps -ef |grep gs_redis|grep -v grep确认进程已被kill掉3)连接第一个cn，将数据重分布活跃语句全部终止掉SELECT pg_terminate_backend(pid);2、修改所有cn上老nodegroup的in_redistribution=n；并kill cn进程alter table pgxc_group set in_redistribution='n' where group_name=old_group;kill cn进程ps -ef |grep coordinator|grep -v grep|awk -F ' ' '{print $2}'|xargs kill -93、运行业务，需要保证业务中无跟表相关的ddl，跟表关联的对象的ddl，函数返回值带表类型的ddl等操作，否则会造成新老节点元数据不一致；4、停止业务，修改所有cn上老nodegroup的redistribute=y；并kill cn进程alter table pgxc_group set in_redistribution='y' where group_name=old_group;kill cn进程ps -ef |grep coordinator|grep -v grep|awk -F ' ' '{print $2}'|xargs kill -95、重新调起重分布。source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilegs_expand -t redistribute --fast-redis --parallel-jobs=12 --redis-mode=read-only

1.当出现memory temporarily unavailable报错时，首先根据报错信息确认具体是哪个cn/dn报的，如果报错信息前面没有类型dnxxxx_xxxx这样的信息，就是cn报的，需要去每个cn的日志里排查是哪个cn2.通过free -g或top查看当前内存的使用情况，确认是操作系统内存耗尽，还是因为cn/dn的内存使用达到限制，如果已经没有现场，可以通过查看/var/log/osinfo中的meminfo来确认当时操作系统的可用内存；meminfo日志：下面我们分两种场景讨论场景一：操作系统没有可用内存对于操作系统内存耗尽的场景，往往会触发操作系统的oom保护机制，这个在/var/log/message中可以搜索关键字‘kill’可以找到相关信息；操作系统在oom杀掉进程时，会打印各个进程的内存使用情况，需要注意的是，rss列的单位并不是b，而是page，在x86服务器上需要乘以4k来计算得到进程实际使用内存大小，在arm服务器上要乘以16k通过比较进程被杀时的内存和max_process_memory，如果被杀时仍未达到max_process_memory，则需考虑max_process_memory是否设置过大，可调整参数解决如果进程被杀时内存已经超过了max_process_memory，可使用下面两个语句进一步分析常用的监控语句1）查看各类内存使用情况select * from pv_total_memory_detail;2）查看占用dynamic内存最高的语句select * from (selectsessid,sum_total,sum_free,sum_used,query_id,query_start,state,waiting,enqueue,queryfrom(selectsessid,sum(totalsize) as sum_total,sum(freesize) as sum_free,sum(usedsize) as sum_usedfrompv_session_memory_detailgroup bysessid ) a,pg_stat_activity bwheresplit_part ( a.sessid,'.' , 2 ) = b.pid )order bysum_total desclimit 10;注：上述第二条监控语句只是排查dynamic内存高的场景，如果第一条语句查出来的结果不是dynamic_used_memory或dynamic_peak_memory高，而是其他内存（other_used_memory、sctpcomm_used_memory等），则需另做排查，以后再开帖子详细介绍场景二：操作系统仍有可用内存，cn/dn实例的dynamic内存使用达到上限对于有现场的情况，可以使用上面的第二条sql语句找到占用内存最高的语句，杀掉该语句并进行整改对于没有现场的情况，可以部署监控脚本等待下次复现另外，如果实例是cn，往往是因为有大量的不下推语句，可以在日志中搜索can't be shipped查看不下推的语句，并进行整改

【功能模块】1 按照原来的demo修改。增加多线程推理调用多个模型，正常运行没问题显存也正常，结果也正常。多线程调用中没问题，但是线程退出最后释放这个函数时候后会报错。错误如下是否是多线程是释放context,device stream哪里有问题。【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

我们经常遇见等锁问题，通过视图查询非常繁琐，我们可以通过如下方式快速准确找到持锁的语句：set lockwait_timeout=1000;    --表锁等待超时时间，默认20min,danwei msset update_lockwait_timeout=1000;  --行锁等待超时时间，默认2minset max_query_retry_times=0;  -- cn_retry 次数，默认为6次设置完成后，执行等锁的语句。很快就会报错，根据报错信息可以快速找到持锁线程和语句。例如：会话一会话二start transaction; drop table aa;set lockwait_timeout=1000;set update_lockwait_timeout=1000;set max_query_retry_times=0;select * from aa;此时会话二会很快报错，通过报错信息很快就能找到持锁语句和线程：ERROR:  Lock wait timeout: thread 140354461361920 on node coordinator1 waiting for AccessShareLock on relation 16655 of database 14764 after 2000.057 msLINE 1: select * from aa;                      ^DETAIL:  blocked by hold lock thread 140354804238080, statement <drop table aa;>, hold lockmode AccessExclusiveLock.找到持锁线程并从业务侧确认可以杀掉该线程后，可以登录对应的实例（上面报错是coordinator1，实际可能是其他实例）,使用如下语句杀掉该线程：select pg_terminate_backend(140354804238080);也可以通过在CN上执行以下语句杀掉excute direct on(xxxx) select pg_terminate_backend(140354804238080);  (xxxx为报错的实例名称)杀掉后，可以通过下面语句确认是否已经杀掉：select * from pgxc_stat_activity where pid='140354804238080';确认杀掉后，重新执行语句即可。

2020-10-20：线程池如何保证核心线程不被销毁？#福大大架构师每日一题#

发生版本【GaussDB A】【C80SPC600】问题描述将重分布进程杀掉重入，长时间不能进入表重分布阶段，后台查看第一个cn上PG_STAT_ACTIVITY视图，发现是在执行如下语句：delete from pgxc_redistb where(nspname, relname) not in ( select n.nspname, c.relname from pg_class c,pg_namespace n where c.relnamespace = n.nspname);问题分析重分布重入时需要先将pgxc_redistb中已完成重分布的表记录剔除掉，此剔除语句执行慢。解决方案1、首先停止重分布进程；2、查看当前事务，cancel掉redis进程调起的语句   select pg_cancel_backend(pid)  from pg_stat_activity where application_name = 'gs_redis' and query like 'DELETE FROM pgxc_redistb%';3、修复表字段，在每个数据库下执行语句：set enable_cluster_resize = on;alter table pgxc_redistb alter column relname set not null;alter table pgxc_redistb alter column nspname set not null;4、重新调起重分布命令。

GDS常见问题FAQ【转载】原文链接：cid:link_0Q1:集群遇见报错unexpected EOF on GDS怎么处理？原因分析：当集群中出现大量这种错误时候首先考虑GDS机器的网络参数设置是否符合要求。可以参考下面的参数参数参考值：net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.core.netdev_max_backlog = 65535 net.ipv4.tcp_retries1 =5 net.ipv4.tcp_retries2 = 60 查看方法cat /proc/sys/net/core/somaxconn cat /proc/sys/net/ipv4/tcp_max_syn_backlog cat /proc/sys/net/core/netdev_max_backlog cat /proc/sys/net/ipv4/tcp_retries1 cat /proc/sys/net/ipv4/tcp_retries2修改方法修改对应参数： vim /etc/sysctl.conf 永久生效： sysctl -pQ2: GDS遇到到网络层错误 “connection timed out” 怎么处理？原因1：由于高并发导入导出时GDS端向DN造成发送数据网络拥塞，当出现发送不成功后GDS会接收到网络层错误connection timed out 并主动 断开连接，之后DN 在下次请求GDS数据时也会接收到connection reset by peer 网络层错误. 经常发生在 数据传输过程中,可以调整系统 net.ipv4.tcp_retries2和 net.ipv4.tcp_retries1 参数原因2： 也可能是因为gds处理请求较慢，以至于backlog listen队列被填满后，新来的请求会被拒绝,一般发生在建连截断。可以调大net.core.somaxconn参数解决解决方法： 同上：net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog =65535 net.core.netdev_max_backlog = 65535 net.ipv4.tcp_retries1 = 5 net.ipv4.tcp_retries2 = 60 原因3： 大集群上arp路由表缓存溢出导致业务报错：connection reset by peer: gc_thresh1，gc_thresh2，gc_thresh3参数是默认值128 512 1024，DN分布在多个服务器机器上，导致连接过来接近512的arp缓存淘汰上限，可能会触发连接不识别被关闭等问题 解决方法：gc_thresh1 = 512 gc_thresh2 = 2048 gc_thresh3 = 4096Q3: DN 报错 ”The peer GDS has performed an orderly shutdown on current connection.“ 什么原因？可能原因：gds挂掉tcp连接异常，参考上面两种情况修改gds参数。gs_check巡检集群系统参数是否合理.Q4: GDS报错句柄不足，报错 too many open file 怎么处理？原因分析： gds进程占用的文件句柄超过设置的值。 解决办法：修改最大进程打开文件句柄数:/etc/security/limits.conf* soft nofile 640000 * hard nofile 640000 修改/etc/security/limits.d/*目录里的配置文件，对于配置文件中存在nofile配置的都需要修改，没有就跳过； 默认优先使用limits.d目录里的配置，再使用limits.conf的配置* soft nofile 640000 * hard nofile 640000修改 /etc/systemd/system.conf，修改行：DefaultLimitNOFILE=640000 保存退出.重新加载systemd服务配置systemctl daemon-reload systemctl daemon-reexec重新打开一个session 以集群用户重启gds进程.执行cat /proc/gds的pid/limits查询，参数已更改.Q5： GDS导入发现集群gaussdb IO异常高100%什么原因？可能原因： 内表中包含了大量索引，如果是btree索引导数过程中大量的索引操作导致系统IO非常高。 排查方法： iotop 观察哪一个进程占用的io非常高， Total DISK READ: 0.00 B/s | Total DISK WRITE: 259.32 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO&gt; COMMAND 111958 be/4 sheng 0.00 B/s 16.73 K/s 0.00 % 0.00 % postgres: stats collector 54920 be/4 sheng 0.00 B/s 6.69 K/s 0.00 % 0.00 % gaussdb --coordinator -i -p 44548 -c log_statement=all -M normal -c logg~ sheng/GAUSS200_OLAP_TRUNK/Code/src/test/regress/./tmp_check/coordinator2 54986 be/4 sheng 0.00 B/s 500M/s 0.00 % 0.00 % gaussdb --datanode -i -p 44556 -c log_statement=all -M normal -c 发现 dn 进程号54986 写io非常高。gstack 54986|grep -i write查看当前进程在做什么操作Q6： ERROR: dn_6001_6002: GDS max line size 1073741823 is exceeded. 为什么？原因分析： GDS导数时候为了避免文件格式异常导致识别的单行数据过大甚至导致系统oom的场景，gds端限制单行不能超过1G。 解决方法： 首先考虑是否因为csv文件的quote没有成对出现，如果确实是因为quote导致的可以考虑修改外表的quote为不可见字符；其次考虑单行数据是否确实的超过1G，手动删除改行。Q7: Cannot enlarge buffer containing 1078343432 bytes by 40783434 为什么？原因分析：copy或者导入的时候可能由于csv文件格式于文件格式异常导致识别的单行数据过大超过1G；或者单行数据大于1G。解决方法： 出现此错误时候首先考虑是否因为csv文件的quote没有成对出现，可以考虑修改sql的quote为不可见字符； 其次考虑单行数据是否确实的超过1G，手动删除改行。Q8: "unexpected message type 0x58 during COPY from stdin" 为什么原因分析： 由于进群故障，如dn宕机后并且不能重试，cn会向dn下发‘X' 报文意味着cn正在关闭socket。属于正常报错信息。 解决办法： 查看集群日志分析为什么集群出现故障。Q9: 为什么乱码？原因分析：乱码的原因本质上是因为 字符编码转换不匹配copy或者gds导入文件中存在混合编码 或者不能转换的字符 存在的原因： 文件来源于另外一个数据库系统，比如oracle或者gaussdb数据库编码设置为"不校验编码"一般为标准ascii类编码比如postgresql中的sqlascii编码,mysql中使用latin1作为"不校验编码"。 由于这种编码数据库内部都不做校验因此用户无论给定什么编码的数据他都会以字节流的方式存起来（也叫错入错处）但是这样会导致一张表里包含不同的编码的数据，如果从这样的系统导出文件自然文件中也会包含不同编码的内容。当使用这种文件导入到gaussdb中的时候有可能报错如“invalid byte sequence for encoding 'utf8': 0xc3”表示0xc4不是一个有效的utf8编码，或者会将乱码字符插入数据库。 预防方法： 设置客户端，外表，数据库的编码一致 。解决方法： 设置gds或者copy的容错参数，或者使用iconv 命令将文件转码为统一的编码（其实iconv遇到转换不了的也会报错或者替换成？之类的字符和gaussdb的容错思路差不多） gds或者copy 的容错机制中有一种可以规避（注意是规避）这个问题。 gds和copy都有一个参数"COMPATIBLE_ILLEGAL_CHARS" 会将转换不了的字符替换成‘?'Q10: 怎么确定文件编码和文件内容是什么编码？其实一般程序更关心文件内容是什么编码而不是文件是什么编码，文件是什么编码取决于bom头写的是什么编码，文件是什么编码取决于结出来的编码有无乱码。 **注意：通过file 命令或者使用vim看到的编码格式不一定是实际的编码，因为他们都是通过识别bom头来确定是什么编码的，但是有些程序写入的数据并不会像在window上那样设置编码格式头也叫“bom头"**。教一个方法:将你设置了终端（xshell后者crt）编辑器显示的编码打开文件如果发现语句通顺那这个文件中的内容就是你终端和编辑器的编码。 在中国大陆能看到最多的编码转换问题大多数是由于gbk,gb2312和utf8 的转换问题或者latin1和utf8的编码转换问题。如果不是这两种问题最好能转换成这种问题。因为gaussdb和pg数据库最擅长的就是处理这些编码转换。​编码建议：目前线网最常见的编码转换仍然是gbk到utf8编码的转换。虽然gaussdb数据库服务端已经支持设置GBK字符集但是强烈建议在设计之初将服务端数据库编码设置成utf8编码，因为utf8可以识别gbk识别不了的字符，除非你的系统以后都只服务汉字人群。 也不建议将数据库编码设置为“sqlascii”，虽然很灵活但是非常率容易出现混合编码后期维护很差。如果后面要插入一些比较特殊的字符，虽然目前gaussdb已经支持了服务端的GBK编码但是某些场景可能尚未考虑到。sqlascii编码虽然方便但是后期不好维护。比如gaussdb目前latin1和gbk是不能互相转换的，但是latin1和utf8就可以互相转换。Q11： GDS外表无数据查询为什么hang？解决方法：查询gds和集群是否网络畅通.查询外表定义中location网络地址是否畅通。查询外表定义中location的协议是否正确对应 ssl->gsfss 普通协议->gsfs集群gtm或者dn故障。Q12： GDS外表有数据数据查询为什么hang？。解决方法：查询gds和集群是否网络畅通.查询外表定义中location网络地址是否畅通。查询外表定义中location的协议是否正确对应 ssl->gsfss 普通协议->gsfs集群gtm或者dn故障。网络拥塞：排查gds发送端 网络拥塞情况 netstat -taucp|grep gds端口 tcp 0 74457 mpp116:31001 mpp098:62506 ESTABLISHED 48541/gds排查DN接受端 网络拥塞情况 netstat -taucp|grep gds端口 cp 0 0 mpp098:62506 mpp116:31001 ESTABLISHED 8824/gaussdb观察现象发现GDS端TCP的Send Queue中堆积了大量数据，而DN端Recv Queue中无任何数据。并且通过-t的实时打印可以发现GDS端TCP的Send Queue中数据在一个较长的时间段能不会减少，而且数据减少的周期非常长且亦有阶段性，而DN端未检测到Recv Queue中有数据。因此定位为TCP连接数据传输被阻塞。Q13： GDS -t 参数原理是什么？设置GDS并发线程数，其实是设置了GDS指的工作线程池大小。比如-t 指定为10 系统回见测试当前是否有空工作线程且当前工作线程小于10时候才会创建新线程，不会一启动就事先创建10个线程。GDS是根据导入事务并发数来决定服务运行线程数的。也就是说即使启动GDS时设置了多线程，也并不会加速单个导入事务。未做过人为事务处理时，一条INSERT语句就是一个导入事务.

理论知识之进程的并行与并发并行 : 并行是指两者同时执行，比如赛跑，两个人都在不停的往前跑；（资源够用，比如三个线程，四核的CPU ）并发 : 并发是指资源有限的情况下，两者交替轮流使用资源，比如一段路(单核CPU资源)同时只能过一个人，A走一段后，让给B，B用完继续给A ，交替使用，目的是提高效率。区别:并行是从微观上，也就是在一个精确的时间片刻，有不同的程序在执行，这就要求必须有多个处理器。并发是从宏观上，在一个时间段上可以看出是同时执行的，比如一个服务器同时处理多个session。

2020-10-07：redis存在线程安全的问题吗？为什么？#福大大架构师每日一题#

2020-10-06：java中垃圾回收器让工作线程停顿下来是怎么做的？#福大大架构师每日一题#