ArcGIS Server浏览地图服务无响应原因分析说明

1、问题描述

从4月17号下午5时起,至18号晚9点,客户单位部分通过ArcGIS Server发布的地图服务(该部分地图服务的数据源为数据库SJZX)无法加载浏览,表现为长时间无响应。同时,通过ArcMap加载数据库中的要素类时,表现为"卡死",并长久无响应。

2、问题观察

通过收集该时间段内某1小时之间的性能数据,得到其耗时排名前6的SQL如下:

ArcGIS Server浏览地图服务无响应原因分析说明_第1张图片

    发现SQL ID 为gj2c1wk1brmaa 和 bxqcnpc5q5330 的两个SQL,其在1个小时的跨度内,执行次数为0。这说明,在这1个小时之内,该SQL一直在执行,且没有结束。SQL ID为bxqcnpc5q5330的SQL执行时间为3624秒,接近完整的1小时(3600s);SQL ID为gj2c1wk1brmaa的SQL执行时间为271786秒,这说明有271786/3600=75个进程在执行这个操作,且持续1小时未结束。

继续观察,发现这两个SQL都与TABLE_LOCKS表有关,SQL ID为bxqcnpc5q5330的SQL在执行时需要获得该表的排它锁;SQL ID为gj2c1wk1brmaa的SQL在执行时需要获得该表的共享锁(即TM锁)。猜测,这两条SQL长时间未执行结束,其根本原因在于无法获得其所需要的锁,即TABLE_LOCKS上发生了锁的阻塞。 

 3、问题分析

SQL ID为bxqcnpc5q5330的SQL需要获得排它锁,它可能被其它的排它锁或共享锁(TM锁)阻塞

SQL ID为gj2c1wk1brmaa的SQL对TABLE_LOCKS表中的记录进行删除操作,需要获得该表的共享锁(TM锁),它可能被排它锁阻塞

我们作两种假设:

   1)TABLE_LOCKS上已经有其它的排它锁

这时候,符合bxqcnpc5q5330、gj2c1wk1brmaa两个SQL的表现。但排名前6的SQL中,还有cffvq2hst53md、00xnu55uqdns0、3ub7rzsp3rpyh 三个SQL有成功执行的次数(这三个SQL分别是向TABLE_LOCKS表中增加记录、获得TABLE_LOCKS的共享锁、根据PID(进程ID)删除TABLE_LOCKS表中记录),如果TABLE_LOCKS上已经有其它的排它锁,这几个SQL也会被阻塞,不可能执行成功。因此TABLE_LOCKS上已经有其它的排它锁的假设不成立。

           2)TABLE_LOCKS上有未释放的共享锁(TM锁)

这时侯,TABLE_LOCKS上的共享锁(TM锁)会阻塞bxqcnpc5q5330 SQL,但bxqcnpc5q5330 SQL之前的共享锁(TM锁)请求不会被阻塞(包括cffvq2hst53md、00xnu55uqdns0、3ub7rzsp3rpyh),bxqcnpc5q5330 SQL之后的共享锁(TM锁)请求会被bxqcnpc5q5330 SQL的排它锁请求阻塞(尽管bxqcnpc5q5330 SQL还没有真正获得到锁,但它在锁的队列中会阻塞发生在它之后的SQL)。因此,该假设符合目前观察到的现象。

4、现象模拟再现

根据上述问题分析结果,我们可以基于假设条件进行现象模拟再现。

      1)TABLE_LOCKS上有未释放的共享锁(TM锁)

当对TABLE_LOCKS执行了新增、删除、更新操作,但未提交事务时(有可能是事务异常结束),共享锁(TM锁)将不会释放。

2)对TABLE_LOCKS请求排它锁

当使用ARCMAP、ARCCATALOG对database connection中的对象(包括要素类、要素集、表等)进行删除操作时,会请求排它锁。

ArcGIS Server浏览地图服务无响应原因分析说明_第2张图片

 

该会话请求的锁模式为6,即排它锁。

ArcGIS Server浏览地图服务无响应原因分析说明_第3张图片

已经开始出现"卡死"并长时间无影响的现象。

3)对TABLE_LOCKS请求共享锁

通过ARCMAP、ARCCATALOG加载图层时,需要向TABLE_LOCKS中增加1条记录,此时需要请求TABLE_LOCKS表上的共享锁。

ArcGIS Server浏览地图服务无响应原因分析说明_第4张图片

此时加载图层已被阻塞。

4)释放第1)步中的共享锁(TM锁)

ArcGIS Server浏览地图服务无响应原因分析说明_第5张图片

ArcGIS Server浏览地图服务无响应原因分析说明_第6张图片

所有的阻塞都迎刃而解了。

你可能感兴趣的:(ArcGIS Server浏览地图服务无响应原因分析说明)