|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.