2012-07-06 3 views
4

우리는 분당 약 1000 개의 작업을 실행하는 석영 기반의 스케줄러 애플리케이션을 가지고 있습니다.이 애플리케이션은 매분마다 초 단위로, 즉 초당 약 16-17 개의 작업으로 균등하게 분배됩니다. 이상적으로, 이러한 16-17 작업은 동시에 실행되어야하지만 작업 실행 메서드의 실행 시간을 기록하는 첫 번째 문은 매우 늦게 호출됩니다. 예 : 05:00부터 05:04까지 분당 1000 건의 작업이 있다고 가정 해 봅시다. 따라서 05:03:50에 예정된 작업은 05:03:50에 execute 메소드의 첫 번째 명령문을 기록해야합니다. 그러나 약 05:06:38에 작업을 수행하고 있습니다. 나는 약 15-20 밀리 세컨드에 관해서 예정된 직업에 의해 잡힌 시간을 추적했다. 이 예약 된 작업은 ActiveMQ 큐에서 메시지를 보내기 때문에 충분히 빠릅니다. 우리는 석영의 스레드 수를 100으로 지정했으며 심지어 200 이상으로 늘리려고 시도했지만 아무런 이득도 얻지 못했습니다. 우리가 발견 한 가지 더 스케줄러의 로그가 처음 일분 후 순차적오고 있다는 점이다 즉석영 실 실행 병렬 또는 순차?

그래서 잠시 후 석영 거의 순차적 인 스레드를 실행하는 것을 제안
[Quartz_Worker_28] <Some log statement> 
.. 
.. 
[Quartz_Worker_29] <Some log statement> 
.. 
.. 
[Quartz_Worker_30] <Some log statement> 
.. 
.. 

. 지속성 저장소 (이 경우 별도의 포스트그레스 데이터베이스 임) 및/또는 컨텍스트 전환으로 작업 완료를 알리는 데 소요되는 시간 때문에 이러한 현상이 발생할 수 있습니다.

이 이상한 행동의 원인은 무엇일까요?

편집 : 나는 위의 로그이 작업이 10시 4분 53초 예정 되었기 때문에

scheduled at: 06-07-2012 10:08:33.458, next scheduled at: 06-07-2012 10:34:53.000 

의이 부분에 의심하고 있지만, 10에서 발사 더 자세한 로그

[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 

: 08 : 33 그리고 여전히 석영은 그것을 실화라고 생각하지 않았습니다. 실화가 아니어야합니까?

+1

당신이 당신의 스레드의 스레드 덤프를 게시 할 수 동작을 개선해야합니까? 여기 또는 Gist/pastebin으로 게시하십시오. 또한''LoggingTriggerHistoryPlugin' 사용을 고려하십시오. (http://nurkiewicz.blogspot.no/2012/04/quartz-scheduler-plugins-hidden.html) –

+0

그러나 이미 스케줄러 앱에 의해 덤프되는 로그의 샘플을 언급했습니다 , 우리는 아직 역사 플러그인을 사용하지 않았기 때문에 석영 스레드 덤프가 없습니다. 히스토리 플러그인을 활성화 한 후 덤프를 시도하려고합니다. – vikas

+0

JVM 스레드 덤프 ('jps' 또는'jvisualvm' 같은 도구 사용)를 의미합니다. 플러그인은 그럴 필요가 없습니다. 그동안 Quartz 스레드가 수행하는 작업을보고 싶습니다. –

답변

3

봅니다 다음과 놀,이 프로세스가 실행 중일 때

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

batchTriggerAcquisitionMaxCount를 정확히 같은 시간에 예약 된 작업 수로 설정하면 트릭이 발생했습니다. 우리는 여전히 quartz.properties에서 설정 한 쿼츠 스레드 수와 동일하게 설정하여 최적화하려고합니다. – vikas