>摘要：云服务环境下，如何解决客户基于大量数据创建索引的性能问题，成为云服务厂商的一个挑战。华为云GaussDB(for MySQL)通过引入并行创建索引技术，很好地解决了批量索引创建和临时添加索引等性能瓶颈问题，帮助用户更快建立好索引。想要进一步了解快速创建索引的秘诀，请不要错过本文。本文分享自华为云社区[《GaussDB(for MySQL)如何快速创建索引？华为云数据库资深架构师为您揭秘》](https://bbs.huaweicloud.com/blogs/300350?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=database&utm_content=content)，作者：华为云数据库资深架构师苏斌。  苏斌，华为云数据库资深架构师，拥有16年数据库内核研发经验，之前作为MySQL官方InnoDB团队主要研发人员，参与和主导了多个重要特性的开发和发布。目前在华为公司负责和参与华为云RDS主要产品RDS for MySQL和GaussDB(for MySQL)内核功能的设计和研发。 # 导读 云服务环境下，如何解决客户基于大量数据创建索引的性能问题，成为云服务厂商的一个挑战。华为云GaussDB(for MySQL)通过引入并行创建索引技术，很好地解决了批量索引创建和临时添加索引等性能瓶颈问题，帮助用户更快建立好索引。想要进一步了解快速创建索引的秘诀，请不要错过本文。 # 关于MySQL索引 我们都知道，数据库使用索引技术加快数据的查询。MySQL数据库也支持若干种索引结构提高查询的性能（参见MySQL文档：https://dev.mysql.com/doc/refman/8.0/en/create-index.html），其中使用最广泛的是B+tree索引，因为B+tree索引在查询和修改的性能之间有很好的平衡，同时其存储和维护的代价也是比较优的。 MySQL的表本身由聚簇索引（必须是B+tree索引）表示，再加上若干个二级索引，包括B+tree索引，共同组成一个MySQL的独立表，可以说MySQL的表是由一组索引共同组成的。我们都知道索引是一把双刃剑，充分的索引可以更好地提升可以适配的查询的性能，但是需要维护这些索引使得其和数据同步，所以在数据修改操作阶段，更多的索引也会带来更高的开销。索引创建与否的权衡通常是动态的，用户不一定能做到在表定义之初就知道需要建立哪些索引，需要随着业务的发展变化而调整索引，这也带来了动态索引创建的一些问题。 # MySQL的索引创建逻辑 我们先看一下MySQL索引创建的逻辑。首先，MySQL索引的创建可以使用两种不同的DDL（Data Definition Language: 数据定义语言）算法来实现。第一种是COPY算法，它非常低效，就是在两个表之间进行数据拷贝，来完成表结构相关的修改，尤其是它要求加表锁，现在基本不使用了。第二种是INPLACE算法，该算法不要求加锁，因此很多DDL操作是不阻塞DML（Data Manipulation Language: 数据操纵语句）操作的，比如创建索引。该算法具体的实现在存储引擎层面完成，可以进行更多的优化。实际上DDL语句还有一种INSTANT算法，但是它无法支持创建索引操作，这里不展开介绍。 对于INPLACE算法，在5.7版本之前，是采用索引记录不断地向建好的空索引插入的方式。由于插入的数据的无序性，该方法导致了明显的性能问题和潜在的空间浪费。在5.7版本以后，MySQL优化了建索引步骤，将其改进为对已排序的索引记录进行自底向上批量插入并且紧凑拼装的创建方式，如果有多个索引要创建，会单独对每个索引执行相同的算法。新的算法会经历读取数据、排序数据和创建索引这几个主要步骤。 总体而言，创建索引这类DDL操作，会比普通的DML等操作要费时，而该类DDL耗时会导致用户在继续动态添加索引加速查询的时候，需要等待很长的时间，极大影响业务；而且用户的MySQL实例开启了Binlog复制，耗时的DDL操作容易引起备库的长时间落后。  MySQL的创建索引流程图 # 云化场景下索引创建的问题 随着越来越多用户把数据托管在云服务上，以及用户数据量的不断增长，前述的动态添加索引导致的问题非常影响用户体验。同时客户的单表数据逐渐达到几TB甚至几十TB，客户对创建索引太慢所带来的性能问题的抱怨越来越多，尤其是创建索引周期如果太长，我们可能很难找到一段合适的业务低峰期来动态创建索引，避免业务的波动。因此，如何在云服务环境下，解决客户基于大量数据创建索引的性能问题，成为云服务厂商的一个挑战。 在云化场景下，还有一个主要场景对客户的体验非常重要。我们知道客户的业务要迁移上云，需要对数据进行大规模的迁移（华为云提供了数据复制服务DRS工具支持各类数据迁移场景），数据迁移比较高效的方式为： 1. 逻辑导出源端数据 2. 在目标端建表（注意，表不含二级索引） 3. 将源端导出的数据插入到目标端 4. 对目标端的表建立二级索引 如果涉及动态数据同步，相关步骤会更复杂一些，由于和该主题无关，这里不展开。以上步骤中，需要重点注意的是步骤2和4，在目标端创建表的时候先不创建二级索引。这个优化对性能影响很大，尤其是一个表有很多二级索引的场景。我们知道Btree索引的插入如果是有序的，对插入性能和结果的空间利用率是最好的，因为Btree索引的分裂会在插入区域的尾部产生，同时由于分裂算法的优化，分裂产生的页面填充率会比较高；相反地，如果是随机插入，尤其是并发地随机插入，很容易导致Btree索引在不同的节点进行分裂，并且分裂后的页面填充率都处于一个半满的状态，导致Btree最终的一个膨胀。 有了这个背景之后，我们就容易理解上面的问题，插入表数据的时候，我们屏蔽了二级索引，等所有数据都准备好了，再采用批量建立索引的方式创建二级索引，这对于二级索引创建效率是最高的。如果不这么做，每插入一条记录，就要去插入相应的二级索引，那么二级索引就是一个无序的随机插入，并发起来性能会变差很多。 虽然在数据同步准备好后，批量创建二级索引是一个有效的方案，但是如果数据量很大，这么创建二级索引还是非常耗时，导致客户在数据迁移完之后需要等待很长时间才能开展业务，这个等待周期可能是小时甚至天级别的。虽然可以考虑表级别的并发创建索引，但是这个方法也有明显的缺点：应用场景有限，要求有多表；以及表和表之间的并发其实不是一个最有效的并发形式，相互影响比较大。 # GaussDB(for MySQL)如何快速创建索引？ 综上所述，在创建索引这个点上存在两个性能瓶颈点：一个是用户迁移数据之后的批量索引创建；第二个是用户临时需要添加一个二级索引。无论哪个点，我们都需要更快的建立好索引，提升用户的使用体验。 华为云GaussDB(for MySQL)引入了**并行创建索引的技术**，它改进了社区版MySQL创建索引只用单线程的问题，以此提高创建索引的效率，并一起解决了前述两个痛点。前面提到的社区版创建索引逻辑是单线程的，首先存在资源利用率不够饱满的问题；其次创建索引过程是CPU和IO开销交替进行的过程，在做一个操作的时候，即使不是资源竞争的操作也只有等待。多线程创建索引可以充分利用CPU和IO资源，同时有的线程在做CPU计算时，别的线程可以并发的做IO操作。 GaussDB(for MySQL)使用的并行创建索引，是一个全链路的并行技术。前面提到，创建索引包含了若干个阶段，我们的并行创建算法，对这里的每个阶段都做并行处理，从读取数据、排序、到创建索引，都是并行操作，每一步都由指定的N个线程并发处理。它的逻辑如下图所示：  GaussDB(for MySQL)尤其对数据的归并排序做了多种优化，使得我们常规的归并排序能够充分的并行，充分利用CPU、内存和IO的资源。在并行创建索引之后的合并步骤，也使用了一套简化的算法，正确处理各种索引结构的场景。 # 支持的索引和场景 GaussDB(for MySQL)的并行创建索引功能，目前支持的索引为Btree二级索引。对于virtual index二级索引，将会在不久的将来提供全面的支持，而MySQL的spatial index和fulltext index不在该并行创建索引覆盖范围内。 特别要注意的是，主键索引的创建目前也是不支持并行的，因此如果一个并行创建索引的SQL语句包含创建主键索引，或者前面提及的spatial index与fulltext index，那么客户端将会收到一个告警，提示该操作不支持并行创建索引，同时该语句会采用单线程创建索引的方式执行完成。 从SQL语句的角度，如前所述，创建索引可以采用不同的算法，由于COPY算法（ALGORITHM=COPY）不是采用批量插入的方式，因此不会受益于该并行创建索引优化。而对于INPLACE算法，如果创建索引用的是非rebuild的方式，都可以受益于该优化；一旦需要使用rebuild的方式创建索引，因为涉及到主键索引的建立，将无法使用并行创建索引的算法。 # 示例 下面我们通过几个实例来了解一下如何使用并行创建索引算法加快创建速度，以及我们的条件约束是如何生效的。 1、我们使用sysbench的表，表内有1亿条数据  2、在该表的k字段建索引，采用社区默认单线程，耗时146.82s  3、通过设置innodb_rds_parallel_index_creation_threads = 4启用4个线程建索引，可以看到建索引耗时38.72s，速度提升3.79倍。  4、假设我们要修改主键索引，虽然指定了多线程，但是会收到一个warning，实际上只能通过单线程建索引  # 注意事项 首先对innodb_rds_parallel_index_creation_threads这个参数进行一下说明，它控制了系统中所有并行DDL可以使用的总线程数，取值范围是[1-128]。该参数取值为1表示使用原始的单线程创建索引，取值为N，表示接下来的DDL使用N个线程创建。如果一个DDL使用了100个线程在执行，那么另外一个也要使用并行的DDL且最多只能使用剩下的28个线程；而如果128个线程都被并行DDL语句占用了，新来的DDL只能走原始的单线程创建的逻辑。 虽然该并行创建索引加快了索引的创建速度，但是在具体使用场景下，还是需要有审慎的评估。我们知道在并行算法应用之后，该DDL对硬件资源的使用会尽可能的充分，这也意味着其它操作就得不到太多的资源了。因此，针对不同的场景需要具体地分析，它决定了我们如何创建索引。 对于迁移场景，由于这时候还没有任何业务接入，用户希望尽快完成所有索引的创建，因此可以尽量设置多线程数，比如我们是16核规格的实例，那么我们就可以把并行线程的数量指定为16，加速完成操作。 如果是用户业务运行阶段要创建索引，我们还是不希望DDL操作，对正在运行的业务如DML操作等有太多的影响。因此，这时候创建索引可以指定相对少一些的线程数量，比如2-4（或者根据CPU规格以及负载决定，同时不鼓励并发地执行多个DDL操作）。这样既能相对地加速创建索引的进程，也能保证DML的正常进行。 综上所述，GaussDB(for MySQL)支持了并行创建索引，通过缩短创建索引使用的时间，很好地解决了客户关切的两类问题，提升了客户的体验。但技术无止境，在创建索引领域，还有其它的问题需要我们优化解决，例如如何减少创建索引步骤对IO的影响等等。我们后续会针对这些点进行优化，给客户带来更多的惊喜。 目前，华为云GaussDB(for MySQL) 并行创建索引优化功能已上线，欢迎大家前往华为云官网体验：https://www.huaweicloud.com/product/gaussdb_mysql.html

1. 找到系统当前所有的端口使用 netstat 命令查找本机各端口的网络连接情况~]netstat -nulpt #结果如下Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address           Foreign Address         Statetcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:1997            0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTENtcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTENtcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTENtcp6       0      0 :::80                   :::*                    LISTENtcp6       0      0 :::22                   :::*                    LISTENtcp6       0      0 ::1:25                  :::*                    LISTENtcp6       0      0 :::3306                 :::*                    LISTEN这里我们要找的是 80与443 端口2. 找到对应端口在系统中的进程 ID(PID)依据查找到的 1997 端口找到对应进程, lsof -i :1997, 注意 : 冒号不要漏掉了lsof -i:80 #结果如下COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAMEtke-gatew 6360 root   10u  IPv6 6410452      0t0  TCP *:http (LISTEN)[root@VM-0-114-centos ~]# lsof -i:443COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAMEtke-gatew  7627 root    9u  IPv6 7717644      0t0  TCP *:https (LISTEN).........->172.80.31.2:https (ESTABLISHED)galaxy    25638 root    8u  IPv4 6276795      0t0  TCP  <机密省略>:57802-..........3. 使用 kill -9 [PID] 命令结束进程通过 lsof 命令我们找到了进程的 PID: 29416,接下来就是使用 kill -9 [PID] 把进程结束就好了kill -9 6360kill -9 25638kill -9 7627到这里就 OK 了，不过为了保险起见，再次执行 netstat -tln 确认是否结束了端口占用 前情提要在布置k8s的时候发现容器报错如~]kubectl get pods -A -o wide.....pot   nginx-ingress-nginx-ingress-85d747cfb4-9hk72   0/1   CrashLoopBackOff.....然后想describe查看了一下报错如下~]kubectl describe pod -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72......... Warning  BackOff  3m14s (x613 over 137m)  kubelet  Back-off restarting failed container最后logs查看发现端口被占用~]# kubectl logs pods -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72Error from server (NotFound): pods "pods" not found[root@VM-0-114-centos ~]# kubectl logs  -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72I1104 10:51:46.738108       1 main.go:169] Starting NGINX Ingress controller Version=1.6.3 GitCommit=b9378d562021/11/04 10:51:46 [emerg] 19#19: bind() to 0.0.0.0:80 failed (98: Address already in use)nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)2021/11/04 10:51:46 [emerg] 19#19: bind() to 0.0.0.0:443 failed (98: Address already in use).......2021/11/04 10:51:46 [notice] 19#19: try again to bind() after 500ms2021/11/04 10:51:46 [emerg] 19#19: still could not bind()nginx: [emerg] still could not bind()运用了以上步骤之后回复正常pot   nginx-ingress-nginx-ingress-85d747cfb4-9hk72   1/1     Running

