死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。

,各司其中​    最主要的区别就是栈内存就是存储局部变量和方法调用,堆是用来存储Java中的对象,无论是成员变量,局部变量还是类变量,他们指向的对象都是存储在堆内存中2,独有还是共享​    栈内存是单线程,没个线程都会有一个栈内存,存存储的变量只能在其所属线程中可见,即栈内存可以理解为线程的私有内存.而堆内存中的对象对所有线程可见.堆内存中的对象可以被所有线程访问3,异常错误​    栈内存不足会报 java.lang.StackOverFlowError​    堆内存不足会报java.lang.OutOfMemoryError4,空间大小​    栈的内存远小于堆内存,可以通过xss设置栈大小,-xms设置堆初始化大小,xmx设置堆最大值

列出所有任务及进程号，杀进程taskkilltaskkill /?  获取使用帮助taskkill是用来终止进程的。具体的命令规则如下：TASKKILL [/S system [/U username [/P [password]]]]{ [/FI filter] [/PID processid | /IM imagename] } [/F] [/T]描述:这个命令行工具可用来结束至少一个进程。可以根据进程 id 或映像名（Image）来结束进程。参数列表:/S system 指定要连接到的远程系统。/U [domain\]user 指定应该在哪个用户上下文执行这个命令:/P [password] 为提供的用户上下文指定密码。如果忽略，提示输入。/F 指定要强行终止的进程。/FI filter 指定筛选进或筛选出查询的的任务。/PID process id 指定要终止的进程的PID。/IM image name 指定要终止的进程的映像名称。通配符 '*'可用来指定所有映像名。/T Tree kill: 终止指定的进程和任何由此启动的子进程。/? 显示帮助/用法。例如:TASKKILL /S system /F /IM notepad.exe /TTASKKILL /PID 1230 /PID 1241 /PID 1253 /TTASKKILL /F /IM QQ.exeTASKKILL /F /IM notepad.exe /IM mspaint.exeTASKKILL /F /FI "PID ge 1000" /FI "WINDOWTITLE ne untitle*"TASKKILL /F /FI "USERNAME eq NT AUTHORITY\SYSTEM" /IM notepad.exe

  当线程池中核心线程数量过大时，线程与线程之间会争取CPU资源，这样就会导致上下文切换。过多的上下文切换会增加线程的执行时间，影响了整体执行的效率；  多线程编程中一般线程的个数都大于CPU核心的个数，而一个CPU核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效的执行，CPU采取的策略是为了每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让其他线程使用，这个过程就属于一次上下文切换。  当线程池中的核心线程数量过少时，如果统一时间有大量任务需要处理，可能会导致大量任务在任务队列中排队等待执行，甚至会出现队列满了之后任务无法执行的情况，或者大量任务堆积在任务队列导致内存溢出（OOM）。

分析一般从几个角度考虑：任务的性质：CPU密集型的任务、IO密集型任务、混合型任务。任务的优先级：高、中、低任务执行时间：长、中、短任务的依赖性：是否依赖其它系统资源，如数据库的连接等。cpu密集型  尽量减少线程数；比如像加解密，压缩、计算等一系列需要大量耗费 CPU 资源的任务，大部分场景下都是纯 CPU 计算。尽量使用较小的线程池，一般为CPU核心数+1。因为CPU密集型任务使得CPU使用率很高，若开过多的线程数，会造成CPU过度切换。IO密集型  任务尽量加大线程数，因为io不占用cpu的资源。比如像 MySQL 数据库、文件的读写、网络通信等任务，这类任务不会特别消耗 CPU 资源，但是 IO 操作比较耗时，会占用比较多时间。可以使用稍大的线程池，一般为CPU核心数 * 2。IO密集型任务CPU使用率并不高，因此可以让CPU在等待IO的时候有其他线程去处理别的任务，充分利用CPU时间。混合型  尽量根据实际情况进行拆分，根据运行时间来决定。  可见，线程的平均工作时间所占比例越高，就需要越少的线程；线程的平均等待时间所占比例越高，就需要越多的线程；

【操作步骤&问题现象】避免网络波动引起的时间问题，想增加这个时间是修改hbase.regionserver.maxclockskew就可以还是说同时要改hbase.master.wait.on.regionservers.timeout？现场调整后重启报错这一台的regionserver发现没有效果为什么？Reported time is too far out of sync with master. Time difference of 37232ms > max allowed of 30000ms

关键字：线程残留，查杀SQL，锁冲突，vacuum full空间不回收，消耗系统资源1. 线程残留可能会对业务带来以下影响： 持锁导致其他语句获取不到锁； 残留线程的事务号太老，导致8.0以下版本vacuum full时空间不能回收；残留线程消耗大量的io,CPU，内存等系统资源，导致业务变慢。2. 如何找到残留线程连接CN，执行以下语句：select node_name,tid,query_id from pgxc_thread_wait_status b where not exists (select query_id from  pgxc_thread_wait_status a where a.node_name like 'c%' and a.query_id=b.query_id) and b.node_name like 'd%' and b.wait_status not in ('none','wait cmd') and b.tid <> pg_backend_pid();确认CN上没有对应的线程，其中$query_id是上一步查到的query_id:select * from pgxc_stat_activity where query_id in ($query_id);3. 如何处理残留线程按照标准应急方案查杀：HC/HCS/HCSO：  https://bbs.huaweicloud.com/forum/thread-147712-1-1.html线下纯软版本：https://bbs.huaweicloud.com/forum/thread-150168-1-1.html4. 监控方法创建附件中的存储过程，周期(几小时一次)调用存储过程，下面存储过程入参表示该线程已经执行超过6小时，可以根据实际情况自行调整：select * from pgxc_residuals_check(6);备注：如果已经存储过程，可以使用该存储过程代替前面的查询步骤。

【功能模块】arcore是4核【操作步骤&问题现象】1、arcore是4核，可以支持或者提供接口把某个线程绑定到某一个cpu核上吗？【截图信息】无【日志信息】（可选，上传日志内容或者附件）无

日常运维过程中，当磁盘性能较差，又总是能碰到io读写很高的语句，导致整体性能较差的时候，可以使用以下办法进行排查：例如构造如下语句：1.连接数据库执行以下sql，构造io使用场景：2.使用root用户，进行iotop观察，直接执行iotop命令：上图可以看到，iotop中有多个指标，有tid可以关联到实际的语句，并且有每个线程的disk read/write的情况，按左右键可以调整排序的维度，如上图，可以看到>标记在DISK WRITE，因此此时是用线程的disk write情况进行排序，写入速率最大的排在最上面。那么我们就找到了最消耗io的线程：第一列：33499/33488等3. 根据线程号，找到问题语句：select a.query,a.query_id,a.pid,b.tid,b.lwtid,b.wait_status from pgxc_stat_activity a,pgxc_thread_wait_status b where lwtid = 33488 and a.query_id = b.query_id and a.query_id <> 0;33488替换为对应线程号：此时会有两种情况，根据线程号能找到对应的业务sql，或者找不到业务sql。1）查到对应语句：获取到语句的pid之后，将导致问题的语句，连接对应cn，使用select pg_terminate_backend(pid);处理掉即可。此时再观察io的使用情况，是否还比较高。如还比较高，使用一样的方法，继续处理问题语句即可。2）查不到对应语句：那么此时就使用gstack工具，查看耗io高的语句在做什么。举例如下：从上图可以看到，此时耗费io的线程，正在进行日志同步。那么就继续分析对应线程的工作情况，确认是否为正常现象。

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处理某个模型的文档，请问在那个文档或则教程有这块内容。