RE: Accessing a file in memory

["Raikov, Lo" <RaikovL@xxxxxxxxxx>]

Rob,

I'm afraid I'd have to disagree. Maybe I'm stretching it a bit, but if you
have inherently long-running batch jobs in the system and your overall CPU
utilization is less than 100%, it means you are underutilizing your
equipment! If a batch job does not devour all that's left after all
high-priority jobs are served, it can only have two explanations: either the
job is not designed to efficiently use CPU or there is a bottleneck
somewhere in the system (e.g. the system is thrashing). As I said, I
exaggerated it a bit, but the principle still stands.

Lo

> -----Original Message-----
> From: Rob Berendt [SMTP:rob@dekko.com]
> Sent: Monday, July 24, 2000 11:16 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: Accessing a file in memory
> 
> You're right.  Basing a purchasing decision on a one time peak is probably
> 
> not good.  But, to come up with reasons why constantly running at 70-90%
> is 
> acceptable when you should be upgrading is not good either.
> 
> 
> 
> 
> 
> RaikovL@mki.com.au on 07/20/2000 08:38:48 PM
> Please respond to MIDRANGE-L@midrange.com@Internet
> To:   MIDRANGE-L@midrange.com@Internet
> cc:    
> Fax to:       
> Subject:      RE: Accessing a file in memory
> 
> No if he has extra $ to spend. The trouble is a decision like that is very
> often taken just on the basis of the peak CPU utilisation. 
> 
> Lo
> 
> > -----Original Message-----
> > From:       Rob Berendt [SMTP:rob@dekko.com]
> > Sent:       Friday, July 21, 2000 1:17 AM
> > To: MIDRANGE-L@midrange.com
> > Subject:    RE: Accessing a file in memory
> > 
> > <SNIP>
> > There is nothing wrong with 90% CPU utilization as such. It only becomes
> a
> > problem when app.. 70% is used by response-time critical jobs. 
> > <ENDSNIP>
> > 
> > There's also nothing wrong with a boss which upon noticing a system
> > hitting 
> > 40% of CPU, and planning for future growth, doubles the number of
> > processors 
> > and adds a ton of memory.
> > 
> +---
> | 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
> +---
> 
> 
> +---
> | 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
> +---
+---
| 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
+---