问题描述
我们有一个基于石英的调度程序应用程序，每分钟运行大约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分钟后会连续发生，即
We have a quartz based scheduler application which runs about 1000 jobs per minute which are evenly distributed across seconds of each minute i.e. about 16-17 jobs per second. Ideally, these 16-17 jobs should fire at same time, however our first statement, which simply logs the time of execution, of execute method of the job is being called very late. e.g.let us assume we have 1000 jobs scheduled per minute from 05:00 to 05:04. So, ideally the job which is scheduled at 05:03:50 should have logged the first statement of the execute method at 05:03:50, however, it is doing it at about 05:06:38. I have tracked down the time taken by the scheduled job which comes around 15-20 milliseconds. This scheduled job is fast enough because we just send a message on an ActiveMQ queue.We have specified the number of threads of quartz to be 100 and even tried with increasing it to 200 and more, but no gain. One more thing we noticed is that logs from scheduler are coming sequential after first 1 minute i.e.
[Quartz_Worker_28] <Some log statement>
..
..
[Quartz_Worker_29] <Some log statement>
..
..
[Quartz_Worker_30] <Some log statement>
..
..
所以它表明经过一段时间石英是运行线程几乎顺序。可能是这种情况正在发生，因为通知作业完成持久性存储（在这种情况下是一个单独的postgres数据库）和/或上下文切换。
So it suggesting that after some time quartz is running threads almost sequential. May be this is happening due to the time taken in notifying the job completion to persistence store (which is a separate postgres database in this case) and/or context switching.
这种奇怪行为背后的原因是什么？
What can be the reason behind this strange behavior?
编辑：更详细日志
[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仍然石英不认为它是失火。难道不应该是失火吗？
because this job was scheduled for 10:04:53, but it fired at 10:08:33 and still quartz didn't consider it as misfire. Shouldn't it be a misfire?
推荐答案
尝试使用以下内容，它应该改善行为
Try to play with the followings, it should improve the behavior
org.quartz.scheduler.batchTriggerAcquisitionMaxCount
org.quartz.jobStore.acquireTriggersWithinLock
org.quartz.scheduler.idleWaitTime
这篇关于Quartz Thread Execution并行还是顺序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！