MRS 服务关于Apache log4j远程代码执行漏洞排查及紧急修复声明一、漏洞情况简介Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。该漏洞影响范围广，漏洞危害大，请尽快采取安全措施，阻止漏洞攻击事件的发生。二、MRS服务受影响的大数据组件HiveLoaderFlinkSparkManager(Tomcat)三、MRS集群侧组件修复指引1. 主备节点文件修复1）登录MRS集群主备节点2）在主备节点上分别按照如下步骤进行文件修复         a. 执行如下命令进行修复前状态检查：su - ommfind /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;对应版本的jar包中是否存在引发问题class文件执行备份操作find /opt -name "log4j-core-2.8.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.8.2.jar_bak; donefind /opt -name "log4j-core-2.6.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.6.2.jar_bak; done查看是否备份成功find /opt -name log4j-core*.jar_bak -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;        b. 执行如下命令进行问题文件修复find /opt -name log4j-core-2.8.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;find /opt -name log4j-core-2.6.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;出现如图报错无影响，只是表示对应目录的文件不存在异常问题文件           c. 执行如下命令进行修复后文件检查：find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件。若出现异常需要进行如下回滚操作 find /opt -name "log4j-core-2.8.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.8.2.jar; done find /opt -name "log4j-core-2.6.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.6.2.jar; done执行如下命令检查是否回滚成功find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;3）MRS Manager Tomcat重启生效登录MRS集群主节点查询tomcat进程ps -ef | grep apache-tomcat kill掉进程  kill -9 xxxx，等待自动拉起【启动期间Manager页面无法访问1-3分钟】查询tomcat进程是否被拉起 ps -ef | grep apache-tomcat4） MRS Controller重启生效登录MRS集群主节点查询controller进程ps -ef | grep ControllerServicekill掉进程  kill -9 xxxx，等待自动拉起【启动期间Manager页面无法访问1-3分钟】查询tomcat进程是否被拉起 ps -ef | grep ControllerService5） MRS executor重启生效登录MRS集群主节点查询executor进程ps -ef | grep executorkill掉进程  kill -9 xxxx，等待自动拉起查询tomcat进程是否被拉起 ps -ef | grep executor 2. 大数据组件修复参照第二节涉及组件范围，对当前集群已安装的组件依次进行修复。修复文件后尽量使用滚动重启，以减少对业务的影响，下面以Hive组件为例，其他组件操作方法类似。     1) 集群节点文件修复到主机管理找到集群节点，登陆所有集群节点        a. 执行如下命令进行修复前状态检查：su - ommfind /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;对应版本的jar包中是否存在引发问题class文件执行备份操作find /opt -name "log4j-core-2.8.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.8.2.jar_bak; donefind /opt -name "log4j-core-2.6.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.6.2.jar_bak; done查看是否备份成功find /opt -name log4j-core*.jar_bak -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;        b. 执行如下命令进行问题文件修复find /opt -name log4j-core-2.8.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;find /opt -name log4j-core-2.6.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;出现如图报错无影响，只是表示对应目录的文件不存在异常问题文件           c. 执行如下命令进行修复后文件检查：find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件。若出现异常需要进行如下回滚操作 find /opt -name "log4j-core-2.8.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.8.2.jar; done find /opt -name "log4j-core-2.6.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.6.2.jar; done执行如下命令检查是否回滚成功find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件完成以后到manager重启各组件服务（除TEZ）     2) 组件服务修复重启生效登录Manager进入服务管理页面，选中所有实例，选择滚动重启。其他服务参考Hive操作进行重启即可

MRS 服务关于Apache log4j远程代码执行漏洞排查及紧急修复声明一、漏洞情况简介Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。该漏洞影响范围广，漏洞危害大，请尽快采取安全措施，阻止漏洞攻击事件的发生。二、MRS服务受影响的大数据组件HiveLoaderFlinkSparkManager(Tomcat)Tez三、MRS集群侧组件修复指引1. 主备节点文件修复1）登录MRS集群主备节点2）在主备节点上分别按照如下步骤进行文件修复         a. 执行如下命令进行修复前状态检查：su - ommfind /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;对应版本的jar包中是否存在引发问题class文件执行备份操作find /opt -name "log4j-core-2.8.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.8.2.jar_bak; donefind /opt -name "log4j-core-2.6.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.6.2.jar_bak; done查看是否备份成功find /opt -name log4j-core*.jar_bak -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;        b. 执行如下命令进行问题文件修复find /opt -name log4j-core-2.8.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;find /opt -name log4j-core-2.6.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;出现如图报错无影响，只是表示对应目录的文件不存在异常问题文件           c. 执行如下命令进行修复后文件检查：find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件。若出现异常需要进行如下回滚操作 find /opt -name "log4j-core-2.8.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.8.2.jar; done find /opt -name "log4j-core-2.6.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.6.2.jar; done执行如下命令检查是否回滚成功find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \; 3）MRS Manager Tomcat重启生效登录MRS集群主节点查询tomcat进程ps -ef | grep apache-tomcatkill掉进程  kill -9 xxxx，等待自动拉起【启动期间Manager页面无法访问1-3分钟】查询tomcat进程是否被拉起 ps -ef | grep apache-tomcat4） MRS Controller重启生效登录MRS集群主节点查询controller进程ps -ef | grep ControllerServicekill掉进程  kill -9 xxxx，等待自动拉起【启动期间Manager页面无法访问1-3分钟】查询tomcat进程是否被拉起 ps -ef | grep ControllerService5） MRS executor重启生效登录MRS集群主节点查询executor进程ps -ef | grep executorkill掉进程  kill -9 xxxx，等待自动拉起查询tomcat进程是否被拉起 ps -ef | grep executor 2. 大数据组件修复参照第二节涉及组件范围，对当前集群已安装的组件依次进行修复。修复文件后尽量使用滚动重启，以减少对业务的影响，下面以Hive组件为例，其他组件操作方法类似。     1) 集群节点文件修复到主机管理找到集群节点，登陆所有集群节点        a. 执行如下命令进行修复前状态检查：su - ommfind /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;对应版本的jar包中是否存在引发问题class文件执行备份操作find /opt -name "log4j-core-2.8.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.8.2.jar_bak; donefind /opt -name "log4j-core-2.6.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.6.2.jar_bak; done查看是否备份成功find /opt -name log4j-core*.jar_bak -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;        b. 执行如下命令进行问题文件修复find /opt -name log4j-core-2.8.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;find /opt -name log4j-core-2.6.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;出现如图报错无影响，只是表示对应目录的文件不存在异常问题文件           c. 执行如下命令进行修复后文件检查：find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件。若出现异常需要进行如下回滚操作 find /opt -name "log4j-core-2.8.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.8.2.jar; done find /opt -name "log4j-core-2.6.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.6.2.jar; done执行如下命令检查是否回滚成功find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件完成以后到manager重启各组件服务（除TEZ）     2) 组件服务修复重启生效        a. 登录Manager进入Hive服务管理页面，选中所有实例，选择滚动重启。        其他服务参考Hive操作进行重启即可(除Tez和Hive的WebHcat实例外)        b. Tez服务更新服务配置修复重启生效            i. 在Manager页面Tez组件全部配置中，搜索OPTS配置，在TEZUI_GC_OPTS中内容末尾添加 -Dlog4j2.formatMsgNoLookups=true【注意与前参数有空格】            ii. 点击保存配置，滚动重启Tez。            iii. 在对应实例后台查看进程 ps -ef|grep tez|grep formatMasNoLookups  ,查看参数已生效。       c. Hive WebHcat实例修复          i. 从华为maven镜像库https://mirrors.huaweicloud.com/repository/maven/ 中下载如下jar包https://mirrors.huaweicloud.com/artifactory/maven-public/org/apache/logging/log4j/log4j-api/2.10.0/log4j-api-2.10.0.jarhttps://mirrors.huaweicloud.com/artifactory/maven-public/org/apache/logging/log4j/log4j-core/2.10.0/log4j-core-2.10.0.jarhttps://mirrors.huaweicloud.com/artifactory/maven-public/org/apache/logging/log4j/log4j-slf4j-impl/2.10.0/log4j-slf4j-impl-2.10.0.jarhttps://mirrors.huaweicloud.com/artifactory/maven-public/org/apache/logging/log4j/log4j-web/2.10.0/log4j-web-2.10.0.jarhttps://mirrors.huaweicloud.com/artifactory/maven-public/org/apache/logging/log4j/log4j-1.2-api/2.10.0/log4j-1.2-api-2.10.0.jarhttps://mirrors.huaweicloud.com/artifactory/maven-public/com/lmax/disruptor/3.3.6/disruptor-3.3.6.jar登录webhcat所在节点su - ommcd /opt/Bigdata/MRS_1.9.3/install/FusionInsight-Hive-2.3.3/hive/lib/ mv log4j-api-2.6.2.jar log4j-api-2.6.2.jar_bakmv log4j-1.2-api-2.6.2.jar log4j-1.2-api-2.6.2.jar_bakmv log4j-slf4j-impl-2.6.2.jar log4j-slf4j-impl-2.6.2.jar_bakmv log4j-web-2.6.2.jar log4j-web-2.6.2.jar_bakmv disruptor-3.3.0.jar disruptor-3.3.0.jar_bak执行命令修改文件权限chmod 777 log4j-core-2.10.0.jarchown omm:wheel log4j-core-2.10.0.jarchmod 777 log4j-api-2.10.0.jarchown omm:wheel log4j-api-2.10.0.jarchmod 777 log4j-1.2-api-2.10.0.jarchown omm:wheel log4j-1.2-api-2.10.0.jarchmod 777 log4j-slf4j-impl-2.10.0.jarchown omm:wheel log4j-slf4j-impl-2.10.0.jarchmod 777 log4j-web-2.10.0.jarchown omm:wheel log4j-web-2.10.0.jarchmod 777 disruptor-3.3.6.jarchown omm:wheel disruptor-3.3.6.jari. 在Manager页面Hive组件WEBHCAT角色服务配置中，搜索OPTS配置，在WEBHCAT_GC_OPTS中内容末尾添加 -Dlog4j2.formatMsgNoLookups=true【注意与前参数有空格】点击保存配置，滚动重启webHCat。在对应实例后台查看进程 ps -ef|grep webhcat,查看参数已生效。

MRS 服务关于Apache log4j远程代码执行漏洞排查及紧急修复声明一、漏洞情况简介Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架，并且引入了大量丰富的特性。该日志框架被大量用于业务系统开发，用来记录日志信息。大多数情况下，开发者可能会将用户输入导致的错误信息写入日志中。此次漏洞触发条件为只要外部用户输入的数据会被日志记录，即可造成远程代码执行。该漏洞影响范围广，漏洞危害大，请尽快采取安全措施，阻止漏洞攻击事件的发生。二、MRS服务受影响的大数据组件HiveLoaderFlinkSparkManager(Tomcat)TezImpala三、MRS集群侧组件修复指引1. 主备节点文件修复1）登录MRS集群主备节点2）在主备节点上分别按照如下步骤进行文件修复         a. 执行如下命令进行修复前状态检查：su - ommfind /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;对应版本的jar包中是否存在引发问题class文件执行备份操作find /opt -name "log4j-core-2.8.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.8.2.jar_bak; donefind /opt -name "log4j-core-2.6.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.6.2.jar_bak; done查看是否备份成功find /opt -name log4j-core*.jar_bak -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;        b. 执行如下命令进行问题文件修复find /opt -name log4j-core-2.8.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;find /opt -name log4j-core-2.6.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;出现如图报错无影响，只是表示对应目录的文件不存在异常问题文件           c. 执行如下命令进行修复后文件检查：find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件。若出现异常需要进行如下回滚操作 find /opt -name "log4j-core-2.8.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.8.2.jar; done find /opt -name "log4j-core-2.6.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.6.2.jar; done执行如下命令检查是否回滚成功find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \; 3）MRS Manager Tomcat重启生效登录MRS集群主节点查询tomcat进程ps -ef | grep apache-tomcatkill掉进程  kill -9 xxxx，等待自动拉起【启动期间Manager页面无法访问1-3分钟】查询tomcat进程是否被拉起 ps -ef | grep apache-tomcat4） MRS Controller重启生效登录MRS集群主节点查询controller进程ps -ef | grep ControllerServicekill掉进程  kill -9 xxxx，等待自动拉起【启动期间Manager页面无法访问1-3分钟】查询tomcat进程是否被拉起 ps -ef | grep ControllerService5） MRS executor重启生效登录MRS集群主节点查询executor进程ps -ef | grep executorkill掉进程  kill -9 xxxx，等待自动拉起查询tomcat进程是否被拉起 ps -ef | grep executor 2. 大数据组件修复参照第二节涉及组件范围，对当前集群已安装的组件依次进行修复。修复文件后尽量使用滚动重启，以减少对业务的影响，下面以Hive组件为例，其他组件操作方法类似。     1) 集群节点文件修复到主机管理找到集群节点，登陆所有集群节点        a. 执行如下命令进行修复前状态检查：su - ommfind /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;对应版本的jar包中是否存在引发问题class文件执行备份操作find /opt -name "log4j-core-2.8.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.8.2.jar_bak; donefind /opt -name "log4j-core-2.6.2.jar" | while read name;do newname=$(dirname $name) ;cp $name $newname/log4j-core-2.6.2.jar_bak; done查看是否备份成功find /opt -name log4j-core*.jar_bak -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;        b. 执行如下命令进行问题文件修复find /opt -name log4j-core-2.8.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;find /opt -name log4j-core-2.6.2.jar -exec zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class \;出现如图报错无影响，只是表示对应目录的文件不存在异常问题文件           c. 执行如下命令进行修复后文件检查：find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件。若出现异常需要进行如下回滚操作 find /opt -name "log4j-core-2.8.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.8.2.jar; done find /opt -name "log4j-core-2.6.2.jar_bak" | while read name;do newname=$(dirname $name) ;mv $name $newname/log4j-core-2.6.2.jar; done执行如下命令检查是否回滚成功find /opt -name log4j-core*.jar -exec grep -Rn org/apache/logging/log4j/core/lookup/JndiLookup.class {} \;所有log4j-core-2.8.2.jar和log4j-core-2.6.2.jar中已不存在问题文件完成以后到manager重启各组件服务（除TEZ）     2) 组件服务修复重启生效        a. 登录Manager进入Hive服务管理页面，选中所有实例，选择滚动重启。        其他服务参考Hive操作进行重启即可(除Tez外)        b. Tez服务更新服务配置修复重启生效            i. 在Manager页面Tez组件全部配置中，搜索OPTS配置，在TEZUI_GC_OPTS中内容末尾添加 -Dlog4j2.formatMsgNoLookups=true【注意与前参数有空格】            ii. 点击保存配置，滚动重启Tez。            iii. 在对应实例后台查看进程 ps –ef|grep tez,查看参数已生效。

