开发者学堂课程【PolarDB-X 开源分布式数据库进阶课程 ：PolarDB-X 进行 TP 负载测试（三 ）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1202/detail/18329
PolarDB-X 进行 TP 负载测试
四、监控和性能指标
1.QPS
第一个就是我们一直提到的 q PS 每秒查询，从数据库层面来看的话，就是一秒内执行的 SQL 语句数，它包括了增删改查这些价格。
2.TPS
tps 是每秒事务数，从数据库层面来看，它既包含了提交的事务，又包含了 rollback 回滚的事物，要区分一下 tps 它在不同语境下的含义，在数据库系统中 GPS 是每秒执行的事务数量，而在外部应用中，它可以理解成对一个页面的一次访问就产生了一 个transaction。在区块链中 tp 它又代表了产生交易的速率，所以PS在不同的语境下是有不同含义。
3.RT
RT 是相应时间，它反映了执行一个请求从开始到说到，响应数据的时候花费的总体时间，这个指标也是用户最能直观感受到的。他在实际应用中又分为客户端 rt 与服务端 rt，当网络环境越差的时候，这两个 rt 的差距也会越大，事实上这几个性能指标相互之间是有关联的，可以想象一下，假设我们刚刚运行的 bench 是一个单线程的检查，如果说每条查询的平均 rt 是1毫秒，那么也就是说在一秒内，我们可以同步的执行1000次检查，也就是说在并发数唯一的情况下，qps 是1000。那么关于这个结论我们也是可以来验证一下的，我们在历史任务列表里面来找一下，跑的线程数唯一的一个任务是今天上午10:00跑的，查看一下任务详情，可以看到它的平均时间是0.47毫秒0.47， 1000÷0.47差不多就是比2000大一点，也就是差不多是2100的。
在介绍完刚刚提到了这三个常见的指标后，再来看一看，刚才运行两次 bench 的一个对比结果，两次结果在这里我们可以勾选两项任务，点击 PS 对比，这里要注意，如果我们数据库是能启动的话，我们会观测到第一次的压缩曲线会有一个从很低的值陡增上来的斜坡，那么我们现在是经过已经提前热身过了的，所以 qPS 曲线会比较平稳，可以发现100并发的检查和50并发检查他们的平均差距很小，只有0.04毫秒。
那么又由于100并发是50的两倍，所以实际上他们的 q PS 也是啊，100也是接近了50并发的两倍就将近18万与9万多，事实上如果再继续加大并发，随着 rt 的上升，q PS 的线性增长效果也会越来越不明显，就是说随着并发的增长，PS 的增长比例会越来越低，这个线下环境大家也可以自己实验验证，很多时候在压测的时候大家会问系统只能跑到几千或者几万的 q PS 是否正常？也就是他想知道理论上的最高 q PS 值是多少？一般来说想要达到理论最高的 q PS，我们希望的是把计算资源尽可能的消耗完，通常就是表现在 CPU 的利用率上，当然根据 fold 的不同，也有一些其他的限制因素，而一般影响到 CPU 的利用率因素，它有以下几种，比如 io 包括了磁盘，io，网络等，还有共享资源的竞争锁或者阻塞队列之类的，以及其他一些依赖，一些别的依赖服务吞吐量低，造成当前节点的这个CPU利用率上不去等等情况，这些都是属于定位性能瓶颈的隐患，这里我们就不展开描述。
那么测试完之后，我们接下来再来运行一下 tpcc ，我也是提前已经导入好了数据，我们来切换一下酷选择自动判断店铺模式，可以看到是以 oo 模式来建一个 tb cc 仓库，点击校验数据它会提示所有表都存在，然后有两百个仓，且数据集完整，这个数据就完整，也就是我们之前提到的六条校验完整性的 circle 那么这个教育完整性的作用，它就在于比如可以模拟运行 VC 的过程中 kill 掉一个 cn 进程，kill 掉一个实例恢复后再来验证下数据完整性是否能只能满足，看看有没有数据丢失或者数据不一致，这些大家也可以自己去进行实验。我们接下来来跑一下50并发的 tbcc。我们到了200层，50并发运行时长，我们选择一分钟提交任务，我们来看一下设施的结果可以看到在实时输出里面会打印出各种信息，包括连接串的参数也就是说他是我们数据库的一个连接参数还有我们的并发度，仓库数，运行时长以及之前讲到的几种事物的一个混合比例。
4.饱和度
我们再来讲一讲与性能息息相关的监控指标，根据谷歌的监控指标可以分为这四类饱和度，延迟 latency 流量 traffic 错误 errors 饱和度，衡量的是资源的使用量，比如 CPU 使用率，内存使用率，iOS 使用率，还有比如任务队列的长度延迟，正如我们之前所提到的，反映了完成操作所需要的时间，比如网络延迟，i will wait，接口调用延迟，数据同步延迟等等量则衡量了防满的系统繁忙的程度，比如磁盘流量，网卡流量，核心接口的请求速率，对于一个 web 服务来说可能就会更关心请求的速率，最后是错误，这个错误它既包含了显示错误与影视错误，也就是 explicit error与 error implicit errors，比如说他可能是直接就报错了，返回了一个错误，也可能是他没有报错，但是返回了非预期的结果反映了系统，它反映了系统的当前运行状况，一般体现为当机进程 crash 准备切换核心功能错误等，
同时我们不同的角色也会关注不同的指标下，比如 dba，他可能更关注数据库的饱和度，也就是说它可以根据业务周期来对系统的性能水位进行一个评估，从而判断是否要进行扩缩容，升降配之类的操作，对于应用开发人员来说则会更关注 q PS 和 rt 这两个指标我们来看一下刚刚跑完的这个 tb cc 50并发的一个结果。可以看到在这里面可以展示出
实时的这个tp mc曲线，大家在下面可以把这个运行时间设置的长一点，看看它是否有什么波动变化，比如说会不会随运行时间变长，有一个性能衰减的情况。下面我们再调整tb cc为100个并发来试一试。
点击填充，上次运行参数设置为100个并发现，接下来要结合我们刚刚提到的几项监控指标来进行一下实际演练，比如在 Linux 系统上可以查看监控指标的命令有很多，最常见的比如 top 命令，这里我们可以看到左边是我们的 cn 进程所在的1s上面就有一个 JAVA 进程，而右边则是所在的一上面有三个满色客d进程还有就是 h top 跟 top 的功能。还有包括了 CPU，磁盘，网络，还有页的换入换出等，可以看到在 cn ecs 上是几乎没有，磁盘的读写的，但是每秒的写入量就会非常的多。那么还有一些比如通过命令来看几个特定的 CPU 和现在可以看到我们已经没有压力了，说明已经跑完了。
可以看到现在就是这个100平方的实际数值还是变化的，实际数值要高，但是他并达不到一个线性的一个效果。就像我们在刚刚的压测过程中，如果只是使用 CPU 或者 io 等机器指标，他们确实可以一定程度的反映数据库的负载，但是如果这个瓶颈是在数据库系统自身上面，比如有强烈的所冲突之类的，此时底层的硬件资源利用率就难以你来衡量数据库本身的饱和度，所以这个时候就需要数据库层面能提供更多的维度的监控指标来定位性能瓶颈。
5.监控指标
我们看看 polarDB-x 提供哪些监控指标，因为监控指标很多，这里只截图列举了一部分，由于 PolarDB-x 是计算存储分离的，所以我们的监控指标也分为计算节点和存储节点两个大类，计算节点这里有 CPU 内存使用率，逻辑GPS，物理 PS rt，物理 rt 之类的存储节点则 CPU 内存使用率，存储空间的还有8 Pro 命中率，读写次数，行数，iOS 等情况,结合以上这些节和以上这些监控信息,可以让有经验的这边或者数据库开发人员,能更容易的定位数据库的性能瓶颈，从而对当前的数据库进行优化.
现在还有多的时间，比如说刚刚同学提到的建仓是不是也是在这里建,我们完全可以切换到一个新的数据仓，选择建库模式。同样的，在这里也是可以看到，新建出来的 b test 答案，现在是一个空的数据库，那么我们来导入一下测试数据，比如我们选四张表，100万的数据量100万的数据量，然后我们发数为四，这里的并发数一般是建议为表的整数倍一到四倍，当然我们也可以多一点并发数，它就会倒得更快一点。我们可以来看看这边导入的一个情况，他就会分为多个线程去导入 sb，四张 s test 的表我们通过说也可以看到就除开ov这条语句。一共就是有八条连接在并发的导入数据，可以看到每秒大概是1万行的一个插入速度，所以导入的速度估计还要一段时间，现在只导入了1/3。那么这些具体的过程大家也可以自己在云起实验室里面体验得到，而且由于它的部署非常简单，大家在线下环境中也是可以直接直接试验的，因为云起实验室的规格比较小，只能够做到一个体验的作用，没有办法体现就是压测的实际作用.
今天讲的 polarDB-x 对进行 tp 负载测试到这里也结束了，内容主要是基于 benchmark boot 的平台进行 bench,欢迎大家后续在云起实验中里面或者自己的线下环境进行体验，有任何问题和建议也可以发在群里.
