>摘要：云服务环境下，如何解决客户基于大量数据创建索引的性能问题，成为云服务厂商的一个挑战。华为云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

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,查看参数已生效。

打算打造一个比较使用的开发注意事项，请大家一起补充，避免后来的同学掉进去。争取能帮掉进去的同学早点出来。如果开发遇到莫名搞不定的问题了，可以看看这里：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、是否需要管理员权限运行，对于管理员权限运行的设计器或者执行器要注意对于共享文件夹是否有访问能力。

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

使用命令查看Linux系统版本、内核版本、CPU型号、硬盘空间、内存信息、网络信息。1、查看系统版本：lsb_release -a2、查看内核版本：uname -a3、查看cpu型号：cat /proc/cpuinfo4、查看硬盘空间情况：df -h5、查看内存信息：free -m 6、查看网络信息：ifconfig常用的查看linux环境信息的命令设进程号为pid，端口号为port。1.CPU占用率命令：top -p pid，%CPU一项，单位为百分比。2.物理内存使用量命令：top -p pid，RES一项，单位为KB。3.虚拟内存使用量命令：top -p pid，VIRT一项，单位为KB。4.进程队列长度命令：top，load average一项，三个值分别代表最近1分钟、5分钟、15分钟进程队列的平均长度。5.打开的socket及其状态命令：netstat -an | grep port，第四列代表源IP，第五列代表目的IP，第六列代表状态（如LISTEN、ESTABLISHED、TIME_WAIT等）。替代命令：ss，需要安装几个内核模块，在连接较多时性能比netstat好很多。安装内核模块命令：insmod /lib/modules/2.6.18-164.el5/kernel/net/ipv4/inet_diag.koinsmod /lib/modules/2.6.18-164.el5/kernel/net/ipv4/tcp_diag.koinsmod /lib/modules/2.6.18-1.2.0.0-xen/kernel/net/ipv4/inet_diag.koinsmod /lib/modules/2.6.18-1.2.0.0-xen/kernel/net/ipv4/tcp_diag.ko6. I/O使用率命令：iostat -x，%util一项，单位为百分比。7.磁盘读写速率命令：iostate -k，kB_read/s表示磁盘每秒读出多少KB数据，kB_wrtn/s表示磁盘每秒写入多少KB数据。8.最近使用的系统调用及其耗费时间命令：strace -f -tt -T -p pid，第一项代表系统调用名称，最后一项代表该调用耗费的时间，单位为秒。9.打开的文件描述符数量命令：ls /proc/pid/fd | wc -l。10.进程地址空间命令：pmap -d pid。11.环境变量命令：cat /proc/pid/environ。12.进程各模块的内存使用情况命令：cat /proc/pid/smaps。13.进程状态信息命令：cat /proc/pid/status，State代表进程状态（运行、睡眠、僵尸等），SleepAVG代表进程睡眠时间的比例，Tgid代表线程组号，PPid代表父进程号，FDSize代表文件描述符的最大个数，VmSize代表进程虚拟地址空间的大小，VLck代表进程锁住的物理内存的大小，锁住的物理内存无法交换到磁盘，VmRSS代表进程正在使用的物理内存的大小，VmData代表进程数据段的大小，VmStk代表进程在用户态的栈的大小，VmExe代表进程拥有的可执行虚拟内存的大小，代码段，不包括使用的库，VmLib代表映射到进程地址空间的库的大小，以上单位均为KB，SigQ代表待处理信号的数量，SigBlk代表被阻塞的信号，SigIgn代表被忽略的信号，SigCgt代表被捕获的信号。14.进程的线程数量命令：ls /proc/pid/task | wc -l。15.启动该进程的命令行命令：cat /proc/pid/cmdline。16.列出当前系统打开了哪些文件以及分别由哪个进程打开命令：sudo lsof -n17.使程序主动生成core dump文件命令：gdb -p pid -batch -ex "generate-core-file"

