TAn的个人空间

TAn： 监控了一下，每次报错的时候，update workitem表的时间都比较长。 最长达到了4s，索引我已经重建过了，每天还是会出现一些，有没有什么优化建议。 [附件] [附件](2019-01-16 08:59)

回复

武汉技术支持团队：数据库死锁了，直接用SQLProfile监控一下，如何用优化工具优化(2019-01-15 09:28)

回复

TAn：已经发展到任何流程都可能出现了，看下面的日志 结束节点用了2s。 @武汉技术支持团队 被这个问题折腾的头都大了，这个错是sql报的还是引擎自己的锁？ 2019-01-14 09:34:58 : DefaultEngine: InstanceManager.SendMessage...(2019-01-15 08:41)

回复

TAn：@武汉技术支持团队 @liam 加了延迟还是会出现这个问题，非常的奇怪。 完全找不到原因出在哪，真是头大 [附件][附件](2019-01-10 15:17)

回复

TAn： 上次删除传阅以后重启过服务器，所以不知道是删除传阅的问题的还是重启了服务器导致的。 然后我又把删除的传阅恢复了回去，还是会出现。 我现在的笨办法就是把待办的页面加载时加了1s的延迟，最近没有发现问题了。 但是个治标不治本的办法，还是得想办法解决。 感觉还是待办这个表的问题，但找...(2019-01-08 09:43)

回复

liam：有没有重启过服务器？记得你之前搞过那传阅的取消。不知道你搞的对那个有无影响。 200来万的数据没见出问题。。实在不行，做归档吧(2019-01-05 11:21)

回复

TAn：@武汉技术支持团队 你微信多少，有没有时间帮我远程看一下。 昨天我重建了ot_workitem索引，出现频率低了一些，但还是会出现。 蛮影响用户正常使用的。(2019-01-04 11:49)

回复

TAn： 发现报的错都集中在对ot_workitem表的数据读取。 是否任务提交以后，引擎在对ot_workitem表进行操作，锁住了。 现在ot_workitem表中大概85w条数据。(2019-01-03 10:51)

回复

TAn： 看报错的是这行代码 int workflowCount = this.Engine.Query.CountWorkItem(this.UserValidator.UserID, WorkItem.WorkItemState.Unfini...(2019-01-03 09:24)

回复

TAn： 没有传阅到整个公司的，都是弄的组或者人。 原来有个流程传阅很多，已经修改过来了。 大部分流程用传阅都比较慎重。 这几天好多流程都会出现这个问题，而不是针对某个流程。(2019-01-03 09:21)

回复