Re: 20020917: CPU & Memory vs. Performance (LDM)

Hi Bunny, 

Multiple LDM's on the same machine is not advisable, I do not think it is
even possible..at least without major disc re-partitioning..They will step
on each other..

Thanks and good luck!

-Jeff
____________________________                  _____________________
Jeff Weber                                    address@hidden
Unidata Support                               PH:303-497-8676 
COMET Case Study Library                      FX:303-497-8690
University Corp for Atmospheric Research      3300 Mitchell Ln
http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000
________________________________________      ______________________

On Tue, 17 Sep 2002, Bunny Pfau wrote:

> 
> WAIT!!! Of course I thought of something else
> regarding performance as soon as I sent that last
> email:
> 
> Can you improve performance by setting up
> multiple LDM servers ON THE SAME COMPUTER
>   OR multiple downstream clients ON THE SAME COMPUTER?
> Or is the way I"m doing it--three downstream clients, each
> on their own computer---probably the way to go.
> (I don't have any super computers I"m workin'; with here...
> just computers in the range of 100-400MHz CPU and anywhere
> from 128 to 512MB of RAM at this time).
> ANd this is my last question-- I swear!!
> :-)
> Bunny
> 
> At 04:25 PM 9/17/2002 -0600, you wrote:
> >Hi Bunny,
> >
> >CPU resources can come into play if you are a relay site and are relaying
> >data feeds that generate many rpc calls. That increases overhead, that can
> >be helped by a faster CPU, and we experience this primarily with the
> >NNEXRAD and IDS|DDPLUS feeds...(many prods/hour).
> >
> >Other than bandwidth we have hit on most resources needed to run the LDM
> >efficiently.. :)
> >
> >Let me know if I can be of any other assistance.
> >
> >Cheers,
> >
> >-Jeff
> >____________________________                  _____________________
> >Jeff Weber                                    address@hidden
> >Unidata Support                               PH:303-497-8676
> >COMET Case Study Library                      FX:303-497-8690
> >University Corp for Atmospheric Research      3300 Mitchell Ln
> >http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000
> >________________________________________      ______________________
> >
> >On Tue, 17 Sep 2002, Bunny Pfau wrote:
> >
> > > Jeff--thanks for the confirmation of needing additional
> > > memory needs.  Actually, I hadn't seen in the archives
> > > about splitting the feeds--I tried it out on my own, in
> > > my own, blind fumblings.  THanks for verifying it, though.
> > >
> > > If you know of any other tricks that would/could inprove
> > > transfer rates--please point me in that direction.
> > > Seems CPU power really doesn't have much to do with it.
> > >
> > > Bunny Pfau
> > > -> Date: Tue, 17 Sep 2002 15:59:54 -0600 (MDT)
> > > -> From: Jeff Weber <address@hidden>
> > > -> To: Bunny Pfau <address@hidden>
> > > -> Cc: ldm-support <address@hidden>
> > > -> Subject: Re: 20020917: CPU & Memory vs. Performance (LDM)
> > > ->
> > > -> Hi Bunny,
> > > ->
> > > -> The optimal amount of memory is slightly larger than your queue.
> > > ->
> > > -> The LDM will run "best" if the entire queue can reside in memory.
> > > ->
> > > -> For example we have a 7GB queue on our feed machine and 8GB of memory.
> > > ->
> > > -> Nice work splitting your feeds, as I am sure you noticed in the 
> > archives,
> > > -> that can increase performance by decreasing latencies.
> > > ->
> > > -> Hope this helps!
> > > ->
> > > -> Cheers,
> > > ->
> > > -> -Jeff
> > > -> ____________________________                  _____________________
> > > -> Jeff Weber                                    address@hidden
> > > -> Unidata Support                               PH:303-497-8676
> > > -> COMET Case Study Library                      FX:303-497-8690
> > > -> University Corp for Atmospheric Research      3300 Mitchell Ln
> > > -> http://www.unidata.ucar.edu/staff/jweber      Boulder,Co 80307-3000
> > > -> ________________________________________      ______________________
> > > ->
> > > -> On Tue, 17 Sep 2002, Unidata Support wrote:
> > > ->
> > > -> >
> > > -> > ------- Forwarded Message
> > > -> >
> > > -> > >To: address@hidden
> > > -> > >From: Bunny Pfau <address@hidden>
> > > -> > >Subject: CPU & Memory vs. Performance (LDM)
> > > -> > >Organization: UCAR/Unidata
> > > -> > >Keywords: 200209171959.g8HJxk112107
> > > -> >
> > > -> >
> > > -> > Is there a document (I've been searching the UNIDATA web site)
> > > -> > that deals with suggested CPU, memory amount to help LDM
> > > -> > run at its most efficient level?
> > > -> >
> > > -> > I have an upstream server serving our own in-house data to
> > > -> > a couple of downstream servers---I mainttain them all.
> > > -> > I'm in the process of trying to squeeze out every last
> > > -> > ounce of speed I can.
> > > -> >
> > > -> > I'm on the Solaris 7 platform, on Sun SPARC hardware.
> > > -> >
> > > -> > I increased my setup so that I have THREE downstream clients
> > > -> > running ldmd and saw that I could increase the data transfer
> > > -> > rate by doing that..
> > > -> >
> > > -> > I've also read through the email archives, noting in some
> > > -> > emails that memory is VERY important.
> > > -> >
> > > -> > Say I have my main, upstream server with a 600MB queue,
> > > -> > at any time finding it to have 400-600MB of data on it..
> > > -> > What would be the recommended ratio of memory to queue size
> > > -> > for a Solaris 7 server (currently it has a measley 128MB of
> > > -> > RAM on it and with three downstream clients requesting data,
> > > -> > I can get up to an 8.2MB/minute transfer rate).
> > > -> >
> > > -> > Any help or referring me to the place in documentation which
> > > -> > might be helpful would be great.
> > > -> >
> > > -> > Thanks,
> > > -> > Bunny
> > > -> >
> > > -> > ---
> > > -> >
> > > -> > Bunny Pfau                      National Center for Atmospheric 
> > Research
> > > -> > address@hidden                  High Altitude Observatory
> > > -> > tel: 303 497-1555               P.O. Box 3000
> > > -> > fax: 303 497-1589               Boulder, CO  80307-3000
> > > -> >
> > > -> >
> > > -> >
> > > -> >
> > > -> >
> > > -> >
> > > -> > ------- End of Forwarded Message
> > > -> >
> > > -> >
> > >
> > >
> 
>