1. 问题现象在某数据库测试的时候发现执行linux基础命令报错：-bash: fork: Cannot allocate memory重启后，问题不再出现。与此同时，客户也反馈测试过程中会经常出现数据库进程少了的现象。 2. 问题分析网上碰到的问题都是说是由于进程数满了，这个可能性不大，因为系统的进程最大数已经设置成32768了，已经很大了。由于出现问题后，无法执行命令查看系统状态。首先想到的办法是查看message日志。通过BMC登录后，收集到message日志查看后发现有crash的现象：从日志上可以看出，系统内存不够用了，所以kill了数据库进程，这也能够解释得了客户发现的数据库进程变少的现象了。从这个日志往上看，发现了另外一个关键信息：可以看出swap空间已经被用光了，出发了OOM，导致了系统出现了异常。对比这次测试跟之前的测试，数据库使用的内存大小都是一样的，发现这次开辟的SWAP空间较小。之前的SWAP分区有150G，而这次才开了4G，在内存紧张的情况下，很容易就出现了OOM。3. 解决方法由于客户不愿意修改数据库内存，认为当前的数据库内存配置是最优的，所以我们动态调整了SWAP分区大小。创建空文件# dd if=/dev/zero of=/home/swap bs=1G count=200挂载到swap空间mkswap /home/swap加载swap空间/sbin/swapon /home/swap以上命令重启后会失效，如果想让修改永久生效则需要修改配置：设置开机自动挂载，修改/etc/fstab/home/swap                       swap                    swap    defaults        0 0 按照这个方式修改后，再也没有出现过此问题了。

1 问题背景同一型号SSD裸盘性能测试，4k随机读写测试（单jobs、iodepth为32），TaiShan200服务器性能不符合预期，需要进行调优。 2 原因分析执行测试命令，分析TaiShan系统表现，发现fio线程cpu占用较低，对fio进程绑核后性能表现等没有变化；将fio测试进程增加到4个，使用4个cpu测试，iops提升很小，cpu占用率更低，说明cpu没到瓶颈。iostat分析,TaiShan的await保持在58，也就是IO请求从下发到完成的耗时较长，由于是裸盘测试不经过文件系统，所以可能与cpu的超频、驱动实现有关。分析热点函数，发现TaiShan的tick_nohz_idle_enter，tick_nohz_idle_exit两个函数cpu占用较高，尝试给系统启动命令加上nohz=off，加上后此两个热点函数消失，但是性能只有小幅提升。在iBMC排查raid配置，发现TaiShan的测试盘一个盘自己组了raid0，为排除影响将磁盘raid模式调整为jbod直通模式，性能没有提升。测试前erase硬盘除去脏数据可能导致的不同程度写放大影响，性能还是没有提升。更换TaiShan测试盘，排除硬件本身差异，性能没有提升。TaiShan使用华为高性能SAS SSD盘测试，4k随机读写iops比当前使用的测试盘高几倍，cpu占用很高，确认主要瓶颈不在cpu。Blktrace工具分析IO请求具体的耗时占比，发现D2C占比高达99%，确认耗时主要在驱动和硬件。D2C表示IO请求被driver提交给硬件，经过HBA、电缆（光纤、网线等）、交换机（SAN或网络）、最后到达存储设备，设备完成IO请求之后再把结果发回这段路径的耗时。lsscsi发现TaiShan服务器有expander芯片。通过raid卡管理工具确认，测试盘接在expander背板，expander背板与raid卡相接，也就是IO请求先下发到raid卡，raid卡发送到expander芯片，expander芯片再发送到硬盘，理论上expander芯片会带来性能损耗。家里实验室验证硬盘背板带expander芯片和不带expander芯片场景下4k随机读写性能，的确有较大差距。3 解决方案调整TaiShan硬盘方面硬件配置，选用不带expander芯片的硬盘背板型号。4 总结裸盘IO由于不经过文件系统，io路径短，如果硬盘性能低不能使cpu达到瓶颈，则在其他硬件配置一致的情况下不同cpu测试性能是持平的；如果硬盘属于高性能硬盘，cpu占用极高，则需通过添加测试进程数，增加使用的cpu个数以达到硬盘瓶颈。需要注意的是，裸盘测试需要确保对比机器的硬盘接入方式是相同的，比如都是cpu直出、都是raid卡直通、都接在expander硬盘背板上；确保raid配置是相同的，比如都是raid1或者都是jbod模式

