石英線程執行並行還是順序？

我們有一個基於石英的調度程序應用程序，它每分鐘運行大約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

石英線程執行並行還是順序？

回答

相關問題