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

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

一.本案例适合什么场景？manager页面无法访问；prestart报错cannot bind to ldap server；二.如何解决1.检查nodeagent进程，误导入了GAUSS_ENV的环境变量2.检查配置文件，存在后台数据库的变量，注释掉，kill nodeagent进程，等待重新拉起后恢复

【问题描述】1. secbox不停重启，UDF进程无法启动，如下cm_agent日志中secbox进程启动日志不停刷新。2.修复secbox启动问题修复后，出现大量关于secbox的挂载点残留，如下为/etc/mtab中关于secbox挂载点的部分记录。【问题分析】1. 查看进程secbox和fenced UDF状态，发现secbox存在，但进程号不断改变，fenced UDF进程不存在2. 查看$GAUSSLOG/cm/cm_agent下cm_agent日志发现，不停打印启动secbox的调用命令3.通过df –h查看磁盘挂载，发现存在与日志目录相关的/var/log挂载，但secbox对应的配置文件$GAUSSHOME/secbox/secbox.conf中只有默认的/var配置，确定问题为secbox默认配置文件和当前系统挂载情况不匹配导致。【问题根因】FI默认环境如下图所示没有单独挂载/var/log，当前环境单独存在/var/log与默认配置文件不匹配，造成secbox异常退出。具体来说Secbox启动的fenced UDF进程需要在日志目录/var/log/Bigdata/mpp/log/gaussdb的下层目录写入日志。而secbox会将系统目录挂载进用户目录下，用户进行写日志操作，当前环境单独挂载有/var/log，而secbox.conf中只存在相关的/var挂载配置，导致在挂载/var/log/Bigdata/mpp/log/gaussdb时，实际会找已挂载上的/var对应磁盘内的文件，而实际的Bigdata目录是在/var/log对应的磁盘下的，无法找到对应的日志目录，造成secbox异常退出。修复完secbox.conf问题后，发现有节点的/etc/mtab中存在大量挂载点残留会导致cpu占用很大，挂载点残留是由于secbox在启动后会依照配置进行挂载，而secbox结束的时候才进行挂载点的清理，如果secbox存在异常结束容易造成secbox已挂载上的挂载点无法清理，造成堆积。当堆积的一定程度就伴随产生占用大量CPU资源现象。【触发条件】系统磁盘挂载与secbox.conf内配置不匹配，具体举例：1. 通过df –h查看，存在/var/log的挂载点2.日志目录在/var/log/Bigdata下，secbox.conf中只有/var的挂载点配置，没有/var/log的配置总结：完整日志路径中存在中间路径(示例中单独挂载的/var/log)被单独挂载，但该中间路径未在secbox.conf中进行配置。

 ForEach ForEach 界面介绍 字段含义字段含义Input Variable Prefix输入变量名的前缀，默认为一个空字符串作为前缀。Start index for loop(exclusive)循环开始的索引不包括此值默认从 1 开始填 0 则起始索引是 1，填 1 则是 2End index for loop(inclusive)循环结束的索引包括此值填 100 则结束索引是 100Output variable输出的变量名在后续循环中，samplers 可使用的变量名Add”_”before number输入变量名和索引之间是否有 _ 间隔不勾选的话，则输入变量名和索引直接相连 ForEach 结合用户自定义变量的栗子线程组树结构 用户自定义变量 ForEach 运行结果 如果输出变量名称为空，需要怎么取循环的值？直接取空即可 ${}  ForEach 不勾选 Add”_”before number 的栗子线程组树结构 用户自定义变量 ForEach 运行结果

 线程组结构树 线程属性 循环控制器 运行结果 

客户端（Jmeter 端）如果通过官网下载的话，就将 JMeterPlugins-Extras.jar 和 JMeterPlugins-Standard.jar 放到  D:\apache-jmeter-5.2.1\lib\ext 然后通过 PerfMon Metrics Collector 监听器进行服务器性能数据显示 服务端（Linux）将 ServerAgent-2.2.3.zip 放到任意目录下，解压unzip ServerAgent-2.2.3.zip 进入 ServerAgent 目录 我提供的 ServerAgent 里面，两个 start 脚本已经是可执行脚本了，直接运行即可./startAgent.sh 运行成功，则会出现下图 如果无法运行，则需要给脚本赋权chmod 777 startAgent.sh 如果是想监控 Window 机器，则将 ServerAgent 放到 Window 电脑的目录下，然后直接双击运行  startAgent.bat 即可 划重点启动 ServerAgent 的前提是系统已安装配置好 Java 环境默认占用端口是 4444 启动 ServerAgent 可能会出现的问题端口被占用杀掉占用 4444 端口的进程先查出 4444 端口是什么进程占用然后查看进程详情，确认是否能杀掉如果可以，则杀掉、 ServerAgent 通过其他端口启动./startAgent.sh --udp-port 0 --tcp-port 1234  端口未对外开放如果服务器开启了防火墙，而且之前没用过 4444 端口，那么该端口很可能会被禁用 阿里云 4444 端口不能对外开放如果是用阿里云服务器，4444 端口是无法对外开放的，所以要通过其他端口来启动 ServerAgent Jmeter 监控服务器全流程一个简单的负载测试线程组结构树一般做负载测试，会监控服务器资源、活动线程数、响应时间、TPS等等，所以加了一堆监听器 

 计数器 计数器界面介绍 字段介绍字段含义Starting value初始值，long 整型，默认 0Increment每次迭代的递增值，默认 0，表示不增加Maximum value最大值，包含此值Number format数字可选格式Exported Variable Name引用名称Track counter independently for rach user每个用户都有一个独立的计数器Reset counter on each Thread Group Iteration每次线程组迭代时计数器将重置为初始值 最基础的栗子只有计数器的情况下的栗子线程组结构树 线程组属性共有 15 个线程，模拟 15 个用户 计数器 运行结果 计数器 + 循环控制器的栗子 线程组属性 循环控制器 计数器 未勾选【与每用户独立的跟踪计数器】的运行结果 勾选【与每用户独立的跟踪计数器】的运行结果 

某局点安装集群初始化集群报错，且重复多次卸载安装均出现问题查看gs_install日志可以看到是pssh远程分发执行LocalQuery脚本报错。可以看到对应的实例在节点上已经被拉起且节点上拉起实例的LocalQuery进程已经结束但是查看执行节点的进程，分发的三个ssh进程仍未退出。现场怀疑是openssh的问题，但是查看ssh -V查看版本是7.4.即Redhat7.5 镜像自带的openssh。客户坚称没有动OS，未做其他加固ssh -V查看也的确是7.4.理论上都在支持列表上不应该出现问题。安装阻塞后，客户最终交代安装后为了解决openssh漏洞问题，使用编译额外安装了openssh8.0.且未卸载openssh7.4.使用openssh8.0启动了sshd。现场卸载了openssh后安装正常。其实是可以在/etc/ssh/sshd_config里看到。现在已经给版本内提需求。现在openssh版本仅支持os原装||版本小于8.0

   字段含义字段含义Filename文件名File encoding文件编码Variable Names变量名称多个变量用 , 分隔Ignore first line忽略首行只在设置了变量名称后才生效Delimiter分隔符默认 , Allow quoted data?是否允许带引号Recycle on EOF?遇到文件结束符EOF 后再次循环Stop thread on EOF?遇到文件结束符EOF 后停止运行线程？Sharing mode线程共享模式后续通过各种栗子来深入理解常用字段的含义 单个字段的栗子csv 测试数据这里用记事本方式当 CSV 数据文件，共有 10 条记录  线程组属性线程数和数据量一致，都是 15 csv 数据文件设置 运行结果  两个字段，共有 10 条记录，最后三条记录有分别有三种引号 csv 数据文件设置线程组结构树和上面栗子差不多一样，线程数仍然 = 15和第一个例子的配置项相反：不忽略首行，允许带引号，遇到文件结束符不再循环 不忽略首行就会把首行的字段名都返回回来，如：1-mobile-age数据有双引号 "" 时，会把双引号忽略掉， '' 单引号不算EOF 是文件结束符，没有开启再次循环时，会直接返回 EOF  可以看到，线程数 = 15，但只有 10 条数据，当跑了 10 个线程后，没有数据了，所以停止运行