1 问题背景虚拟机（8C16G）裸盘（预分配80G）fio 4k随机写测试（4jobs，iodepth为32）TaiShan 200服务器性能不符合预期，需要进行调优。 2 原因分析执行测试命令，观察TaiShan服务器表现：物理机上，发现kvm进程cpu占用较高，进一步分析发现TaiShan上kvm线程200+；虚拟机上，TaiShan cpu0占用率很高，其中软中断占比高的不合理。怀疑是虚拟机实现方式的问题，发现TaiShan虚拟机测试磁盘类型为virtio-scsi-device（可以使用virtio-block-device，block设备比scsi设备IO路径稍微短些），且当前测试使用的qemu版本较低，可能还不支持armv8新特性。修改TaiShan虚拟机启动参数，将测试盘类型调整为virtio-block-device，性能有小幅提升，物理机上kvm线程数从200+降低到80以内，虚拟机上cpu0的软中断也较低到合理范围，但系统占用又变得很高，说明kvm线程和软中断高是磁盘类型导致，此时是cpu瓶颈。无法给TaiShan虚拟机指定cpu asimd特性，显示参数错误。将虚拟机vcpu一对一绑核，关闭irqbalance,给fio测试程序绑核，几乎没有性能提升。开启大页内存，没有性能提升。分析fio系统调用，发现clock_gettime系统调用耗时有时达到2ms，耗时很高，此客户机操作系统为3，更换为centos7.7，fio系统调用看不到clock_gettime函数，但是性能没有提升。使用原生0.0版本测试，性能有一定提升;进一步重新编译qemu，加上对native aio的支持，性能提升较大。此时，虚拟机上仍然是cpu0 占用特别高，物理机上观测一个vcpu线程cpu占用特别高，qemu主线程cpu占用不高。尝试给磁盘配置iothread卸载qemu主线程压力、对磁盘添加write-cache=on和ioeventfd =on等属性、排查TaiShan物理机上对应SSD的性能表现，没有性能提升。将物理机上SSD的调度策略由默认的cfq调整为noop，性能有一定提升。使用7开始对virtio-blk支持的新特性multiqueues磁盘多队列，性能有较大提升，虚拟机上单个cpu占用特别高的问题解决了。进一步优化，将TaiShan iommu模式配置为passthrough，性能有进一步提升。3 解决方案使用新版qemu如0.0或更高版本,guest os版本也尽量高点使用virtio-blk磁盘多队列特性虚拟机异步io模式配置为native若虚拟化场景无需使用磁盘、网卡直通或SRIOV特性，则可关闭SMMU。4 总结虚拟化场景IO测试，IO路径较长，且不同类型磁盘IO路径也不同。首先需要确认磁盘bus类型（scsi、ide、virtio），保证使用的磁盘文件的协议（nfs、iscsi、本地挂载）是一致的,保证磁盘文件在对应物理机上创建的规则是一样的（预分配、缓存特性等）。如果判断是单核瓶颈，可以尝试使用磁盘多队列特性（针对virtio-blk设备，对qemu、geust操作系统版本有要求）；如果是qemu主线程占用高，可以考虑开启iothread分担压力（可能影响动态迁移特性，需调研）；设置磁盘异步调用为native会有性能提升，不过也有一定的使用限制（不能用于sparse images，否则在文件系统元数据需要更新时会导致qemu threads阻塞），需了解使用需求。实际测试中，瓶颈分析需要结合虚拟机和物理机两者的系统表现，因为虚拟机的cpu、io等占用信息不一定是真实的（存在vcpu等kvm线程本身被调度和阻塞的问题等）。

