石英线程执行并行还是顺序？

我们有一个基于石英的调度程序应用程序，它每分钟运行大约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仍然石英不认为它是失火。它不应该是一场失火吗？

来源

2012-07-06 vikas

可以在此过程中运行您发布线程的线程转储？张贴在这里或作为Gist/pastebin。另外考虑使用['LoggingTriggerHistoryPlugin']（http://nurkiewicz.blogspot.no/2012/04/quartz-scheduler-plugins-hidden.html） – 2012-07-06 12:15:31

我已经说过我们的调度程序应用程序转储的日志样本，但是，我没有石英线程转储，因为我们还没有使用任何历史插件。我会尝试启用历史记录插件后获得转储。 – vikas 2012-07-06 12:53:18

我的意思是一个JVM线程转储（使用像'jps'或'jvisualvm'这样的工具），插件不是必需的。我想看看在此期间Quartz线程在做什么。 – 2012-07-06 13:08:21

尝试用以下的发挥，应该改善的行为

org.quartz.scheduler.batchTriggerAcquisitionMaxCount 
org.quartz.jobStore.acquireTriggersWithinLock 
org.quartz.scheduler.idleWaitTime

来源

2012-07-08 03:46:40 SudhirJ

将batchTriggerAcquisitionMaxCount设置为准确同时计划的作业数。我们仍然试图通过将其设置为等于我们在quartz.properties中设置的石英线数来优化它。 – vikas 2012-07-08 11:59:27

石英线程执行并行还是顺序？

回答

相关问题