问一个quartz.net的问题：运行一段时间后“卡死”

[圣殿骑士18]

为实现计划任务的通用性，我使用了quartz.net代替自己写的简易计划。
但在客户使用过程中，发现运行一段时间后，程序就卡住了，感觉应该是死循环了。这个时间可能是半个月，或者一个月，没有规律。
计划任务用于两个数据库之间同步，负载比较轻。代码实现也基本上按照网上的一般实现，采用配置文件定义计划任务。
出现问题时，日志也没有输出什么异常，就是不同步了，查看进程，可以看到这个进程的cpu占用在49-50%，一直不下来。

请教问题的原因？

程序代码和配置实现：
1、设置和启动代码


2、计划任务整体架构设计成插件模式，即执行的业务代码主体使用独立的项目实现，编译好之后，放在计划任务程序的子目录下，计划任务使用probing机制搜索此dll。为了尽量不影响主程序的运行，我代码中还用应用程序域（AppDomain）加载并执行的


3、配置计划任务：

[圣殿骑士18]

另：同步方法SyncGoods()并不复杂，平时执行也正常。应该不会卡死在SyncGoods()中，猜测是quartz本身哪里卡了。

[wanghui0380]

不猜，在发生问题后使用任务管理器抓出dump，然后根据dump看“卡”在什么地方了

[圣殿骑士18]

引用 2 楼 wanghui0380 的回复:

不猜，在发生问题后使用任务管理器抓出dump，然后根据dump看“卡”在什么地方了

这是什么操作？我不会，请再说明一下细节？

[圣殿骑士18]

我百度了下，发现分析dump还是需要仔细研究的

[圣殿骑士18]

除了dump分析，还有其他建议吗？

[正怒月神]

windows 日志也没有记录吗？

[以专业开发人员为伍]

你可以每隔 24 小时重新删除、重建一次。

[圣殿骑士18]

引用 7 楼 sp1234 的回复:

你可以每隔 24 小时重新删除、重建一次。

因为进程没有出错。经检查windows也没错误日志

[圣殿骑士18]

引用 8 楼 daixf_csdn 的回复:

[quote=引用 7 楼 sp1234 的回复:]
你可以每隔 24 小时重新删除、重建一次。

因为进程没有出错。经检查windows也没错误日志[/quote]
这也是个办法

[娃都会打酱油了]

感觉是你数据库或程序有死锁了

[正怒月神]

引用 6 楼 hanjun0612 的回复:

windows 日志也没有记录吗？

如果windows 日志没有记录。
那么你去看看sql操作日志，看看是不是数据库操作的死锁问题？

[smthgdin_020]

查看windows日志和数据库日志，看有什么问题先，不然按照现在这个情况不好准且定位问题，都是靠猜。

[早酒晚舞]

6666666666666666666666

[圣殿骑士18]

引用 12 楼 smthgdin 的回复:

查看windows日志和数据库日志，看有什么问题先，不然按照现在这个情况不好准且定位问题，都是靠猜。

数据库死锁，照理说不会占用cpu。

[圣殿骑士18]

引用 11 楼 hanjun0612 的回复:

[quote=引用 6 楼 hanjun0612 的回复:]
windows 日志也没有记录吗？

如果windows 日志没有记录。
那么你去看看sql操作日志，看看是不是数据库操作的死锁问题？
[/quote]
数据库死锁，照理说不会占用cpu。

[圣殿骑士18]

引用 12 楼 smthgdin 的回复:

查看windows日志和数据库日志，看有什么问题先，不然按照现在这个情况不好准且定位问题，都是靠猜。

windows日志无异常

[正怒月神]

引用 16 楼 daixf_csdn 的回复:

[quote=引用 12 楼 smthgdin 的回复:]
查看windows日志和数据库日志，看有什么问题先，不然按照现在这个情况不好准且定位问题，都是靠猜。

windows日志无异常[/quote]
看情况，还是会有死锁导致cpu递增的情况。
会不会是数据问题导致前一次操作没有结束？后一次任务又开始，然后死锁的情况？
信息比较少，还是挺难分析的。

[吉普赛的歌]

程序与数据库是不是放在一起的？
监控一下 每个进程的 占用 cpu 的百分比。首先要确定到底是哪个进程占用了 cpu ？
当然， 如果 cpu 高时你正好发现了， 可以直接用任务管理器来查看。

[吉普赛的歌]

每10秒一次？有没有避开维护时间？
晚上数据库可能会做一些备份、归档、索引整理的操作， 如果这个时候弄会有问题。