在某些电脑安装完设计器后，去拾取网页元素或者点击录制器，在设计器右上角有如下提示，有时重启电脑也解决不了这个问题。原因分析： 这机器使用的这个端口被其本地的其他程序占用了，导致studio就用不了这个接口了。解决方法：法一、简单快速的方法是本地电脑新建一个用户，环境是干净的，使端口都是空闲的。法二、使用cmd命令查找到相应的程序并做杀进程使端口空闲先来。1、退出WeAutomate设计器2、打开一个cmd窗口，并输入netstat -ano | findstr 578893、根据查询出来的PID（上图红框所示），查询进程，可以看到是哪个程序，这个可以略过tasklist|findstr 53764、使用taskkill杀掉进程，注意替换查询到的PID号码taskkill /pid 5376 -t -f基本既可以解决“请检查57889端口是否被占用类问题”如有解决不了的情况请大家留言。

RPCRPC和RESTful都是远程调用接口，那么它们之间到底有什么区别的呢？我以前一直傻傻分不清楚，直到我看了周志明老师写的《凤凰架构：构建可靠的大型分布式系统》我才理清了它们之间的区别，怕自己忘了，特意做下笔记。RPC（Remote Procedure Call，RPC），即远程过程调用，最近几年频繁被各种论坛，文章，课程提及，乍一看还以为是什么牛逼的新技术，其实在计算机科学中已经存在超过四十年时间，是个不折不扣的“老古董”。RPC出现的最初目的，就是为了让计算机能够与调用本地方法一样去调用远程方法。我们先来看一下计算机是如何调用本地方的，我抄录了书中的例子：// Caller : 调用者，代码里的main()// Callee ： 被调用者，代码里的println()// Call Site ： 调用点，即发生方法调用的指令流位置// Parameter ： 参数，由Caller传递给Callee的数据，即“hello world”// Retval ： 返回值，由Callee传递给Caller的数据，如果方法能够正常结束，它是void，如果方法异常完成，它是对应的异常public static void main(String[] args) {    System.out.println("hello world");}123在完全不考虑编译器优化的前提下，程序运行至调用println()方法输出hello world这行时，计算机（物理机或者虚拟机）要完成以下几项工作。传递方法参数：将字符串hello world的引用地址压栈。确定方法版本：根据println()方法的签名，确定其执行版本。这其实并不是一个简单的过程，无论是编译时静态解析，还是运行时动态分派，都必须根据某些语言规范中明确定义的原则，找到明确的Callee，“明确”是指唯一的一个Callee，或者有严格优先级的多个Callee，譬如不同的重载版本。执行被调方法：从栈中弹出Parameter的值或引用，并以此为输入，执行Callee内部的逻辑。这里我们只关心方法是如何调用的，而不关心方法内部具体是如何执行的。返回执行结果：将Callee的执行结果压栈，并将程序的指令流恢复到Call Site的下一条指令，继续向下执行。我们再来考虑如果println()方法不在当前进程的内存地址空间中会发生什么问题。不难想到，这样会至少面临两个直接的障碍。首先，第一步和第四步所做的传递参数、传回结果都依赖于栈内存，如果Caller与Callee分属不同的进程，就不会拥有相同的栈内存，此时将参数在Caller进程的内存中压栈，对于Callee进程的执行毫无意义。其次，第二步的方法版本选择依赖于语言规则，如果Caller与Callee不是同一种语言实现的程序，方法版本选择就将是一项模糊的不可知行为。我们暂时忽略第二个问题，假设Caller和Callee是使用同一种语言实现的。那么两个进程之间该如何交换数据呢？这就是“进程间通信”（Inter-Process Communication，IPC）要解决的问题。进程间通信几种解决方案：管道（Pipe）或者具名管道（Named Pipe）管道类似于两个进程间的桥梁，可通过管道在进程间传递少量的字符流或字节流。普通管道只用于有亲缘关系的进程（由一个进程启动的另外一个进程）间的通信，具名管道摆脱了普通管道没有名字的限制，除具有管道的所有功能外，它还允许无亲缘关系的进程间的通信。管道典型的应用就是命令行中的“|”操作符，譬如：ps -ef | grep javaps与grep都有独立的进程，以上命令就是通过管道操作符“|”将ps命令的标准输出连接到grep命令的标准输入上。信号（Signal）信号用于通知目标进程有某种事件发生。除了进程间通信外，进程还可以给进程自身发送信号。信号的典型应用是kill命令，譬如：kill -9 pid以上命令即表示由Shell进程向指定PID的进程发送SIGKILL信号。信号量（Semaphore）信号量用于在两个进程之间同步协作手段，它相当于操作系统提供的一个特殊变量，程序可以在上面进行wait()和notify()操作。消息队列（Message Queue）以上三种方式只适合传递少量消息，POSIX标准中定义了可用于进程间数据量较多的通信的消息队列。进程可以向队列添加消息，被赋予读权限的进程还可以从队列消费消息。消息队列克服了信号承载信息量少、管道只能用于无格式字节流以及缓冲区大小受限等缺点，但实时性相对受限。共享内存（Shared Memory）允许多个进程访问同一块公共内存空间，这是效率最高的进程间通信形式。原本每个进程的内存地址空间都是相互隔离的，但操作系统提供了让进程主动创建、映射、分离、控制某一块内存的程序接口。当一块内存被多进程共享时，各个进程往往会与其他通信机制，譬如与信号量结合使用，来达到进程间同步及互斥的协调操作。本地套接字接口（IPC Socket）消息队列与共享内存只适合单机多进程间的通信，套接字接口则是更普适的进程间通信机制，可用于不同机器之间的进程通信。套接字（Socket）起初是由UNIX系统的BSD分支开发出来的，现在已经移植到所有主流的操作系统上。出于效率考虑，当仅限于本机进程间通信时，套接字接口是被优化过的，不会经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等操作，只是简单地将应用层数据从一个进程复制到另一个进程，这种进程间通信方式即本地套接字接口（UNIX Domain Socket），又叫作IPC Socket。RPC要解决的三个问题如何表示数据这里的数据包括传递给方法的参数和方法执行之后的返回值。也就是说一个进程把参数传给另一个进程，或者从另一个进程获取返回值，数据格式怎么表示的问题。你可能会觉得很奇怪，比如用Java语言写的程序，传递String，int等类型不就行了吗？对于进程内的方法调用，使用同一种语言的数据类型，比如双方的程序都用Java语言写的，这样调用自然没有问题。但是，如果调用方是用Java语言写的，被调用方是C语言写的，他们的数据类型定义的都不一样，该如何兼容呢？就算双方都用同一种语言写的，比如C语言，但是在不同的硬件指令集、不同的操作系统下，同样的数据类型也完全可能有不一样的表现细节，譬如数据宽度、字节序列的差异等等。那该怎么办呢？说来也简单，就是先把双方要交流的数据先转化成大家都认识的中间格式，然后再将中间格式数据转化成自己所用语言的数据类型，听起来是不是很熟悉？没错，这就是序列化与反序列化。我以前学Java的时候，学到序列化与反序列化就很纳闷？参数为什么要序列化呢？直接传不就行了吗？原来是要考虑不同语言、硬件、操作系统的情况。每种RPC协议都有对应的序列化协议，例如：ONC RPC的外部数据表示（External Data Representation，XDR）CORBA的通用数据表示（Common Data Representation，CDR）Java RMI的Java对象序列化流协议（Java Object Serialization Stream Protocol）gRPC的Protocol BuffersWeb Service的XML序列化众多轻量级RPC支持的JSON序列化看到Web Service的XML序列化特别有感触，以前在用Web Service的时候，我很奇怪为什么要用xml费这么大劲去描述一个个字段，一个个参数，原来是为了让不同的语言都能识别。如何传递数据两个程序之间如何传递数据，也就是互相操作，交互数据，除了序列化与反序列化之外还需要考虑：异常、超时、安全、认证、授权、事务等等，都可能产生双方需要交换信息的需求。在计算机科学中，专门有一个名词“Wire Protocol”来表示这种两个Endpoint之间交换这类数据的行为，常见的Wire Protocol如下：Java RMI的Java远程消息交换协议（Java Remote Message Protocol，JRMP，也支持RMI-IIOP）CORBA的互联网ORB间协议（Internet Inter ORB Protocol，IIOP，是GIOP协议在IP协议上的实现版本）DDS的实时发布订阅协议（Real Time Publish Subscribe Protocol，RTPS）Web Service的简单对象访问协议（Simple Object Access Protocol，SOAP）如果要求足够简单，双方都是HTTP Endpoint，直接使用HTTP协议也是可以的（如JSON-RPC）除了传递数据，RPC 还有更吸引人的地方，它真正强大的地方是它的治理功能，比如连接管理、健康检测、负载均衡、优雅启停机、异常重试、业务分组以及熔断限流等等。如何表示方法确定表示方法在本地方法调用中并不是太大的问题，编译器或者解释器会根据语言规范，将调用的方法签名转换为进程空间中子过程入口位置的指针。不过一旦要考虑不同语言，事情又立刻麻烦起来，每种语言的方法签名都可能有差别，所以“如何表示同一个方法”“如何找到对应的方法”还是需要一个统一的跨语言的标准才行。这个标准可以非常简单，譬如直接给程序的每个方法都规定一个唯一的、在任何机器上都绝不重复的编号，调用时压根不管它是什么方法、签名是如何定义的，直接传这个编号就能找到对应的方法。这种听起既粗鲁又寒碜的办法，还真的就是DCE/RPC当初准备的解决方案。虽然最终DCE还是弄出了一套与语言无关的接口描述语言（Interface Description Language，IDL），成为此后许多RPC参考或依赖的基础（如CORBA的OMG IDL），但那个唯一的绝不重复的编码方案UUID（Universally Unique Identifier）也被保留且广为流传开来，并被广泛应用于程序开发的方方面面。类似地，用于表示方法的协议还有：Android的Android接口定义语言（Android Interface Definition Language，AIDL）CORBA的OMG接口定义语言（OMG Interface Definition Language，OMG IDL）Web Service的Web服务描述语言（Web Service Description Language，WSDL）JSON-RPC的JSON Web服务协议（JSON Web Service Protocol，JSON-WSP）以上RPC中的三个基本问题，全部都可以在本地方法调用过程中找到对应的解决方案。RPC的设计始于本地方法调用，尽管早已不再追求实现与本地方法调用完全一致的目的，但其设计思路仍然带有本地方法调用的深刻烙印，抓住两者间的联系来类比，对我们更深刻地理解RPC的本质会很有帮助。为了解决上面的三个问题，每个RPC的产品解决问题的角度不同，有的着重于简单性，有的希望能支持更多的语言达到普适性，有的看中高性能。现在，已经相继出现过RMI（Sun/Oracle）、Thrift（Facebook/Apache）、Dubbo（阿里巴巴/Apache）、gRPC（Google）、Motan1/2（新浪）、Finagle（Twitter）、brpc（百度/Apache）、.NET Remoting（微软）、Arvo（Hadoop）、JSON-RPC 2.0（公开规范，JSON-RPC工作组）等难以穷举的协议和框架。这些RPC功能、特点不尽相同，有的是某种语言私有，有的支持跨越多种语言，有的运行在应用层HTTP协议之上，有的直接运行于传输层TCP/UDP协议之上，但并不存在哪一款是“最完美的RPC”。今时今日，任何一款具有生命力的RPC框架，都不再去追求大而全的“完美”，而是以某个具有针对性的特点作为主要的发展方向。同时这也导致了我们的选择困难症，更是催生出了一大堆网络文章和课程，来讲解各RPC的优缺点，什么时候能有一个RPC的王者出来统一天下呢？RESTREST源于Roy Thomas Fielding在2000年发表的博士论文“Architectural Styles and the Design of Network-based Software Architectures”，此文的确是REST的源头。REST（Representational State Transfer，表征状态转移），这个名字听起来很晦涩，什么叫“表征”、什么东西的“状态”、从哪“转移”到哪？我们要理解REST就要先理解什么是HTTP，再配合一些实际例子来对两者进行类比，以更清楚地了解REST，你会发现REST实际上是“HTT”（Hypertext Transfer）的进一步抽象，两者的关系就如同接口与实现类的关系一般。超文本（或超媒体）“超文本（或超媒体）”是一种“能够对操作进行判断和响应的文本（或声音、图像等）”，这个概念在20世纪60年代提出时应该还属于科幻的范畴，但是今天大众已经完全接受了它，互联网中一段文字可以点击、可以触发脚本执行、可以调用服务端已毫不稀奇。下面我们继续尝试从“超文本”或者“超媒体”的含义来理解什么是“表征”以及REST中的其他关键概念，这里使用一个具体事例将其描述如下：资源（Resource）譬如你现在正在阅读一篇名为《REST设计风格》的文章，这篇文章的内容本身（你可以将其理解为蕴含的信息、数据）称之为“资源”。无论你是通过阅读购买的图书、浏览器上的网页还是打印出来的文稿，无论是在电脑屏幕上阅读还是在手机上阅读，尽管呈现的样子各不相同，但其中的信息是不变的，你所阅读的仍是同一份“资源”。表征（Representation）当你通过浏览器阅读此文章时，浏览器会向服务端发出“我需要这个资源的HTML格式”的请求，服务端向浏览器返回的这个HTML就被称为“表征”，你也可以通过其他方式拿到本文的PDF、Markdown、RSS等其他形式的版本，它们同样是一个资源的多种表征。可见“表征”是指信息与用户交互时的表示形式，这与我们软件分层架构中常说的“表示层”（Presentation Layer）的语义其实是一致的。状态（State）当你读完了这篇文章，想看后面是什么内容时，你向服务端发出“给我下一篇文章”的请求。但是“下一篇”是个相对概念，必须依赖“当前你正在阅读的文章是哪一篇”才能正确回应，这类在特定语境中才能产生的上下文信息被称为“状态”。我们所说的有状态（Stateful）抑或是无状态（Stateless），都是只相对于服务端来说的，服务端要完成“取下一篇”的请求，要么自己记住用户的状态，如这个用户现在阅读的是哪一篇文章，这称为有状态；要么由客户端来记住状态，在请求的时候明确告诉服务端，如我正在阅读某某文章，现在要读它的下一篇，这称为无状态。也就是说，由服务端来记录用户的状态就叫有状态；由客户端记录状态，并把它传到服务端的叫做无状态。转移（Transfer）无论状态是由服务端还是由客户端来提供，“取下一篇文章”这个行为逻辑只能由服务端来提供，因为只有服务端拥有该资源及其表征形式。服务端通过某种方式，把“用户当前阅读的文章”转变成“下一篇文章”，这就被称为“表征状态转移”。REST的一条核心原则是“统一接口（Uniform Interface）”，REST希望开发者面向资源编程，希望软件系统设计的重点放在抽象系统该有哪些资源，而不是抽象系统该有哪些行为（服务）上。这条原则你可以类比计算机中对文件管理的操作来理解，管理文件可能会涉及创建、修改、删除、移动等操作，这些操作数量是可数的，而且对所有文件都是固定、统一的。如果面向资源来设计系统，同样会具有类似的操作特征，由于REST并没有设计新的协议，所以这些操作都借用了HTTP协议中固有的操作命令来完成。统一接口也是REST最容易陷入争论的地方，基于网络的软件系统，到底是面向资源合适，还是面向服务更合适，这个问题恐怕在很长时间里都不会有定论，也许永远都没有。但是，已经有一个基本清晰的结论是：面向资源编程的抽象程度通常更高。抽象程度高带来的坏处是距离人类的思维方式往往会更远，而好处是通用程度往往会更好。用这样的语言去诠释REST，还是有些抽象，下面以一个例子来说明：譬如，对于几乎每个系统都有的登录和注销功能，如果你理解成登录对应于login()服务，注销对应于logout()服务这样两个独立服务，这是“符合人类思维”的；如果你理解成登录是PUT Session，注销是DELETE Session，这样你只需要设计一种“Session资源”即可满足需求，甚至以后对Session的其他需求，如查询登录用户的信息，就是GET Session而已，其他操作如修改用户信息等也都可以被这同一套设计囊括在内，这便是“抽象程度更高”带来的好处。如果想要在架构设计中合理恰当地利用统一接口，建议系统应能做到每次请求中都包含资源的ID，所有操作均通过资源ID来进行；建议每个资源都应该是自描述的消息；建议通过超文本来驱动应用状态的转移。REST绑定于HTTP协议。面向资源编程不是必须构筑在HTTP之上，但REST是，这是缺点，也是优点。因为HTTP本来就是面向资源设计的网络协议，纯粹只用HTTP（而不是SOAP over HTTP那样再构筑协议）带来的好处是无须考虑RPC中的Wire Protocol问题，REST将复用HTTP协议中已经定义的概念和相关基础支持来解决问题。HTTP协议已经有效运作了三十年，其相关的技术基础设施已是千锤百炼，无比成熟。而坏处自然是，当你想去考虑那些HTTP不提供的特性时，便会彻底束手无策。HTTP协议中已经提前约定好了一套“统一接口”，它包括GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS七种基本操作，任何一个支持HTTP协议的服务器都会遵守这套规定，对特定的URI采取这些操作，服务器就会触发相应的表征状态转移。REST接口很容易理解，举个具体例子，假设一个商城用户中心的接口设计：用户资源会拥有多个不同的下级的资源，譬如若干条短消息资源、一份用户资料资源、一辆购物车资源，购物车中又会有自己的下级资源，譬如多本图书资源。你很容易在程序接口中构造出这些资源的集合关系与层次关系，而且这些关系是符合人们长期在单机或网络环境中管理数据的经验的。相信你不需要专门阅读接口说明书，就能轻易推断出获取用户icyfenix的购物车中的第2本书的REST接口应该表示为：GET /users/icyfenix/cart/2。再来举几个列子：GET /books：列出所有书籍POST /books：新建一本书GET /books/ID：获取某个指定书籍的信息PUT /books/ID：更新某本书籍的信息（提供该书籍的全部信息）PATCH /books/ID：更新某本指定书籍的信息（提供该书籍的部分信息）DELETE /books/ID：删除某本书

