We run a big bill posting batch process every night.
The main determining factor for how long this job runs is the number of bills being posted.
Friday night this job posted around 35,000 bills and ran in 3.6 hours.
Last night’s job posted around 35,000 bills and ran in 5.1 hours.
This time of night, nothing else of any significances is running but this one posting job.
As I dig into the performance data for these jobs, the main difference that pops out is that the job running 5.1 hours had a significant higher number of JOURNAL WAITS… This application does use commitment control and therefore a lot of application journaling is occurring, so I expect waits. I didn’t expect to see such a big increase though.
In fact when I ran a journal analysis for this job, the amount of journal updates and deletes for the 2 main files in the process were very close to the same for both jobs… 6,300,000 updates and 1,400,000 deletes.
Note: We do have the Batch Journal Caching feature installed and turned on.
Journal . . . . . . : OCCISJRN Library . . . . . . : P1FILES
Attached receiver . : CIS1JR2026 Library . . . . . . : JRNRCVCIS
Text . . . . . . . . : Production CIS Journal
ASP . . . . . . . . : IASP1 Journaled objects:
Message queue . . . : CISJRNMSGQ Current . . . . . : 23220
Library . . . . . : QGPL Maximum . . . . . : 250000
Manage receivers . . : *SYSTEM Recovery count . . . : *SYSDFT
Delete receivers . . : *NO Receiver size options: *MAXOPT3
Journal cache . . . : *YES Fixed length data . : *JOB
Manage delay . . . . : 10 *USR
Delete delay . . . . : 10 *PGM
Journal type . . . . : *LOCAL
Journal state . . . : *ACTIVE
Minimize entry data : *NONE
That’s about as far as I’ve got… I can’t seem to find any reason for such a large increase in “Journal Wait Time” for this job…
Any ideas as to what might be going on would be greatly appreciated!
AKA … 肯尼思 or 케네스
Kenneth E. Graap