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

Re: 19990601: Linux LDM memory problem (fwd)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 19990601: Linux LDM memory problem (fwd)
  • Date: Tue, 1 Jun 1999 16:12:54 -0600 (MDT)
David,

How about trying not to use a memmapped queue file. Set the environment
variable NO_MMMAP = 1 .  One would have to do a make distclean and rerun
configure.  It might be better or worst, It would be interested to find
out.  Keep me informed.

Robb...



On Tue, 1 Jun 1999, Unidata Support wrote:

> 
> ------- Forwarded Message
> 
> >To: address@hidden
> >From: David Wojtowicz <address@hidden>
> >Subject: Linux LDM memory problem (fwd)
> >Organization: .
> >Keywords: 199906012023.OAA18453
> 
> 
> 
> FYI: Looks like I'm not the only one with the Linux/LDM memory
> problem...
> 
> 
> ---------- Forwarded message ----------
> Date: Wed, 26 May 1999 16:05:58 -0400 (EDT)
> From: Mark Tucker <address@hidden>
> To: address@hidden
> Subject: Linux LDM memory problem
> 
> 
> David,
> Hi, I work for the Meteorology Dept. at Lyndon State College.  I ran
> across your e-mail in the support archives on Unidata's site.  We are also
> running our ldm on Linux (kernel 2.0.36).  Having only worked with the ldm
> on Linux I assumed that the behavior I was seeing was normal for the ldm.
> I just thought I'd pass along my experiences where they were similar to
> yours.  Unfortunately, I don't have any real solutions for you but maybe
> something here will be useful.
>     We run with a queue of about 400MB for our ldm for quite a while.  
> Stopping the ldm definitely takes some time and disk writing for
> everything to exit completely. This generally takes several minutes for
> every thing to settle down.  Our server is a bit overkill (PII-400, 512MB
> RAM, Ultra2-Wide SCSI disks) and I think this is probably the only thing
> that keeps shutdown times for the ldm from taking half an hour.
> Running "ldmadmin restart" has never worked correctly as far as I can
> remember because of this (at least, that has been my assumption).
>    Because our server has ample memory there is enough room for
> the file cache and buffer to co-exist with the other processes.  I think
> thisis the main reason that we have not seen some of the delays in working
> interactively on the ldm server that you mentioned.  The 2.2 series of
> Linux kernels are supposed to be more aggressive about caching disk
> activity so I suspect that this problem will be made worse, not better, as
> those of us running linux upgrade our systems.   
> 
> Mark Tucker
> Information Technology
> Lyndon State College
> address@hidden
> 
> 
> 
> 
> 
> ------- End of Forwarded Message
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================