用户参数我们通过实际栗子去讲述理论知识点 测试计划树结构 测试计划设置了一个变量 d1 线程组模拟两个用户，各循环五次 线程组下的用户参数只设置了一个参数 d1 HTTP 请求下的用户参数设置了两个参数 d1、d2 HTTP 请求下的用户自定义变量只设置了一个变量 d1 Flask-json 请求 运行结果共发送 10 个请求

 Thread[transport-vert.x-eventloop-thread-2,5,main] has been blocked for 368339 ms, time limit is 2000客户并没有jar的依赖包，排除了edge-core模块导致该问题，麻烦大佬给看下该问题

用户自定义变量我们通过实际栗子去讲述理论知识点 测试计划树结构 测试计划设置了一个变量 d1 线程组模拟两个用户，各循环五次 线程组下的用户自定义变量只设置了一个变量 d1 HTTP 请求下的用户自定义变量设置了两个变量 d1、d2 Flask-json 请求 运行结果共发送 10 个请求

HTTP 请求默认值界面介绍乍眼一看，其实跟 HTTP Request 的界面基本一样，少了一点点东西而已，所以这里就不介绍每个字段的含义了，来说下注意事项 重点HTTP 请求默认值可以直接添加到线程组下面，也可以添加到某个 HTTP 请求下面如果是在线程组下的 HTTP 请求默认值，那么它的作用域就是该线程组下的所有 HTTP 请求，包括子级、孙子级、孙孙子级的 HTTP 请求如果实在某个 HTTP 请求下的 HTTP 请求默认值，那么它的作用域就只针对这个 HTTP 请求线程组的 HTTP 请求默认值的优先级小于HTTP 请求下的 HTTP请求默认值当然啦，所有 HTTP 请求默认值的优先级都比 HTTP 请求低 光理论很难理解，我们来看个栗子 测试计划树结构一个线程组下的 HTTP 请求默认值（1），两个 HTTP 请求下的HTTP 请求默认值（2、3） 第一个 HTTP 请求默认填写的内容设置了：协议、host、端口、编码、参数 第二个 HTTP 请求默认填写的内容设置了：host、端口、路径 第三个 HTTP 请求默认填写的内容设置了：host、编码、参数列表 看看 Flask-json 的请求体和响应体吧 可以看到【2--请求默认值】里设置的host、端口、路径把【1--请求默认值】设置的覆盖掉了又因为【1--请求默认值】设置了编码和参数列表，而【2--请求默认值】没有设置，所以直接拿了【1--请求默认值】的值但有个问题，HTTP 请求本身有设置请求数据（JSON），请求数据是不会被覆盖的，而会把【1--请求默认值】的参数列表和 JSON 数据拼接在一起，拼接后的数据结构是错误的，所以请求会报错即使 HTTP 请求默认值里面设置的是 JSON 数据，也不会合二为一，仍然会报错（如下图） 看看图片文件上传接口的请求体和响应体吧 可以看到【2--请求默认值】里设置的host、编码把【1--请求默认值】设置的覆盖掉了而这个 HTTP请求的请求数据是也是参数列表形式传参的，这样就可以拼接成功了最终会把两个请求默认值的参数列表拼接起来再传递，即使参数名一样，仍然会分开传，而不是覆盖参数值（可见下面的扩展小栗子） 总结HTTP 请求所需的各种字段值（host、端口、编码、请求数据等等），取值的顺序（优先级）是：HTTP 请求本身设置的值HTTP 请求下的 HTTP 请求默认值设置的值线程组下的 HTTP 请求默认值设置的值

系统：4.19.36-vhulk1907.1.0.h748.eulerosv2r8.aarch64问题描述：我的kafka服务一个启动脚本在/etc/rc.d/init.d/中，为s1；另一个启动脚本在kafka安装目录中，为s2。其中s2相当于调用了s1现象，系统设置了max open files为65536后，在命令行中不管直接执行s1还是s2,启动kafka后，查看/proc/$pid/limits中的Max open files都是设置好的65536,但是，如果在/etc/crontab中加入了*  *  *  *  * root  /xxxxx/xxxx/s2后，由crontab中启动的kafka查看/proc/$pid/limits总是4096在普通的centos中测试时候一切正常，没有这种现象。请问：鲲鹏中的这种现象如何解决？