创建任务页面：针对“进程/线程调度”中几种状态“Wait_Blocked”、“Wait_For_CPU”和“Running”可以支持过滤吗：

（1）前言        今天来和大家聊聊MySQL的复制演进过程，熟悉MySQL的同学应该都知道什么是MySQL复制mysql，关于这块知识网络上也有各种材料，笔者查找过很多资料，发现很多材料都描述得不够全面，光看单篇文章难以建立整体概念，因此梳理了一版浅显全面的文章出来，帮助大家轻松读懂MySQL复制演进过程。        言归正传，一直以来，MySQL的主从复制都常常被大家诟病，总结原因有以下几点：        1. 主从复制速度问题(这是最主要的)        mysql采取的复制方式是，主机执行提交之后将语句记录进binlog，备机启动一个IO线程从主传输binlog到本地，进入本地的relaylog；然后备机会另外启动一个SQL线程负责顺序执行relaylog中的语句，对语句在备机上重做，所以说这是一个异步的拷贝过程。这样会导致一个问题，就是备机数据大部分情况下会延后。主机对本地磁盘的IO、备机从主机传输的网络IO、备机本地的磁盘IO、最后备机重放数据的IO，经过了四个过程，即使服务器和网络配置都很快，理论上也一定是有延迟的；如果服务器和网络配置有瓶颈，这个延迟就会扩大化到影响业务的程度，最直接的就是读写分离的情况下，导致前端写入操作明明已经返回完成了，后端读数据时却显示没有完成。        2. 主机宕机切换后脏数据问题        mysql的主备目的之一，就是在主宕机的情况下，能及时切换到备机继续提供服务，不至于整个系统挂掉，即故障转移。但就是因为主从复制要经过复制这一消耗IO的步骤，主在挂掉的一瞬间，一般主备机都会有一定量的数据区别，这些在主机执行完毕了但还未传输到备机上的数据，就是所谓的脏数据。这样的脏数据，同样会导致前后不一致，如果服务器和网络配置不高，本来同步复制就慢的情况下，会导致极大的差别。                2009年oracle公司收购了sun，对mysql进行升级换代之后，有了巨大的改进，在5.5、5.6、5.7版本都针对主从有升级改造，在目前的5.7版本达到了非常高的可用性，配合最新的HA中间件mysql fabric，可以达到以前的几倍的稳定性。下面来详细讲一讲这三个版本中，oracle都对主从具体做了什么改进。（2）MySQL5.5版本        1. 5.5版本添加了一个semi-sync replication（半同步复制）的插件，这个插件就是为了优化同步复制的脏数据问题而生的。        2. 半同步复制在提交过程中增加了一个延迟，在提交事务后，只有在备库收到了该事务的binlog时才会给客户端进行查询结束的反馈。这会给客户端查询体验增加一些延迟，不过问题不大，因为相对于写入硬盘的时间，通过网络传输些日志的时延不算什么。重要的是，半同步复制不会阻塞事务的提交，而是阻塞在给客户端的反馈；当备库一直没有回应已收到事件，主库会超时并转化成正常的异步复制模式。        3. 顺带提一下半同步复制简单原理：在传输binlog时，要求备机返回ack证明自己拿到了数据，在至少一个备机返回ack后，主机才将数据修改提交到本地，这样能保证至少一个备机和主机是完全一致的。        4. 再举个例吧：当在主机上持续不断insert数据时，始终有一部分数据处在传输到备机的过程中，这部分数据在主机上已经是执行成功的状态，但因为还没传输完成收到任何一台备机的回应，所以尚未持久化。这个瞬间主机宕机了，数据传输不完，备机的回应也收不到了，主机重启后，主机上的这部分数据因为没有收到回应进行持久化，所以消失了。而备机上的这部分数据因为尚未接收完全，也不能作为一个relaylog提交执行，所以备机也没有这部分数据。最终的结果就是，这部分脏数据就被丢弃了，不会造成主从的不一致。        5. 优点：保证至少一个备机和主机在任何时候都是一致的，不会出现你比我多或者我比你多的情况，不需要进行主从恢复后的数据恢复行为。在只有一主一从的情况下，整个系统永远不会有脏数据。        6. 缺点：显而易见的，一主多备的情况下，除了只有一台备机的情况外，其他备机都会有数据不一致现象。另外，没有成功传输的数据就被直接丢弃了，找都找不回来，如果涉及金融交易，瞬时的数据丢失也是不可原谅的，所以这种架构在数据重要度非常高的业务里不能用。（3）MySQL5.6版本        1. 5.6版本对主从同步进行了改进，加入了GTID（5.6.2开始，5.6.10完善）的事务区分标志，又加入了多线程复制和组提交的新模式。        2. GTID：在MySQL5.6以前对于主从复制出现问题有时候需要分析BINLOG找到POS点，然后再CHANG MASTER TO。容易犯错，造成主从复制错误。引入GTID后,不需要再寻找BINLOG和POS点，只需要知道MASTER的IP、密码、端口就可以，MySQL会从内部GTID机制自动找到同步点。加入GTID后，一是可以根据GTID可以知道事务最初是在哪个实例上提交的，二是GTID的存在也方便了Replication的Failover。        3. GTID原理：分成两部分，一部分是服务的UUID，保存在mysql数据目录的auto.cnf文件中，这是一个非常重要的文件，不能删除，这一部分是不会变的。另外一部分就是事务ID（TID）了，随着事务的增加，其值依次递增。        4. 多线程并发复制：在MySQL5.6之前，复制是单线程队列式的,只能一个一个运行。在新版中支持基于库的多线程复制，但是库里的表不能多线程。针对多个库的情况，开启多线程，每个库一个独立IO线程，可以交叉并发传输。在不同库同一时间进行的操作理论上是互不影响的，可以同步进行，你改你的，我改我的。极大改善了多库业务的复制速度。贴个经典的图。                5. 5.6的并行复制框架实际包含了一个协调线程和若干个工作线程，协调线程负责分发和解决冲突，工作线程只负责执行。        6. 但是多线程并发复制也不一定完全有效，其并行只是基于schema的，也就是基于库的。如果用户的MySQL数据库实例中存在多个schema，对于备机复制的速度的确可以有比较大的帮助。但如果业务始终只有一个库，或者数据库压力都集中在一个库上，其他库基本没什么操作，那针对库的多线程基本没有意义，还是和以前的单线程复制是一样的速度。所以说MySQL 5.6所谓的并行复制对真正用户来说，有点雷声大雨点小。        7. 组提交：极大提升了binlog和innodb的redolog的落盘（保存到磁盘）效率，可将多次磁盘IO可以合并成一次磁盘IO，减少读写次数，有效提高了写日志的速度。也就意味着在主从同步过程中，磁盘IO这一块的效率提高了。        8. 组提交的原理：多个事务同时执行完成，数据需要持久化到log中时，会全部进入一个待提交队列。最先进入队列的事务线程成为leader线程，其他后续进入的成为follower线程，leader线程将会获得这个队列的控制权，就是会获得一个锁，全权负责本次队列中所有事务的落盘操作。接着联系其他follower线程，将他们的提交内容获取得到，并让他们等待自己完成操作。接着这个leader线程会进入后续的落盘过程，等完成后，会通知本队列中所有follower线程落盘已经完成，可以返回成功状态了。（4）MySQL5.7版本        1. MySQL 5.6基于库的并行复制出来后，基本无人问津，在沉寂了一段时间之后，MySQL 5.7出来了，它的并行复制以一种全新的姿态出现在用户面前。MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave服务器的回放与master是一致的，即master服务器上是怎么并行执行的，那么slave上就怎样进行并行回放。不再有库的并行复制限制，对于binlog格式也无特殊的要求（基于库的并行复制也没有要求）。        2. 5.7之所以被看作mysql主从复制上一个划时代的版本，主要原因是mysql将日志组提交的模式应用到了主从网络IO上，在原来已经通过组提交优化了的磁盘IO效率基础上，对网络IO效率进行了同样的优化，正是将困扰mysql主从复制多年的两大难题解决的最重要版本。官方称之为Enhanced Multi-Threaded Slave（简称MTS）。        3. MTS这么牛，再多点一下：增强的多线程复制，即通过备机开启多个IO线程，主机通过组提交的模式并行地传输事务进行复制。具体思想简单易懂，一言以蔽之：一个组提交的事务都是可以并行回放的，若这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交），关于MTS的详细原理和实现，可以查阅资料详细学习一下，这里点到为止。        4. 但是前面提到的网络IO是有先后顺序的，和传输顺序通常是不同的，收到事务后需要区分先后顺序来执行，否则备机执行顺序和主机不同，数据同样会出错。获取事务先后顺序的方法也很简单，就是使用的MYSQL 5.6已经加入的GTID，因为每个事务在提交时已经按顺序生成了唯一的GTID，备机读到事务后按照GTID的顺序执行就可以了。        5. 在这样的模式下，从机可以同时消费主机的多个事务队列，在同一时间接收到更多的数据传输，有效降低了数据来不及传输而导致的宕机数据丢失的概率。        6.最后提一个问：MySQL5.7是如何识别哪些事务是要一起提交的呢？        其实就是在GTID event 中增加了两个字段：int64 last committed和int64 sequence number,同一个组提交里多个事务gtid不同，但last committed却是一致的，同时一个组里的last committed对应上一个事务的sequence number。当slave的coordinator线程在分发这些event的时候，具有相同last committed 的事务(event的集合)就可以同时发送给不同的work线程，达到并行同步的目的。        总结一下，MySQL复制演进历程大致可以概括为：从5.5的单线程复制，到5.6基于Schema级别的并行复制，再到5.7最大化还原主库的支持事务级别的并行复制。其实总体来看其发展是有连贯的前因后果的，大致了解MySQL复制的来龙去脉之后，再去抠细节会清晰许多。