如题，好像 npu-smi info 命令和 Ascend-DMI 工具都不能查看当前每个推理卡，或者具体到每个chip上有哪些进程正在运行；请问有别的工具能够查看这个信息吗？

MindSpore Federated Learning Server集群物理架构如图所示：如上图所示，在联邦学习云侧集群中，有两种角色的MindSpore进程：Federated Learning Scheduler和Federated Learning Server:Federated Learning SchedulerScheduler的作用主要有两点：协助集群组网：在集群初始化阶段，由Scheduler负责收集Server信息，并达成集群一致性。`开放管理面：支持用户通过RESTful接口对集群进行管理。在一个联邦学习任务中，只有一个Scheduler，与Server通过TCP协议通信。Federated Learning ServerServer为执行联邦学习任务的主体，用于接收和解析来自端侧设备的数据，具有执行安全聚合、限时通信、模型存储等能力。在一个联邦学习任务中，Server可以有多个(用户可配置)，Server间通过TCP协议通信，对外开放HTTP端口用于端侧设备连接。在MindSpore联邦学习框架中，Server还支持弹性伸缩以及容灾，能够在训练任务不中断的情况下，动态调配硬件资源。Scheduler和Server需部署在单网卡的服务器或者容器中，且处于相同网段。MindSpore自动获取首个可用IP地址作为Server地址。参数配置MindSpore联邦学习任务进程复用了训练脚本，用户只需要使用相同的脚本，并通过Python接口set_fl_context传递不同的参数，启动不同角色的MindSpore进程在确定参数配置后，用户需要在执行训练前调用set_fl_context接口，调用方式如下：代码如下：import mindspore.context as contextenable_fl = Trueserver_mode = "FEDERATED_LEARNING"ms_role = "MS_SERVER"server_num = 4scheduler_ip = "192.168.216.124"scheduler_port = 6667fl_server_port = 6668fl_name = "LeNet"scheduler_manage_port = 11202config_file_path = "./config.json"fl_ctx = {"enable_fl": enable_fl,"server_mode": server_mode,"ms_role": ms_role,"server_num": server_num,"scheduler_ip": scheduler_ip,"scheduler_port": scheduler_port,"fl_server_port": fl_server_port,"fl_name": fl_name,"scheduler_manage_port": scheduler_manage_port,"config_file_path": config_file_path}context.set_fl_context(**fl_ctx)model.train()建议将参数配置通过Python argparse模块传入，以下是部分关键参数传入脚本的示例：代码如下：import argparseparser = argparse.ArgumentParser()parser.add_argument("--server_mode", type=str, default="FEDERATED_LEARNING")parser.add_argument("--ms_role", type=str, default="MS_SERVER")parser.add_argument("--server_num", type=int, default=4)parser.add_argument("--scheduler_ip", type=str, default="192.168.216.124")parser.add_argument("--scheduler_port", type=int, default=6667)parser.add_argument("--fl_server_port", type=int, default=6668)parser.add_argument("--fl_name", type=str, default="LeNet")parser.add_argument("--scheduler_manage_port", type=int, default=11202)parser.add_argument("--config_file_path", type=str, default="")args, t = parser.parse_known_args()server_mode = args.server_modems_role = args.ms_roleserver_num = args.server_numscheduler_ip = args.scheduler_ipscheduler_port = args.scheduler_portfl_server_port = args.fl_server_portfl_name = args.fl_namescheduler_manage_port = args.scheduler_manage_portconfig_file_path = args.config_file_path启动集群代码如下：mobile/├── config.json├── finish_mobile.py├── run_mobile_sched.py├── run_mobile_server.py├── src│ └── model.py└── test_mobile_lenet.py要注意的是：config.json：配置文件，用于安全能力配置，容灾等。finish_mobile.py：由于Server集群为常驻进程，使用本文件手动退出集群。run_mobile_sched.py：启动Scheduler。run_mobile_server.py：启动Server。model.py：网络模型。test_mobile_lenet.py：训练脚本启动Schedulerrun_mobile_sched.py是为用户启动Scheduler而提供的Python脚本，并支持通过argparse传参修改配置。执行指令如下，代表启动本次联邦学习任务的Scheduler，其TCP端口为6667，联邦学习HTTP服务端口为6668，Server数量为4个，集群Scheduler管理端口为11202：python run_mobile_sched.py --scheduler_ip=192.168.216.124 --scheduler_port=6667 --fl_server_port=6668 --server_num=4 --scheduler_manage_port=11202启动Serverrun_mobile_server.py是为用户启动若干Server而提供的Python脚本，并支持通过argparse传参修改配置。执行指令如下，代表启动本次联邦学习任务的Server，其TCP端口为6667，联邦学习HTTP服务起始端口为6668，Server数量为4个，联邦学习任务正常进行需要的端侧设备数量为8个：python run_mobile_server.py --scheduler_ip=192.168.216.124 --scheduler_port=6667 --fl_server_port=6668 --server_num=4 --start_fl_job_threshold=8若想让Server分布式部署在不同物理节点，可以使用local_server_num参数，代表在本节点需要执行的Server进程数量：# 在节点1启动3个Server进程python run_mobile_server.py --scheduler_ip=192.168.216.124 --scheduler_port=6667 --fl_server_port=6668 --server_num=4 --start_fl_job_threshold=8 --local_server_num=3# 在节点2启动1个Server进程python run_mobile_server.py --scheduler_ip=192.168.216.124 --scheduler_port=6667 --fl_server_port=6668 --server_num=4 --start_fl_job_threshold=8 --local_server_num=1停止联邦学习 当前版本联邦学习集群为常驻进程，也可以执行finish_mobile.py脚本用于中途停止联邦学习服务器，执行如下指令来停止联邦学习集群，其中scheduler_port传参和启动服务器时的传参保持一致，代表停止此Scheduler对应的集群。python finish_mobile.py --scheduler_port=6667可看到如下结果：

1. 找到系统当前所有的端口使用 netstat 命令查找本机各端口的网络连接情况~]netstat -nulpt #结果如下Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address           Foreign Address         Statetcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:1997            0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTENtcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTENtcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTENtcp6       0      0 :::80                   :::*                    LISTENtcp6       0      0 :::22                   :::*                    LISTENtcp6       0      0 ::1:25                  :::*                    LISTENtcp6       0      0 :::3306                 :::*                    LISTEN这里我们要找的是 80与443 端口2. 找到对应端口在系统中的进程 ID(PID)依据查找到的 1997 端口找到对应进程, lsof -i :1997, 注意 : 冒号不要漏掉了lsof -i:80 #结果如下COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAMEtke-gatew 6360 root   10u  IPv6 6410452      0t0  TCP *:http (LISTEN)[root@VM-0-114-centos ~]# lsof -i:443COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAMEtke-gatew  7627 root    9u  IPv6 7717644      0t0  TCP *:https (LISTEN).........->172.80.31.2:https (ESTABLISHED)galaxy    25638 root    8u  IPv4 6276795      0t0  TCP  <机密省略>:57802-..........3. 使用 kill -9 [PID] 命令结束进程通过 lsof 命令我们找到了进程的 PID: 29416,接下来就是使用 kill -9 [PID] 把进程结束就好了kill -9 6360kill -9 25638kill -9 7627到这里就 OK 了，不过为了保险起见，再次执行 netstat -tln 确认是否结束了端口占用 前情提要在布置k8s的时候发现容器报错如~]kubectl get pods -A -o wide.....pot   nginx-ingress-nginx-ingress-85d747cfb4-9hk72   0/1   CrashLoopBackOff.....然后想describe查看了一下报错如下~]kubectl describe pod -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72......... Warning  BackOff  3m14s (x613 over 137m)  kubelet  Back-off restarting failed container最后logs查看发现端口被占用~]# kubectl logs pods -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72Error from server (NotFound): pods "pods" not found[root@VM-0-114-centos ~]# kubectl logs  -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72I1104 10:51:46.738108       1 main.go:169] Starting NGINX Ingress controller Version=1.6.3 GitCommit=b9378d562021/11/04 10:51:46 [emerg] 19#19: bind() to 0.0.0.0:80 failed (98: Address already in use)nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)2021/11/04 10:51:46 [emerg] 19#19: bind() to 0.0.0.0:443 failed (98: Address already in use).......2021/11/04 10:51:46 [notice] 19#19: try again to bind() after 500ms2021/11/04 10:51:46 [emerg] 19#19: still could not bind()nginx: [emerg] still could not bind()运用了以上步骤之后回复正常pot   nginx-ingress-nginx-ingress-85d747cfb4-9hk72   1/1     Running

1. 找到系统当前所有的端口使用 netstat 命令查找本机各端口的网络连接情况~]netstat -nulpt #结果如下Active Internet connections (only servers)Proto Recv-Q Send-Q Local Address           Foreign Address         Statetcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:1997            0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTENtcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTENtcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTENtcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTENtcp6       0      0 :::80                   :::*                    LISTENtcp6       0      0 :::22                   :::*                    LISTENtcp6       0      0 ::1:25                  :::*                    LISTENtcp6       0      0 :::3306                 :::*                    LISTEN这里我们要找的是 80与443 端口2. 找到对应端口在系统中的进程 ID(PID)依据查找到的 1997 端口找到对应进程, lsof -i :1997, 注意 : 冒号不要漏掉了lsof -i:80 #结果如下COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAMEtke-gatew 6360 root   10u  IPv6 6410452      0t0  TCP *:http (LISTEN)[root@VM-0-114-centos ~]# lsof -i:443COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAMEtke-gatew  7627 root    9u  IPv6 7717644      0t0  TCP *:https (LISTEN).........->172.80.31.2:https (ESTABLISHED)galaxy    25638 root    8u  IPv4 6276795      0t0  TCP  <机密省略>:57802-..........3. 使用 kill -9 [PID] 命令结束进程通过 lsof 命令我们找到了进程的 PID: 29416,接下来就是使用 kill -9 [PID] 把进程结束就好了kill -9 6360kill -9 25638kill -9 7627到这里就 OK 了，不过为了保险起见，再次执行 netstat -tln 确认是否结束了端口占用 前情提要在布置k8s的时候发现容器报错如~]kubectl get pods -A -o wide.....pot   nginx-ingress-nginx-ingress-85d747cfb4-9hk72   0/1   CrashLoopBackOff.....然后想describe查看了一下报错如下~]kubectl describe pod -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72......... Warning  BackOff  3m14s (x613 over 137m)  kubelet  Back-off restarting failed container最后logs查看发现端口被占用~]# kubectl logs pods -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72Error from server (NotFound): pods "pods" not found[root@VM-0-114-centos ~]# kubectl logs  -n pot nginx-ingress-nginx-ingress-85d747cfb4-9hk72I1104 10:51:46.738108       1 main.go:169] Starting NGINX Ingress controller Version=1.6.3 GitCommit=b9378d562021/11/04 10:51:46 [emerg] 19#19: bind() to 0.0.0.0:80 failed (98: Address already in use)nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)2021/11/04 10:51:46 [emerg] 19#19: bind() to 0.0.0.0:443 failed (98: Address already in use).......2021/11/04 10:51:46 [notice] 19#19: try again to bind() after 500ms2021/11/04 10:51:46 [emerg] 19#19: still could not bind()nginx: [emerg] still could not bind()运用了以上步骤之后回复正常pot   nginx-ingress-nginx-ingress-85d747cfb4-9hk72   1/1     Running

打算打造一个比较使用的开发注意事项，请大家一起补充，避免后来的同学掉进去。争取能帮掉进去的同学早点出来。如果开发遇到莫名搞不定的问题了，可以看看这里：1、谨慎杀进程、谨慎杀javaw.exe进程，我们的执行器助手也是javaw进程，如果要杀金蝶但不杀助手，可以采用“wmic process where "Name='javaw.exe' AND CommandLine LIKE %%kingdee%%" delete”2、注意参数是否合法，参数中可能包含了带空格的变量或者带空格的IP地址，导致运行出错。强烈建议密码不使用&符号做密码字符之一（当前已知连接器使用的凭证中不能包含&字符）3、注意参数的引用方式是@{var}，@{list[2]}4、调用vba函数的传参需要加引号"@{sheetname}","@{sheetRange}"5、一个eval函数中只写一步运算，返回值注意填写位置，而不是用“=”6、谷歌chrome浏览器需要“扩展程序”里打开“开发者模式”选项，并打开WeAutomate Web插件7、录制chrome或者IE流程时，需要打开UI录制器打开后，点地球来输入网址并回车，这样才能录制到一个openurl8、老版本2.13及以前版本开发者需要熟悉一下新增的命令9、调用子程序callscript，需要传递入参与出参且内部无法改变全局变量的值10、学会使用论坛关键字搜索11、是否需要管理员权限运行，对于管理员权限运行的设计器或者执行器要注意对于共享文件夹是否有访问能力。

鲲鹏+麒麟多线程测试介绍：UnixBench 是测试类 Unix 系统性能的老牌工具，也是常用的基准测试工具主要测试项目有：系统调用、读写、进程、图形化测试、2D、 3D、管道、运算、C库等系统基准性能提供测试数据。unixbench一个基于系统的基准测试工具，不单纯是CPU 内存 或者磁盘测试工具。测试结果不仅仅取决于硬件，也取决于系统、开发库、甚至是编译器。测试环境：测试环境版本泰山2280 2*48 kunpeng920 银河麒麟高级服务器麒麟操作系统V10UnixbenchV5.1.3安装：Unixbench 是一款开源工具，可直接在网上下载使用，下载连接如下：https://github.com/kdlucas/byte-unixbench/archive/v5.1.3.tar.gz1：将下载的软件包上传之服务器并解压2：进入解压好的文件夹进行编译3：修改参数由默认16线程测试，需要将Run文件maxCopies参数更改成系统的逻辑核数比如泰山2280 4826配置参数需要更改为96 cat /proc/cpuinfo  查看系统核数set number  显示文件行数，修改maxCopies保存退出。测试修改BIOS参数设置BIOS选项设置值Power PolicyPerformanceStream Write ModeAllocate share LLCCPU Prefetching ConfigurationEnabledCustom Refresh Rate64ms在安装路径下执行测试大约10分钟  ./Run -c 1  单线程测试多线程测试执行命令./Run -c 96 （-c后面的核数根据系统的逻辑核数修改，结果也可以在result里查看）

在单线程下yolov3总共耗时10ms左右，但是在多线程下同时跑yolov3，单个耗时达到50ms；多线程开发是依据开发文档，每一个线程创建一个context与stream管理线程，请问如何定位此问题？谢谢答复。

压测最大并发量未受限每IVR配置5线程，每线程配置600压力测试启动，其中两个线程瞬间满占用其余3个无占用呼叫也随之报错，主被叫跟踪339拆线按产品文档核实，并无该配置错误检查IVR进程状态，均为collected请问还有啥原因导致该现象呢

如何才能加速ADC的应用进程？关于这个主题，我也是基于自身需求提出的，只有开发的功能应用于实际工作中，实现产出，才能引起管理层的注意，才能加大投入。目前痛点：学会了ADC8大编排的皮毛功能，稍有欣慰，但是实际应用的时候碰到一些问题，如：缺少单独的账号、单独的页面，缺少信息安全和存储空间的提示，正品app缺少独立的链接等。针对以上问题，建议如下：1、用ADC开发的界面和功能发布后，可以让开发人员自定义设置登录人员账号密码，不用依赖于华为账号；2、运行态界面就是独立运行的应用，可以登录和操作功能，同时具备存储功能。3、华为自身盈利：通过提供增值功能和云服务收费，明码标价；4、内部资料明确保密属性。这样可以增加大家的开发热情，加速应用。

管道：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。命名管道FIFO：未命名的管道只能在两个相关的进程之间通信，通过命名管道FIFO，不相关的进程也能交换数据。消息队列：消息队列是消息的链表，具有特定的格式，存放在内存中并由消息队列标识符标识。消息队列允许一个或多个进程向它写入与读取消息。管道和命名管道的通信数据都是先进先出原则，消息队列可以实现消息的随机查询，消息不一定要以先进先出的次序读取，也可以按消息的类型读取，比FIFO更有优势。共享内存：共享内存是允许一个或多个进程共享的一块内存区域。信号量：信号量是一个计数器，可以用来控制多个进程对共享资源的访问。通常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。