点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
故障现象
XX医院平台是布署在云平台上的应用。前端查询药品或更新记录时，点击确认按扭转圈圈一段时间（响应超时），才能提交成功。
据业务侧描述，业务网关响应，一般是在100MS以内，在今天有时会飚升到1000多MS延时非常不稳定。
问题分析及处理
2.1 SQLSERVER所在主机CPU分析
主机有128G内存64CPU,CPU有时飚升至80%，有可能是SQL问题。
2.2 SQLserver性能SQL
对所在的SQL进行分析，SQL在数据库中执行效率非常高，未发现执行很久且缓慢的SQL语句。同时发现一些定时任务会耗一定CPU，经和业务沟通说这些在之前未做任何改变。
SELECT
dec.session_id AS [SPID]
,prc.blocked AS [锁源进程]
,des.status as [状态]
,prc.lastwaittype as [等待类型]
,substring(dest.text,1,512) as [执行脚本(缩)]
,des.cpu_time as [CPU]
,des.reads as [Reads]
,des.writes as [Writes]
,dec.connect_time AS [连接时间]
,DATEDIFF(minute, dec.connect_time, GETDATE()) AS [连接时间(分)]
,des.login_name as [登录名]
,des.[program_name] as [应用程序]
,des.host_name as [客户端]
,db_name(prc.dbid) as [数据库]
,prc.waitresource as [等待资源]
,dec.client_net_address as [客户端IP]
,dec.local_net_address as [服务器端IP]
,dec.net_transport as [连接方式]
,dec.protocol_type as [协议类型]
FROM master.sys.dm_exec_sessions des(nolock)
INNERJOIN master.sys.dm_exec_connections dec(nolock)
ON des.session_id = dec.session_id
INNERJOIN master.sys.sysprocesses prc(nolock)
ON des.session_id = prc.spid
CROSSAPPLY master.sys.dm_exec_sql_text(dec.most_recent_sql_handle) dest
WHERE des.is_user_process = 1 AND des.session_id <> @@spid AND des.status<>'sleeping'
ORDERBY dec.session_id ,dec.client_net_address;
2.3 分析底层IO
发现SQLSERVER所属服务在响应耗时在不断的抖动和主机CPU抖动相对应，怀疑是否存储上存在性能瓶颈。
经咨询该数据库运行在存储用的SAS硬盘非SSD，由于存储侧目前无法替换成SSD，暂时不能解决。
2.4 CEPH参数优化后，延时消失，恢复正常
在CEPH关闭存储系统的 Deep Scrub 功能，该功能是扫描磁盘上的所有数据并计算crc32校验值。
通过对比各个对象副本的数据和元数据，完成副本一致性检查，这个是非常影响存储性能，经过和存储侧沟通，对该参数进行关闭，响应延时到100MS以内，业务恢复正常。
案例总结
在使用CEPH开源存储系统时，deep scrub会大大影响IO性能，可关闭该参数；
或使用高性能磁盘时，对该参数开启，在不影响IO性能或者影响比较小的情况下，可以提高数据读写的完整性，总之需要根据具体情况进行分析。
本文作者：唐田寿(上海新炬中北团队）
本文来源：“IT那活儿”公众号
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