下方提供代码测试工具下载使用方式：编译命令（要求jdk1.8）：javac MaskTest.java运行命令：java MaskTest <你的代码进程启动命令>例如：C++(windows): java MaskTest Main.exeC++(linux): java MaskTest ./Main.outjava: java MaskTest java Mainpython: java MaskTest python Main.py代码常见问题：1. 配送路径值为非法数据：只接受[E|W|S|N]2. 超过步数上限500：一张地图的步数超出了5003. 快递员中间离开地图范围：接受某次移动方向后，快递员离开地图范围4. 运行超时：  a. 所有待配送小区需求口罩数已为零，进程没有中断  b. 进程在接受'G'指令后，没有返回方向字符，仍在等待输入，进程被IO阻塞  c. 每次输出没有独占一行，例如java应使用System.out.println()而不是System.out.print()  d. 存在死循环  e. 时间复杂度过高5. 配送结束后，尚有小区未获得口罩：进程退出时，仍存在待配送小区6. 运行出错：  a. 代码无法通过编译  b. 代码抛出异常、内存溢出、return非零值等运行时错误  c. 进程退出时，仍存在待配送小区（导致接收'G'指令的通道关闭）

资源信息如下：

并行查询特性最早是在PostgreSQL 9.6中引入。自那时起，社区一直在扩展该功能。在PostgreSQL 11和PostgreSQL 12中，社区开发人员向数据库引擎添加了更多的相关功能。本文就PostgreSQL查询优化器对并行执行代价估算的工作原理进行阐述，不足之处希望大家多多指正。串行顺序扫描执行代价估算       为了方便解释，用一个简单的例子来说明问题。首先通过代码片段1创建一个表包含两列。    1.  //代码片段1     2.  mydb=# CREATE TABLE people (id int PRIMARY KEY NOT NULL, age int NOT NULL);      3.  CREATE TABLE为了演示并行查询带来的益处，利用代码片段2往表people**一千万条数据，其中age字段是0-100之间的随机数。    1.  //代码片段2     2.  mydb=# INSERT INTO people        3.         SELECT id, (random()*100)::integer AS age        4.         FROM generate_series(1,10000000) AS id;       5.  INSERT 0 10000000默认情况下PostgreSQL是打开并行执行的。我们首先关闭并行执行开关，检查串行查询执行的耗时。通过将配置参数max_parallel_workers_per_gather设置为0可以关闭并行执行特性。从查询执行计划可以看到，顺序扫描的执行代价为144.248ms（Pg的执行计划显示的时间由两部分组成，‘..’前面的称之为start_up_cost,后面部分叫做run_cost）。总的查询执行代价为169.248ms。Pg如何计算得到这些数字的？ 1.  //代码片段3  2.  mydb=# SET max_parallel_workers_per_gather TO 0;    3.  SET    4.  mydb=# explain analyze select count(*) from people;    5.                                 QUERY PLAN    6.  --------------------------------------------------------------------------------  7.   Aggregate  (cost=169248.60..169248.61 rows=1 width=8) (actual time=1375.237..1375.237 rows=1 loops=1)    8.      -> Seq Scan on people(cost=0.00..144248.48 rows=10000048 width=0)    9.   (4 rows)Pg查询执行时间total_cost = start_up_cost + run_cost,具体来说pg的运行时的代价由以下的式子计算得到：                total_cost = cpu_run_cost + disk_run_cost                                   = (cpu_tuple_cost + cpu_operator_cost) × Ntuple + seq_page_cost×Npage (1)        其中cpu_tuple_cost是CPU传输该记录的代价；cpu_operator_cost指函数运算或其他操作符的开销。有了上述计算规则以后，可以通过Pg的元数据表pg_class查询表people相关统计信息,见代码片段4。可以得到Npage=44248，Ntuple = 10000048.Pg源代码的cost.h头文件定义了公式(1)相关的计算代价，见代码片段5：    1.  //代码片段4     2.  mydb=# SELECT relpages, reltuples FROM pg_class WHERE relname = 'people';       3.   relpages |   reltuples       4.   ----------+---------------       5.     44248 | 1.0000048e+07       6.  (1 row)计算代价如下：    1.  //代码片段5     2.  /* defaults for costsize.c's Cost parameters */       3.  /* NB: cost-estimation code should use the variables, not these constants! */       4.  /* If you change these, update backend/utils/misc/postgresql.sample.conf */       5.  #define DEFAULT_SEQ_PAGE_COST  1.0       6.  #define DEFAULT_RANDOM_PAGE_COST  4.0       7.  #define DEFAULT_CPU_TUPLE_COST  0.01       8.  #define DEFAULT_CPU_INDEX_TUPLE_COST 0.005       9.  #define DEFAULT_CPU_OPERATOR_COST  0.0025       10. #define DEFAULT_PARALLEL_TUPLE_COST 0.1       11. #define DEFAULT_PARALLEL_SETUP_COST  1000.0将代码片段5的计算代价，放入公式(1)，我们可以得到顺序扫描的代价：                              total_cost = (cpu_tuple_cost)×Ntuple + seq_page_cost×Npage                        = 0.01×1.0000048e+07 + 1×44248                                 = 144248.48这就是代码片段3第8行的顺序执行代价。而总的执行代价，需要对每条元组进行count函数操作，因此需要加上cpu_operator_cost,因此聚集函数count的查询执行start_up_cost为：                              Start_up_cost = cpu_run_cost + disk_run_cost                               = (cpu_tuple_cost + cpu_operator_cost)×Ntuple + seq_page_cost×Npage (1)                       = (0.01 + 0.0025) ×1.0000048e+07 + 1×44248                               = 169248.6 （代码片段3第7行所示）最后，系统只需要对这条元组传输即可，因此总的查询执行代价为：                            total_cost = (cpu_tuple_cost)×Ntuple + start_up_cost                                       =  0.01 + 169248.6                                       =  169248.61（代码片段3第7行所示）并行顺序扫描执行代价估算现在我们将并行执行的特性打开令max_parallel_workers_per_gather=2，相应的执行计划如下：1.  //代码片段6 2.  mydb=# set max_parallel_workers_per_gather = 2;   3.  SET   4.  mydb=# explain analyze select count(*) from people;   5.                           QUERY PLAN   6.  ------------------------------------------------------------------------------------------------------------ 7.   Finalize Aggregate  (cost=97331.80..97331.81 rows=1 width=8) (actual time=524.896..524.896 rows=1 loops=1)   8.     ->  Gather  (cost=97331.58..97331.79 rows=2 width=8) (actual time=524.828..526.162 rows=3 loops=1)   9.           Workers Planned: 2   10.          Workers Launched: 2   11.          -> Partial Aggregate  (cost=96331.58..96331.59 rows=1 width=8)   12.                -> Parallel Seq Scan on people  (cost=0.00..85914.87 rows=4166687 width=0)   13.  Planning Time: 0.307 ms   14.  Execution Time: 526.209 ms   15. (8 rows)为了解释并行查询执行代价，我们首先看看不同进程（为什么用进程是历史原因）之间工作量的分配。当并发进程只有两个的时候，主进程需要将大部分时间花费在执行工作，当并行进程的增加，主进程逐渐将工作转向聚合部分结果。Pg的进程工作量分配正是建立在这个基础之上。具体的分配算法见代码片段7第22行-27行。并行执行的框架如图1所示。1.  //代码片段7 2.  static double   3.  get_parallel_divisor(Path *path)   4.  {   5.      double      parallel_divisor = path->parallel_workers;   6.     7.       /*  8.        * Early experience with parallel query suggests that when there is only 9.        * one worker, the leader often makes a very substantial contribution to 10.       * executing the parallel portion of the plan, but as more workers are  11.       * added, it does less and less, because it's busy reading tuples from the  12.       * workers and doing whatever non-parallel post-processing is needed.  By  13.       * the time we reach 4 workers, the leader no longer makes a meaningful  14.       * contribution.  Thus, for now, estimate that the leader spends 30% of  15.       * its time servicing each worker, and the remainder executing the  16.       * parallel plan.  17.       */   18.     if (parallel_leader_participation)   19.     {   20.         double      leader_contribution;   21.    22.         leader_contribution = 1.0 - (0.3 * path->parallel_workers);   23.         if (leader_contribution > 0)   24.             parallel_divisor += leader_contribution;   25.     }   26.    27.   return parallel_divisor;  28.  }                                                                                    图1.并行执行框架因此当并行执行的worker为2的时候，每个工作进程所分配得到的工作量为：10000048.0 / (2 + (1 – 0.3 * 2)) = 4166686.66 rows.这就是代码片段6第13行得到每个worker处理的元组(rows)数目。这里需要注意的是虽然是并行扫描但是IO代价仍然是按照全表扫描的代价计算。这主要是因为每个并发进程在同一份数据上按照block-by-block的方式顺序推进全局next指针，这等价于全表扫描。总结PostgreSQL的口号是开源数据库中最强大的关系型数据库系统。其实业界也一直将其称为开源数据库的oracle。此言不虚，因为很多企业客户在去“O”问题上选择用PostgreSQL替代Oracle。PostgreSQL不仅在语法上高度兼容Oracle而且在性能上也向Oracle靠拢，例如并行查询特性就是PostgreSQL引以为豪的特性之一。PostgreSQL实现了并行scan，merge-join，hash-join，以及partition-join等。这篇文章对PostgreSQL的并行查询进行了初步的分析，探讨了并行工作进程之间的工作量分配，查询执行代价的计算，以及并行查询的总体框架。后续我们计划对PostgreSQL的并行join算法进行深入探讨以更好地了解PostgreSQL的并行查询功能。

