[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT - I/O and CPU load



Brian Stults wrote:
> 
> Hello,
> 
> I'm sorry that this is off-topic, but I think many people here would be
> able to answer this question easily.  The unix system in my research
> center has a file server with 4 CPUs.  I don't know all the specifics of
> the machine, but my question is rather general anyway.  Basically, the
> file server is the fastest of all the Sun stations by far, so everyone
> logs into it to run their jobs.  Some of these jobs last for several
> days and are very processor intensive.  It "feels" to me like my I/O
> intensive jobs slow down when these processor-intensive jobs are
> running.  However, our sysadmin insists that cpu-intensive jobs will
> have no effect on I/O intensive jobs.  Is this generally true?
> 
> Thanks very much for any information you can give me.  I would like to
> make the case that the file server should be just a file server and that
> all these week-long jobs should be run somewhere else, but I just don't
> know if that is a valid argument.
> 
> Thanks,
> Brian
> --
> 
> Brian J. Stults
> Doctoral Candidate
> Department of Sociology
> University at Albany - SUNY
> Phone: (518) 442-4652  Fax: (518) 442-4936
> Web: http://www.albany.edu/~bs7452

I think your sysadmin has it exactly the wrong way round - your IO jobs
will have little effect on CPU jobs but CPU jobs will have a significant
impact on your IO jobs.  However, a lot will depend upon the job
priorities and the way the job/process scheduler allocates time on a
cpu.

Without going into scheduling theory (and not knowing anything about
this particular system's scheduler anyway) what you want to try is to
get the IO jobs to run at a higher priority than the CPU jobs.

The IO jobs will spend most of the 'real' time waiting for IO, not
needing cpu, and that's when the CPU jobs get their turn on the cpus -
the IO jobs won't be eligible for cpu time if they're still waiting on
IO.

When an IO job finishes its IO and eventually does need more cpu time,
it will be scheduled ahead of waiting cpu jobs for a slot on a cpu
because of its higher priority.  It will do a bit of cpu and then start
waiting for IO again, probably without using it's full allotted time on
the cpu.

If the CPU jobs are run at a higher priority than the IO jobs, each CPU
job will use all of it's allotted time on the cpu, before being chucked
off for another CPU job to get it's time, and the IO jobs won't get a
look-in.

If IO and CPU jobs are scheduled at the same priority you will find that
ecah CPU job will use it's full time-slot but each IO job probably wont,
so here again, the CPU jobs will hold up the IO jobs for longer than the
IO jobs will hold up the CPU jobs.

This is, of course, assuming that IO itself doesn't require lots of
cpu;)

As your jobs don't need lots of cpu, why don't you run them on the
feeblest system there - the one that everyone else avoids "because it's
too slow"?  It should make less difference to you and would probably be
faster in the end - let all the CPU people fight for cycles amongst
themselves.

LeeE
-- 

http://www.spatial.freeserve.co.uk

...or something




Reply to: