[if !supportLists]1、 [endif]问题现象描述

开户流程50用户并发情况，/mb/pj6vsv/visitor/sms-otp-verify-v2接口50并发响应时间超过6秒钟,应用服务器资源很低。

[if !supportLists]2、 [endif]问题定位过程

2．1、进入usercenter服务控制台，jps查看当前运行服务进程PID

[if !vml]

[endif]

2.2、先通过jdk自带的工具jstack保存一下JVM进程对应的栈信息，具体的命令是：

jstack -l 1> 1-stack，记录对应进行的PID，多记录几次线程堆栈的快照，方面后续在快照中找对应的线程调用内容。

[if !vml]

[endif]

2.3、查看生成的线程堆栈快照分析。查看到读取mysql相关的代码

截图待补充

2.4、考虑是数据的问题，进入数据库服务器查看资源情况。

[if !vml]

[endif]

数据库CPU使用率达到100%

2.5、查看数据库慢sql统计，其中updaate语句执行时间达到6秒或7秒钟。

[if !vml]

[endif]

2.6、分析sql语句。

UPDATEt_visitor  SET    status = N,    gmt_modified =NOW(),   modifier = creator    WHERE is_deleted = N   AND user_id = N

此sql语句执行计划扫描11w+数据记录，后续的where条件没有索引。

2.7、对比SIT发现此数据表存在user_id索引，所以在性能环境增加此索引。

[if !vml]

[endif]

2.7、增加索引后慢sql问题解决，响应时间从6秒钟降低到300+毫秒。但是数据库CPU使用率依然达到98%。

2.8、继续查看数据库慢sql，存在大量select语句的慢sql，分析此sql依然没有索引

SELECT

id,

user_id,

biz_type,

did,

mobile,

email,

user_name,

STATUS,

device_model,

device_sys_version,

country_code

FROM

t_visitor

WHERE

is_deleted = N

AND did = N

AND biz_type = N

AND STATUS = N;

2.9、对比sit数据库也没有对此sql进行添加索引，在性能环境考虑新增。

2．10、增加索引后结果如下。

性能测试环境对t_visitor数据表did字段增加索引后验证，数据库使用率从99%降至68.1%，TPS从最初14笔/秒，上升到74笔/秒。

[if !vml]

[endif]

[if !vml]

[endif]

[if !supportLists]3、 [endif]问题解决方案

3.1、如上步骤钟描述

[if !supportLists]4、 [endif]优化后结果

数据库使用率从99%降至68.1%，TPS从最初14笔/秒，上升到74笔/秒。

[if !vml]

[endif]

[if !vml]

[endif]

。

同时产生usercenter和corecenter服务CPU资源使用率过高问题，此问题的分析过程见文档：《使用jstack定位分析CPU消耗问题.doc》