1. Tuning-Kit-release-2.1.T5.zip版本2. centos 7.63. 进程分析任务->进程/线程性能分析4.  问题：选择进程ID，且只能选择进程ID，但图出现了线程曲线。

1. Tuning-Kit-release-2.1.T5.zip版本2. centos 7.63. 进程分析任务->进程/线程性能分析4.  问题：   1. TID与PID不应该相同   2. 所有TID CPU都是0，实际后面附的截图不为0进程CPU：线程CPU：

在鲲鹏aarch64平台上，多线程并行使用okhttp进行文件上传，发现出现了空指针，下标越界等异常。而同样的代码在x86平台运行无异常情况。遂对调用okhttp的代码进行抽取并将问题缩小范围，得到如下的一段问题重现代码，仅包含简单的原生java代码，不涉及任何第三方包的引用。package test2; import java.util.ArrayList; import java.util.LinkedList; import java.util.concurrent.Callable; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Future; public class RequestTest { public static void main(String[] args) { outter: for (int i = 0; i > -1; i++) { ExecutorService exs = Executors.newCachedThreadPool(); ArrayList<Future<String>> lst = new ArrayList<>(); ArrayList<HttpCall> calls = new ArrayList<HttpCall>(); for (int j = 0; j < 100; j++) { HttpCall call = new HttpCall(); calls.add(call); } for (HttpCall httpCall : calls) { Future<String> future = exs.submit(httpCall); lst.add(future); } for (Future<String> future : lst) { try { String result = future.get(); if (!"".equals(result)) { exs.shutdown(); break outter; } } catch (Exception e) { e.printStackTrace(); } } exs.shutdown(); System.out.println("No." + i + " done!"); } } } class HttpCall implements Callable<String> { public static LinkedList<Object> lst = new LinkedList<Object>(); @Override public String call() throws Exception { try { for (int i = 0; i < 200; i++) { synchronized (HttpCall.class) { if (!lst.isEmpty()) { lst.remove(0); } } Thread.sleep(1); synchronized (HttpCall.class) { if (lst.size() < 8) { lst.add(new Object()); } } } } catch (Exception e) { e.printStackTrace(); return "-"; } return ""; } }以上代码x86平台运行无异常，但是拿到鲲鹏aarch64平台下却会有小概率抛出空指针异常：系统信息和jdk版本如下：