1.1 Varnish简介Varnish是一款高性能的反向代理缓存服务器，通过缓存静态资源，在基于Web的业务场景可提升站点10+倍的性能，目前仍是CDN（Content Delivery Network）的一个重要实现方案。1.2 Varnish物理机调优1.2.1 Varnish配置参数调优目的：通过调优Varnish的配置文件，可以有效的提高服务器的性能。方法：配置varnish的配置文件/usr/local/varnish/config/default.vcl中的default，vcl_recv，vcl_backend_response，vcl_pipe，vcl_pass，vcl_hash，vcl_hit，vcl_miss，vcl_deliver模块。配置项说明default配置通信IP及端口vcl_recv用于接收和处理请求；当请求到达varnish，通过判断请求的数据来决定如何处理请求vcl_backend_response获得后端主机的响应后调用vcl_pipe用于将请求直接传递至后端主机，并将后端响应原封不动返回给客户端vcl_pass用于将请求直接传递给后端主机，但后端主机的响应并不缓存，而是直接返回给客户端vcl_hash在vcl_recv调用后为请求创建一个hash值时，调用。此hash值将作为varnish中hash表的keyvcl_hit在缓存中找到请求的内容后自动调用vcl_miss在缓存中没有找到请求的内容后自动调用。用于判断是否需要从后端服务器获取内容vcl_deliver将在缓存中找到的请求的内容发送给客户端前调用1.2.2 Varnish亲和性配置目的：对varnish进程进行绑核并启动。方法：以物理机1P场景为例，使用numactl设置CPU与内存的亲和性。numactl -C 0-2,4-10,12-18,20-26,28-34,36-42,44-47 --membind=0,1 /usr/local/varnish/sbin/varnishd -P /tmp/varnish.pid -a :12345 -T 127.0.0.1:6082 -s malloc,100GB -f /usr/local/varnish/config/default.vcl -t 600 -p thread_pool_max=5000 -p thread_pools=10 -p thread_pool_destroy_delay=3 -p timeout_idle=75 -p thread_pool_min=700参数名称参数说明-C进程绑定的CPU core--membind分配进程的内存，其中0,1表示分配的内存在node0和node1上-PVarnish进程pid文件存放路径-a表示Varnish对httpd的监听地址及端口-T设定 varnish 的 telnet 管理地址及其端口-s指定 varnish 缓存存放的方式，常用的方式有：“-s file,<dir_or_file>,<size>”。-f指定 varnish 的配置文件位置-t指定默认的TTL值-p thread_pool_max每个线程池创建的最大线程数-p thread_pools设置线程池个数-p thread_pool_destroy_delay摧毁线程的延迟时间，也就是摧毁之前需要犹豫一下，这个犹豫的时间-p timeout_idle设置保持链接的空闲时长-p thread_pool_min每个线程池创建的最小线程数 

1.1 Squid简介Squid是一个高性能的代理缓存服务器，通过缓存和重用经常请求的网页，减少了带宽并缩短了响应时间。1.2 Squid物理机调优1.2.1 Squid亲和性调优目的：通过调优Squid的配置文件，可以有效的提高服务器的性能。方法：对squid进程进行绑核并启动。在/usr/local/squid/etc/squid.conf中配置cpu_affinity_map参数：workers 43cpu_affinity_mapprocess_numbers=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38, 39,40,41,42,43,44,45,46,47,48cores=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37, 38,39,40,41,42,43,44,45,46,47,48Squid启动参数说明参数说明Workers启动的进程数cpu_affinity_map process_numbers进程与CPU的对应关系，如上配置，表示squid的启动的1-48个进程分别对应着1-48号CPU步骤2   一路CPU上启动一个Squid实例。             /usr/local/squid/sbin/squid -s                如需启动两个Squid实例，需新建配置文件squid_2.conf，执行如下命令启动第二个实例：        /usr/local/squid/sbin/squid -f /usr/local/squid/etc/squid_2.conf

