记录一次并发压力测试的调优过程，希望能在大家碰到相关工作时有一定的帮助。
项目背景忽略。

大致的测试内容为，对某个页面的功能进行压力测试，相关语句有两条：
一条SELECT (*) FROM xxxxxx，显示记录总数
另外一条 SELECT * FROM xxxxxxx ORDER BY xxx DESC LIMIT 0,10，排序后分页显示相关内容。

通过 JMETER 进行 200 并发的压力测试，先看一下调整前的测试情况

可以看到，200 并发下的业务流程响应时间在 28s 左右。

这里我们需要收集相关信息
1、压力测试过程中的 TOP 情况

首先我们关注 CPU 的使用情况，CPU 3185%，现场 CPU 为 32 核，基本吃满，但是我们更需要关注的是 CPU 使用的 USR/SYS 比例

这里我们看到：只有 21.8% 的 CPU 是 USR 的，其余 78.2 都在 SYS 上，说明系统中有大量的等待时间或者系统中断，我们需要更多的信息来进行判断

2、抓取数据库压力测试过程中的堆栈
通过 pstack 或者 gdb 工具抓取压力测试过程中的数据库进程堆栈。
打开堆栈文件，搜索 ntsk_process_cop，这个是活动会话的起始函数，我们取 3 个活动会话的堆栈（堆栈可以进行去重，这里不展开描述）
线程 1：

线程 2：

线程 3：

这里只列举了 3 个，实际在堆栈中，我们可以发现大量的活动会话线程最上层都停留在pthread_mutex_lock，是由 buf4_enter 发起的，而 buf4_enter 大多又是由 nbtr_root_get 发起，这个表示：在查询过程中，存在大量需要抓取相关 B 树根页的操作，而根页可能落在某片 BUFFER POOL 上，进入该 BUFFER POOL 的请求很多，导致其临界区发生大量的等待，所以导致 SYS CPU 非常高，整体测试结果不理想。

这里我们需要调整两个参数：
① FAST_POOL_PAGE，原始 3000，调整至 99999，FAST POOL PAGE 表示快池中的数据页页数，由于 FAST POOL 和普通的 BUFFER POOL 不一样，其没有相关临界区操作，可以直接读取到数据页，因此，放大该池可以让更多的热数据进入到该池内，减少频繁访问页时导致的冲突。

② ENABLE_FREQROOTS，原始参数 0，表示只有特定标记的表的数据才会进入到 FAST POOL 中，调整为 1，表示运行过程中动态统计页的访问信息，当访问次数和频率到达某个阈值时，将其加入到 FAST POOL 中，尽量把热页放到 FAST POOL 中，减少并行访问冲突。

这两项修改致力于减少由于热页冲突导致的系统等待，修改完成后我们再次进行测试，并抓取测试过程中的数据库堆栈。
打开堆栈，搜索 ntsk_procss_cop，同样的，这里选取几个活动会话线程为例进行讲解
线程 1：

从这个会话可以看到，堆栈最后停留在 pthrad mutex lock，由 mem2_malloc_ex 发起，这里有几个概念，每个活动会话有自己的运行时内存池 vm_pool，和自己的会话内存 sess_pool，当 VM_POOL 和SESS_POOL 大小不足时，会向主内存池 MEM_POOL 进行内存申请挂到自己的私有池上对 VM_POOL 和 SESS_POOL 进行扩展，而老一点的版本 MEM_POOL 是不进行分片的，如果需要扩展 VM_POOL 或 SESS_POOL 的会话很多，会在主池 MEM_POOL 的临界区上产生大量的临界区等待。为了避免这种情况，我们有两种方式进行调整：

1. 减少会话运行语句需要的内存（调整SQL计划，修改参数等，这里不展开）
2. 放大 VM_POOL 和 SESS_POOL，尽量让其不发生扩展，不与主内存池发生交互，减少冲突

由于我们还没有对 SQL 本身进行调整，这里采用第二种方式进行调整。我们需要查询内存池相关的使用情况，运行过程中查询 VM POOL 和 SESS_POOL 的平均大小，最大大小

我们可以看到 VIRTUAL MACHINE(VM_POOL) 平均大小 5M，最大大小 40.9M左右；SESSION(SESS_POOL) 平均大小3M，最大大小 8M 左右，由于每个会话上跑的语句差不多，只是参数不同，我们可以大致认为，该业务执行过程中 VM_POOL 可能被扩展到 45M 左右，SESS_POOL 可能被扩展到 9M 左右，所以我们调整参数
VM_POOL_SIZE 45000
VM_POOL_TARGET 45000
SESS_POOL_SIZE 10000
SESS_POOL_TARGET 10000

扩大 VM POOL 和 SESS POOL，减少了内存的主池冲突，然后我们再次进行测试

测试 TOP 截图：

可以看到，USR CPU 83.1% SYS CPU 1.4%，比之前已经好了非常多，在没有对 SQL 本身进行任何调整的情况下，我们看下测试结果对比

平均响应时间已经由 28s 降低至 9.3s 效果是比较显著的。

当然优化进行到这里并没有结束，USR CPU 高只能说明 CPU 在处理实际的数据计算，但是如果执行计划不好，需要的计算量会比好的计划要高非常多，同样的计算次数，好的计划可以完成更多次的查询，后续再更新该场景的实际 SQL 语句调优过程。