Chris Goodey wrote:
>
> While any remarks I make on such general information is of course,
> only of general use, I will point out that to get 100% utilitization
> on 4 processors requires at LEAST 4 cpu bound processes.
>
> If you are running two heavy batch jobs, each could almost take up one
> full processor, and that would give you 50% utilization. In many cases,
> a single faster processor will do better than several slower ones even if
> they have more total cpu power.
>
> I have had to break up batch jobs into smaller pieces so that multiple cpu
> horsepower
> could be more effectively used. Sometimes this is just not possible, when
> one job
> is dependent on another running first. Other times reports can be overlapped

Sounds like you need Maestro. We have Maestro on *one* HP and it
schedules jobs on a hundred other HP3000s. You can make a schedule
dependent on another job or schedule, add the --onejob-- parm so it runs
alone, and so on and so forth. Really powerful. When a job in a schedule
aborts, the schedule enters the STUCK state until you fix the busted job
and restream it.


> and in
> general things rescheduled to better exploit parallelism.
>
> Now if you are already running dozens of jobs, have plenty of memory, then
> perhaps
> the problem is I/O. Are you running a single RAID system? If so, that is
> likely to
> be a problem. Many people think that a RAID system is faster than the old
> fashioned
> disc systems, but this is often not true. You are paying a penalty for the
> fault tolerence.
> I think mirrored discs on numerous controllers is a better way to go for
> many systems.
> If you have the money, and can add some more controllers and some mirrored
> drives,
> you will certainly increase you I/O capacity.
>
> Assuming you have Glance, what does it tell you? If you see many processes
> waiting for
> I/O, then that tells you something. If you only see a few processes running
> then you may not have a workload that can exploit the 4 processors. On our
> single 989/100
> system a single Suprtool job can take most of a discs I/O when it is doing
> sequential reads.
> If it is a regular Cobol job, the less efficient I/O makes it use more cpu,
> and it typically
> can't use the data quite as fast is the disc system can supply it.
>
> > -----Original Message-----
> > From: Ron Wallace [mailto:[log in to unmask]]
> > Sent: Friday, April 07, 2000 9:19 AM
> > To: [log in to unmask]
> > Subject: Disc I/O on a 989/400
> >
> >
> > We just moved our AMISYS application from a 987/200 to a
> > 989/400.  We seem to be experiencing a lot of I/O constraint.
> >  We have not been able to get the CPU utilization above 50%,
> > on a good day, usually 35%.  We have a Nike(Not sure of
> > spelling) 20 box with a variety of disc drives(4, 16 and 20
> > gig) drives.
> >
> > I do not think we have been able to utilize 2 of the 4
> > processors on this box.  I have tried spreading files across
> > the drives and condensing.
> >
> > I have a lot of through put that I can not seem to use.
> >
> > Has anybody found any solution to this?
> >
> > Ron Wallace
> > Contractor
> >