文档位置已迁移至如下链接：https://support.huaweicloud.com/prtg-kunpenghpcs/kunpenghpcs_prtg_0020.html

文档位置已迁移至如下链接：https://support.huaweicloud.com/tstg-kunpenghpcs/kunpenghpcs_tstg_0002.html

1 apr简介APR为上层的应用程序提供一个可以跨越多操作系统平台使用的底层支持接口库。使得平台细节的处理进行下移。对于应用程序而言，它们根本就不需要考虑具体的平台，不管是Unix、Linux还是Window，应用程序执行的接口基本都是统一一致的。因此对于APR而言，可移植性和统一的上层接口是其考虑的一个重点。而APR最早的目的并不是如此，它最早只是希望将Apache中用到的所有代码合并为一个通用的代码库，然而这不是一个正确的策略，因此后来APR改变了其目标。有的时候使用公共代码并不是一件好事，比如如何将一个请求映射到线程或者进程是平台相关的，因此仅仅一个公共的代码库并不能完成这种区分。 2 环境信息2.1 环境信息类别子项版本获取地址OSCentOS7.5 Aarch64href="https://www.centos.org/download/" https://www.centos.org/download/服务器配置16U16GB40GB软件apr1.7.0http://mirror.bit.edu.cn/apache//apr/apr-1.7.0.tar.gz3 软件移植3.1 环境准备OS安装类型：CentOS-7.5-aarch64-1804。 注：操作系统安装使用最小简化版安装(如上图)，其余步骤安装一般安装操作系统步骤即可。 3.1.1 相关软件下载上传1、 上传CentOS 7.5系统ISO镜像文件至服务器2、 上传apr源码包至服务器目录下,如/opt, 下载地址如下：http://mirror.bit.edu.cn/apache//apr/apr-1.7.0.tar.gz3.2 安装apr    1、 安装apr    上传以下脚本至要安装apr的服务器上的任意目录，如/opt。    （apr_install.sh）    添加执行权限：    chmod +x /opt/apr_install.sh    执行脚本    sh /opt/apr_install.sh    2、 提示apr install success表示安装成功。  3.3 验证执行1.执行cat /usr/local/apr/lib/pkgconfig/apr-1.pc命令，简单使用apr是否正常，看到以下内容则表示apr已经安装成功。 4 参考信息https://www.huaweicloud.com/kunpeng/software.html