什么时候用异步编程在前端编程中（甚至后端有时也是这样），我们在处理一些简短、快速的操作时，例如计算 1 + 1 的结果，往往在主线程中就可以完成。主线程作为一个线程，不能够同时接受多方面的请求。所以，当一个事件没有结束时，界面将无法处理其他请求。现在有一个按钮，如果我们设置它的 onclick 事件为一个死循环，那么当这个按钮按下，整个网页将失去响应。为了避免这种情况的发生，我们常常用子线程来完成一些可能消耗时间足够长以至于被用户察觉的事情，比如读取一个大文件或者发出一个网络请求。因为子线程独立于主线程，所以即使出现阻塞也不会影响主线程的运行。但是子线程有一个局限：一旦发射了以后就会与主线程失去同步，我们无法确定它的结束，如果结束之后需要处理一些事情，比如处理来自服务器的信息，我们是无法将它合并到主线程中去的。为了解决这个问题，JavaScript 中的异步操作函数往往通过回调函数来实现异步任务的结果处理。回调函数回调函数就是一个函数，它是在我们启动一个异步任务的时候就告诉它：等你完成了这个任务之后要干什么。这样一来主线程几乎不用关心异步任务的状态了，他自己会善始善终。实例function print() {    document.getElementById("demo").innerHTML="RUNOOB!";}setTimeout(print, 3000);尝试一下 »这段程序中的 setTimeout 就是一个消耗时间较长（3 秒）的过程，它的第一个参数是个回调函数，第二个参数是毫秒数，这个函数执行之后会产生一个子线程，子线程会等待 3 秒，然后执行回调函数 "print"，在命令行输出 "RUNOOB!"。当然，JavaScript 语法十分友好，我们不必单独定义一个函数 print ，我们常常将上面的程序写成：实例setTimeout(function () {    document.getElementById("demo").innerHTML="RUNOOB!";}, 3000);尝试一下 »注意：既然 setTimeout 会在子线程中等待 3 秒，在 setTimeout 函数执行之后主线程并没有停止，所以：实例setTimeout(function () {    document.getElementById("demo1").innerHTML="RUNOOB-1!";}, 3000);document.getElementById("demo2").innerHTML="RUNOOB-2!";console.log("2");尝试一下 »这段程序的执行结果是：RUNOOB-1!RUNOOB-2!异步 AJAX除了 setTimeout 函数以外，异步回调广泛应用于 AJAX 编程。有关于 AJAX 详细请参见：https://www.runoob.com/ajax/ajax-tutorial.htmlXMLHttpRequest 常常用于请求来自远程服务器上的 XML 或 JSON 数据。一个标准的 XMLHttpRequest 对象往往包含多个回调：实例var xhr = new XMLHttpRequest(); xhr.onload = function () {    // 输出接收到的文字数据    document.getElementById("demo").innerHTML=xhr.responseText;} xhr.onerror = function () {    document.getElementById("demo").innerHTML="请求出错";} // 发送异步 GET 请求xhr.open("GET", "https://www.runoob.com/try/ajax/ajax_info.txt", true);xhr.send();尝试一下 »XMLHttpRequest 的 onload 和 onerror 属性都是函数，分别在它请求成功和请求失败时被调用。如果你使用完整的 jQuery 库，也可以更加优雅的使用异步 AJAX：实例$.get("https://www.runoob.com/try/ajax/demo_test.php",function(data,status){    alert("数据: " + data + "\n状态: " + status);});尝试一下 »

【操作步骤&问题现象】执行slabtop -o 2>/dev/null | grep "dentry" | awk '{print $(NF-1)}'命令，检查Dentry内存超过10GB（排查频繁操作大量文件的进程，找出问题根因，解决dentry占用内存问题），怎么排查是那个进程导致的？

【问题现象】         Dms agent进程在长时间运行(4-5个月后)占用内存过多，导致内核无法分配内存，进程异常。【问题版本】         所有使用DMS，内核版本为810 、811的版本都涉及。         包含：HCS 8.0.2版本，HCS 8.0.3版本，HCSO 0130,0430,0730。【问题根因】  进程缓存信息占用【恢复方案】Kill  agent_service.py对应的的进程。