Re: Journaling and contention

Jim

Bit of a guess here... and I know you kinda indicated that the ASP option 
is a big job but...

Given that you have recently split this into multiple jobs, is it possible 
that your job is now "outrunning" the speed at which journal entries can be 
written to disk ?  What does the WRKDSKSTS display show in terms of % busy 
on disk arms when you get the problems ? Can you find out using performance 
tools ?

One tip that I recently got from News/400 (reading back-issues during an MQ 
install :)) was that journals should be in their own ASP (as you alluded 
to) and preferably the disks should be mirrored rather than protected by 
raid as this minimises the travel required for the disk arms to complete 
the write (they do a write to the mirrored disks rather than to a couple of 
disks in the raid set including a write for the parity bit) (yeah that's a 
simplified version I know). This also had something to do with writes 
normally being done to the "inside" of the disk and parity bits being 
written on the "outside" of the disk (it is possible i have that back to 
front). If there is only one journal (and I guess in your situation maybe 
you should only have only this one file in that journal) then the heads 
basically don't need to move much to write to disk.

In short, for maximum performance, have only one journal, in a dedicated 
ASP, with the disks assigned to that ASP mirrored instead of set for RAID.

PS. If I remember correctly the article was by Rick Turner - I can try and 
hunt it down if you want some more details.

Food for thought anyway

Cheers
Evan Harris

<SNIP>

>We're having difficulty with object contention on very active journals and
>receivers.  We have an RPGLE history program writing hundreds of thousands
>of records to a history file under commitment control.  The journals are set
>up strictly for commitment control.  The file is journaled to a journal with
>journal receivers managed by and deleted by the system.  Originally a single
>job stream generated all the history.  We recently split the job out into
>multiple concurrent streams, each writing records to the file at the same
>time.

<SNIP>

>I'm wondering if anyone has had similar problems with journaling on very
>busy databases.  Before I try reducing (or adding) the number of records to
>a COMMIT I'd like to see if anyone has a strong feel for whether it would
>help.  Also, our journals are not in their own ASP.  Splitting them out is a
>big job.  I've heard conflicting stories as to the benefits.  The strategy
>is supposed to reduce contention between the data and the
>journals/receivers.  It seems to me that my problem is contention among the
>journals and receivers themselves.

<SNIP>


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---