1 JMeter简介JMeter是Apache组织基于Java的压力测试工具。用于对软件做压力测试，能够对HTTP和FTP服务器进行压力和性能测试，也可以对任何数据进行同样的测试（通过JDBC）。安全的可移植性和100%纯java。完全Swing和轻量组件支持（预编译的JAR使用javax.swing.*）。完全多线程框架允许通过多个线程并发取样和通过单独的线程组对不通的功能同时取样。精心的GUI设计允许快速操作和更精确的计时。缓存和离线分析、回访测试结果。 2 环境信息2.1 环境信息类别子项版本获取地址OSCentOS7.5 Aarch64href="https://www.centos.org/download/" https://www.centos.org/download/服务器配置16U16GB50GB软件JMeter5.1.1 https://mirrors.bit.edu.cn/apache//jmeter/binaries/apache-jmeter-5.1.1.zip3 软件移植3.1 环境准备OS安装类型：CentOS-7.5-aarch64-1804。 注：操作系统安装使用最小简化版安装，但推荐安装时选择GUI选项。 3.1.1 相关软件下载上传1、 上传CentOS 7.5系统ISO镜像文件至服务器2、 上传apache-jmeter-5.1.1.zip软件包至服务器目录下下载地址：https://mirrors.bit.edu.cn/apache//jmeter/binaries/apache-jmeter-5.1.1.zip  3.2 安装JMeter    1、 如果当前服务器不能访问外网，请先配置本地yum源。        a. 上传以下脚本至要安装ActiveMQ的服务器上的任意目录，如/opt。        （local_yum_install.sh）        b. 执行如下命令添加执行权限：        chmod +x /opt/local_yum_install.sh        c. 执行如下命令安装配置本地yum源        sh /opt/local_yum_install.sh         2、 上传JMeter软件包，apache-jmeter-5.1.1.zip至服务器，如/opt目录下    3、 下载安装解压工具        yum install unzip –y    4、 解压安装包        unzip /opt/apache-jmeter-5.1.1.zip4 软件运行4.1 验证执行    1.进入到JMeter安装目录/bin目录执行jmeter.sh文件        /opt/jmeter.sh    2.加载以下图片表示安装成功   5 参考信息https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/resources/porting-and-tuning/building-blast-with-arm-compiler/single-page