问题现象业务中DDL偶发或频繁执行变慢，ms级->s级劣化排查方法1、抓DDL慢时部分CN/DN的进程堆栈gstack cn_pid/dn_pid > stack.log2、分析进程中高频栈cat stack.log | grep "#2  0x00" |awk '{print $4}'| sort -rn |uniq -c | sort -rn如searchCatCache/systable_beginscan/heap_getnext几个函数高频出现则进行后续索引后置排查3、查系统表索引偏移1）拼接需要查询的语句select 'execute direct on (' || node_name || ') ''select ctid,oid,relname from pg_class where oid in(2662,2659,2679,2687,2655,2693,2701)'';' from pgxc_node;select 'execute direct on (' || node_name || ') ''select ctid,attrelid,attname from pg_attribute where attrelid in(2662,2659,2679,2687,2655,2693,2701)'';' from pgxc_node;2）执行1中拼接的语句若存在例如上述这种ctid中位置超过10w的情况，则基本确认为此问题触发场景vacuum/vacuum full系统表（pg_class、pg_attribute等）解决方案升级对应8.0\8.1新补丁版本后对系统表做vacuum full操作

随着5G、移动互联网、云计算等新技术的出现，加速了各行各业的数字化转型，传统媒体在新技术的驱动下迎来了新一轮的技术变革。广电媒体行业在采、编、存、管、发各个环节，都迫切需要更专业化、智能化的媒体处理、管理平台，以提高内容生产力。传统媒体“单一渠道采集、封闭式生产、点对面单向传播”的运作模式，向“全媒体汇聚、共平台生产、多渠道分发”的新型传播方式转变。且云平台能够成为标准化、模块化、开放性的业务支撑平台，服务能力灵活组合，可自助调度资源，调整服务策略，业务迁移能够做到平滑无修改。目前，广电行业持续快速发展需要解决以下几个关键需求：存储性能：需要实现海量非结构化文件的存储，并确保存储性能不随文件数增长而性能下降。可扩展性：电视台每天产生的大量节目素材和成片等数据需要存储容量，并要求能够根据业务量可以方便扩展。备份容灾：多媒体内容成为广电行业重要的数字资产，为了应对文件、数据丢失或损坏等可能出现的意外情况，数据需要进行备份容灾。业务应用：传统系统业务流程繁复、单一、适配能力差，重型业务流程无法适应互联网环境下快速、简洁、多样化、高适应性的需求。有孚网络凭借着以北京、上海、深圳为中心，涵盖京津冀、长三角、粤港澳大湾区等重要热点区域的数据中心布局，能够满足融媒体数据管理过程中超大规模的存储需求。针对传统广电传媒行业的转型中的各项IT痛点，分布式结构自带良好的扩展性，支持存储PB级存储容量和千亿级文件数集中管理的有孚专有存储云平台，满足单机故障不影响业务，带伤运行不降速的需求，支持服务与容量双扩展，存储性能随总体容量线性提升，有效解决海量数据的存储和高速计算的问题。有孚网络通过对象存储访问接口将媒体数据安全、快速存储在对象存储中，提供更高的持续读写性能，文件迁移效率以及更高的扩展性。同时，能够在数据处理中完成图片压缩、缩略、裁剪、转格式，及音视频转码、水印、抽帧、拼接等处理。在数据安全方面，有孚专有存储云依托自建数据中心，提供纯物理环境，大大增长了数据的安全保密性。此外，用户无需投入额外的设备或进行特殊的网络配置，直接采用VPN或专线多种组网方式的数据通道建立，通过VPN或专线，可连接云端到用户自有云计算数据中心。不同于传统的文件/块的数据存储，以图片、视频为主的非结构化数据在数据保护方面具有其特性。有孚专有存储云采用分布式存储架构，可跨设备存储、实时数据同步，同时还支持云上两地三中心灾备方案在，主节点系统发生灾难时，容灾系统保障数据安全，保证客户数据万无一失。在保障成本可控的前提下，以CDN、专线、SD-WAN、EIP线路场景化定义网络，提供兼顾专网、公网、云上下的高性能网络，保障从采集、收录，到管理、分发，打破地域限制的高效、安全协作；内容生产商云剪辑服务，与内容服务商视频点播、直播服务场景直接融合，形成视频生产，录制、剪辑、转码，存储管理，分发加速于一体的高效闭环视频服务体系，高效生产快速传播。传统媒体要想更好地发挥自身优势，需要综合利用各方资源，结合云计算及大数据时代的技术创新，走上多元融合的数字化发展之路。有孚网络丰富的云计算数据中心资源、安全的同城/异地灾备方案、完善的分布式环网、资深的客户服务团队，能够为融媒体数据管理提供有效解决方案，有孚网络将持续助力融媒体内容产品升级。

