我们有一个基于石英的调度程序应用程序,每分钟运行大约1000个作业,这些作业在每分钟的几秒钟内均匀分布,即每秒约16-17个作业。理想情况下,这些16-17个作业应该同时触发,但是我们的第一个语句,它只是记录执行时间,执行作业的方法被称为很晚。例如 让我们假设我们从05:00到05:04每分钟安排1000个工作。因此,理想情况下,计划在05:03:50的作业应该在05:03:50记录执行方法的第一个语句,但是,它是在大约05:06:38进行的。我已经跟踪了预定作业所花费的时间,大约需要15-20毫秒。这个预定作业足够快,因为我们只是在ActiveMQ队列上发送消息。 我们已经指定石英的线程数为100,甚至尝试将其增加到200或更多,但没有增益。我们注意到的另一件事是来自调度程序的日志在最初的1分钟之后就会顺序出现,即
[Quartz_Worker_28] <Some log statement>
..
..
[Quartz_Worker_29] <Some log statement>
..
..
[Quartz_Worker_30] <Some log statement>
..
..
因此它表明,经过一段时间石英运行线程几乎是顺序的。由于将作业完成通知持久性存储(在这种情况下是一个单独的postgres数据库)和/或上下文切换所花费的时间,可能会发生这种情况。
这种奇怪行为背后的原因是什么?
编辑:更详细的日志
[06/07/12 10:08:37:192][QuartzScheduler_Worker-34][INFO] org.quartz.plugins.history.LoggingTriggerHistoryPlugin - Trigger [<trigger_name>] fired job [<job_name>] scheduled at: 06-07-2012 10:08:33.458, next scheduled at: 06-07-2012 10:34:53.000
[06/07/12 10:08:37:192][QuartzScheduler_Worker-34][INFO] <my_package>.scheduler.quartz.ScheduledLocateJob - execute begin--------- ScheduledLocateJob with key: <job_name> started at Fri Jul 06 10:08:37 EDT 2012
[06/07/12 10:08:37:192][QuartzScheduler_Worker-34][INFO] <my_package>.scheduler.quartz.ScheduledLocateJob <some log statement>
[06/07/12 10:08:37:192][QuartzScheduler_Worker-34][INFO] <my_package>.scheduler.quartz.ScheduledLocateJob <some log statement>
[06/07/12 10:08:37:192][QuartzScheduler_Worker-34][INFO] <my_package>.scheduler.quartz.ScheduledLocateJob <some log statement>
[06/07/12 10:08:37:220][QuartzScheduler_Worker-34][INFO] <my_package>.scheduler.quartz.ScheduledLocateJob - execute end--------- ScheduledLocateJob with key: <job_name> ended at Fri Jul 06 10:08:37 EDT 2012
[06/07/12 10:08:37:220][QuartzScheduler_Worker-34][INFO] org.quartz.plugins.history.LoggingTriggerHistoryPlugin - Trigger [<trigger_name>] completed firing job [<job_name>] with resulting trigger instruction code: DO NOTHING. Next scheduled at: 06-07-2012 10:34:53.000
我怀疑上述日志的这一部分
scheduled at: 06-07-2012 10:08:33.458, next scheduled at: 06-07-2012 10:34:53.000
因为这份工作安排在10:04:53,但它在10:08:33解雇了,而且石英并没有把它视为失火。难道不是一场失火吗?
答案 0 :(得分:3)
尝试使用以下内容,它应该改善行为
org.quartz.scheduler.batchTriggerAcquisitionMaxCount
org.quartz.jobStore.acquireTriggersWithinLock
org.quartz.scheduler.idleWaitTime