copy是cqlsh中的逻辑导入导出命令。包括两个命令COPY TO / COPY FROM.使用这组命令可以在Cassandra与其他RDBMS或Cassandra之间迁移数据。目前已经支持csv, json文件格式以及标准输出和输入。 1. 如何执行copy?    1. 执行copy时，首先要启动cqlsh. 启动cqlsh后，接着执行copy命令。如下1    ./cqlsh 127.0.0.1 9042 -u {user_name} -p {password}1COPY cycling.cyclist_name TO '/home/cas/copydata';2. 如果数据量很大，可以放在后台执行。使用cqlsh的-e 参数。-e 参数用来后台执行给定的语句，然后退出。命令如下1    ./cqlsh 127.0.0.1 9042 -u {user_name} -p {password} -e "COPY cycling.cyclist_name TO '/home/cas/copydata'";2. COPY TO 1    COPY <table name> [(<column>, ...)] TO <file name> WITH <copy option> [AND <copy option> ...]COPY TO 常见的参数有: NUMPROCESSES, RATEFILE, PAGESIZE, BEGINTOKEN, ENDTOKEN, MAXATTEMPTS, MAXOUTPUTSIZE; 新增的参数有: RESULTFILE, DATAFORMATS, WHERECONDITION.重点介绍常见和新增的参数，关于其他COPY TO的参数可以参考Cassandra官网文档:copy-to1. `file name` 导出时，可以指定文件名称为目录, 也可以指定文件名称为文件。默认导出到文件。如果指定导出文件为存在的目录时，将会按照range范围导出到目录下的不同的文件中，如果某一个range范围导出没有数据，则不会生成文件。如果指定的文件名是文件，那将会导出到指定的文件中。如果文件不存在，则新创建该文件。1    ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata'"1    ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata/cycling.cyclist_name'"2. `NUMPROCESSES` 导出的线程数。在导出时，会将range范围进行细分。导出的线程数越多，细分range的范围数也就越多。但当线程数太多的时候，容易对服务端造成压力，造成导出失败。所以要选择一个合适的线程数进行导出，默认的线程个数是（CPU核数 - 1）3.  `RATEFILE` 速率文件。指定文件路径后，会打印导出过程的瞬时速率，可以用来评价导出的性能。4.  `PAGESIZE` 在一次page查询中。获取的row数。 默认为 1000。 建议不要设的调小。设置太小会影响导出性能。5.  `BEGINTOKEN， ENDTOKEN` 执行要导出的range范围。默认是全部数据导出。6.  `MAXATTEMPTS` 每一个查询重试的次数。如果某次查询达到最大重试次数，那么导出将会直接失败。 7.  `MAXOUTPUTSIZE` 每一个导出文件中的最大的行数。如果导出数据大于这个值。将会轮转生成另一个文件。默认是不限制的。1    ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata/cycling.cyclist_name' with MAXOUTPUTSIZE=1"8.  `RESULTFILE` 导出结果文件路径，如果不设置。默认生成在当前执行目录下。如果执行目录中存在之前的结果文件，将会重命名之前的结果文件。导出结果的内容主要包括：导出成功与否，总共导出的行数和速率，导出的range范围数，以及成功失败的range范围数，并展示每一个range范围的结果和导出的行数。9. `DATAFORMATS` 导出的数据格式。取值为csv， json。默认为csv格式。指定为json时，导出为json格式的数据。10. `WHERECONDITION` 导出的查询条件。支持查询条件的导出。对于非主键列，如果通过索引来查询，提高导出性能。         1. wherecondition 格式如下 `[key(operators)value,key(operators)value...]`        2. operators 支持 `[">=", "<=", ">", "<", "="]`，例如: `'keyspace_name=system,table_name>=local'`        3. 如果value中包含有特殊字符，比如保留字符 【" ,><=’】, 那么需要给字符加上双引号，例如：`'keyspace_name=system,table_name>="loc>=al"'`一个完整的COPY TO例子：1    nohup ./cqlsh 127.0.0.1 9042 --request-timeout=3600 --debug -e "COPY nihao.sz_user to '/home/cas/copydata' with WHERECONDITION='update_timestamp=1' NUMPROCESSES=12 AND RATEFILE='rate.txt' AND RESULTFILE='export_result' AND dataformats='json';"  >export.log 2>&1 &3. COPY FROM   1    COPY <table name> [(<column>, ...)] FROM <file name> WITH <copy option> [AND <copy option> ...]COPY FROM 常见的参数有: NUMPROCESSES, MAXROWS, INGESTRATE, ERRFILE, MAXBATCHSIZE, MINBATCHSIZE, CHUNKSIZE， MAXPARSEERRORS, MAXINSERTERRORS, SKIPROWS, SKIPCOLS;新增的参数有: DATAFORMATS.重点介绍常见和新增的参数，关于其他COPY FROM参数可以参考Cassandra官网文档： copy-from1. `file name` 导入数据时，指定导入的文件路径，可以是一个目录，或者是一个文件，或者是逗号分隔的文件名列表。如果是目录，则导入该目录下的所有文件。2. `NUMPROCESSES` 导入的线程数3. `MAXROWS` 导入的最大行数。默认不限制。4. `INGESTRATE` 每一秒导入的最大行数。默认为 1000005. `ERRFILE` 导入失败的列将放在这个文件中。6. `MAXBATCHSIZE` 每一次batch导入的最大行数。默认为207. `MINBATCHSIZE` 每一次batch导入的最小行数。默认为28. `CHUNKSIZE` 导入主线程给子线程每次传递的行数，默认为 10009. `MAXPARSEERRORS` 可以忽略的语法解析错误的最大行数。默认不限制10. `MAXINSERTERRORS` 可以忽略的写入失败的最大行数。默认为100011. `SKIPROWS` 导入时初始跳过的行数。默认为0，不跳过12. `SKIPCOLS` 导入时忽略的列名，以逗号分隔。默认不忽略。13. `DATAFORMATS` 导入的数据格式。取值为csv，json。默认为csv格式。数据为json格式时，必须指定为json。一个完整的COPY FROM例子：1    nohup ./cqlsh 127.0.0.1 9042 --request-timeout=3600 --debug -e "COPY nihao.sz_user FROM '/home/cas/copydata' with NUMPROCESSES=12 AND RATEFILE='rate.txt' AND dataformats='json';"  >import.log 2>&1 &

基于CSE和Vert.x 开发API Gateway。单机多用户访问下，APIGateway CPU占用飙高，页面响应增长。环境上apigateway 进程号：1286791. 查看CPU占用top -p 128679查看线程cpu占用。ps -mp 128679 -o THREAD,tid,time  128722 占用高。发现有2个线程占用高，最高到80-90%。2.查看堆栈3. 修改APIGateway配置，增加thread-count值后能缓解，但是cpu占用依然很高。求助，是APIGateway微服务配置问题还是APIGateway实现问题？