记录一次麻烦的压力测试

前言：

为了提升性能响应，部署了nginx转发双网关的方式进行压力测试

系统结构图

正文：

第一次执行，发现数据量太大导致数据库服务器的cpu占用过高。

重跑压测脚本，观察数据库服务器资源占用情况，发现压测服务对应的进程占用大量的cpu资源，怀疑是某个数据库sql没有建索引。

占用期间执行sql

SELECT
    s.sid,
    s.serial#,
    s.username,
    s.status,
    ROUND(s.last_call_et / 60, 4) AS elapsed_time_sec, 
    ROUND(q.cpu_time / 1000000, 4) AS cpu_time_sec, 
    q.sql_id,
    q.sql_text,
    s.module
FROM
    v$session s
JOIN
    v$sql q ON s.sql_id = q.sql_id
WHERE
    s.status = 'ACTIVE'
    AND s.username IS NOT NULL
ORDER BY
    cpu_time_sec DESC;

sql输出

执行sql　　　　　　　　　　　　　　　　　　　　　　　　　　	        cpu_time
select * from * where arg1 = * and arg2 = *　　　　　　　　　　　　　>5S
insert into **　　　　　　　　　　　　　　　　　　　　　　　　　　　　　>3S
insert into **　　　　　　　　　　　　　　　　　　　　　　　　　　　　　>1S　
update * set * where arg3 = * and arg4 = *　　　　　　　　　　　　　　>1S

优先看了select、update后的where语句是否添加了索引。排查后确认其中select语句没有索引，添加后解决数据库服务器cpu过高问题，select语句耗时时间明显下降。

第二次执行，没注意服务器资源占用。重复启动服务导致内存超过80%，不符合压测硬性指标

排查思路：服务部署前计算服务器的可用内存【(总内存-已用内存)×0.8】，服务部署时使用的jvm等参数配置是否会超出可用内存，部署后已经性能执行前检查可用内存。

本次执行失败的原因是，通过jps -l命令查询看到了同一个应用同时启动的两个，应该是第一次启动的服务没有正确关闭。

第三次执行，数据库表空间占满内存，联系dba。

询问dba主要解决办法是1、删除数据库的执行日志；2、扩容磁盘空间

问题分析：第二次和第三次问题其实完全可以避免，在性能测试前尤其是可靠性测试，执行前需要记录当前已用磁盘、数据库表空间等信息，如果存在用满的情况直接就能看到。

第四次执行，第七个小时开始出现大量错误，到第八个小时恢复正常

如下图