【功能模块】使用canfd通路配置来支持can【操作步骤&问题现象】1、canfd的通路配置可以兼容can，配置canfd 的channel 8为250k接收整车报文，channel 9 为500k 接收摄像头报文，channel 5为500k 向外转发整车部分报文，channel 11为500k 向外转发摄像头报文2、channel 9 接收摄像头频率为100ms 70帧数据，程序中开启了一个发送线程，对报文进行简单处理之后，使用method向channel11发送3、channel 8 接收整车报文频率为100ms 30帧数据，程序中开启了另外的发送线程，对报文进行简单处理之后，使用method向channel 5发送4、程序运行一段时间之后，异常退出另外：文档中指出“CAN下发数据频率最高100Hz”，意思是1s最多发送100帧数据吗？【日志信息】（可选，上传日志内容或者附件）2019/04/20 02:45:42.823489   99047406 002 ECU1 CAN- INTM log info V 2 [setup console output in DLT back-end. return-code: 0]2019/04/20 02:45:42.826178   99047432 000 ECU1 CAN- CM-- log info V 1 [CM version is: 2.43]2019/04/20 02:45:42.827396   99047445 001 ECU1 CAN- CM-- log info V 1 [RT_DDS_URI is set with RT_DDS_URI=/home/mdc/merlin/canfd_abstract/Debug/etc/dds.xml]2019/04/20 02:45:42.827740   99047448 002 ECU1 CAN- CM-- log info V 1 [SOMEIP_CONFIG_FILE is set with SOMEIP_CONFIG_FILE=/home/mdc/merlin/canfd_abstract/Debug/etc/vsomeip.json]2019/04/20 02:46:38.764639   99606817 003 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.861858   99607789 004 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.889568   99608066 005 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.921894   99608389 006 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.931948   99608490 007 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.941968   99608590 008 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.958648   99608757 009 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]2019/04/20 02:46:38.991940   99609090 010 ECU1 CAN- CM-- log warn V 1 [The same sessionId already exists in sessionId list,and the old one will be replaced by new one]。。。。。。。。segmentation fault然后程序异常退出

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的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的线程，正在进行日志同步。那么就继续分析对应线程的工作情况，确认是否为正常现象。