RE: Journal performance problems

Oliver,

Keeping your journal receivers in a separate ASP is standard and
appropriate procedure; I wouldn't move them to your production ASP.

As far as verifying whether your single-drive ASP is the problem, it
sounds like you are doing the right thing by turning on monitoring.  A
drive tends to max out its throughput when it reaches about 40% busy,
after that you need more arms.  If this drive is at or above 40% during
these batch jobs, then you can be reasonably sure that it is performing
at its maximum and that you would benefit from adding another drive.  You
can get a good idea of this from the WRKDSKSTS display if you can take a
five-minute sample while your batch job(s) are running.  

I truly don't think that a larger write-cache will be much benefit for
batch jobs.  If these jobs are pumping out write transactions for an hour
and a half, you will just fill up the cache quickly and then be right
back where you started.  The write cache will do an excellent job of
evening out transient spikes, but won't do much for continuous overload.

Regards,
Andy Nolen-Parkhouse

> oliver.wenzel@xxxxxxxxxxxxxxxxxxxxxxx
> Subject: Journal performance problems
> 
> Hello,
> 
> Any ideas on how to confirm this?
> 
> Also, we could add a disk drive to ASP2, which should help some. Or
> might
> it be better to cancel ASP2 and add the disks to ASP1?
> 
> I've started Management Central performance monitoring to get a better
> look at system activity.
> 
> Any suggestions?
> 
> Regards,
> 
> Oliver