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

Re: 19990510: Any known problems with ldm-5.0.5 and irix 6.5?

On Tue, 15 Jun 1999, Pete Pokrandt wrote:

> In a previous message to me, you wrote: 
> 
>  >Pete,
>  >
>  >I would take some of the options out:
>  >
>  >
>  >-make your queue size 100MB
>  >-reboot the machine.
>  >
> 
> Robb,
> 
> Just an update on my irix 6.5 queue corruption problems.  I had 
> increased my queue size to 180 Mb and things were running along
> just fine, until Friday June 4 (when I left on vacation of course..)
> when the ldm tried to increase the size of the queue. As soon as
> that happened, corrupt queue and crash. 

Pete,

A little more info, the queue isn't actually corrupt even though there are
assertion messages in the logs.  The queue growing conflicts with pqexpire
and it hangs the ldm but usually the queue is OK. We have increase the
time pqexpire runs from 5 to 20 minutes to avoid the conflict. The other
alternative is to make the queue higher then the high water mark, which
you already have done.  Another option is to build from source 
in ./configure modify "#define _NOGROW 1"  

Robb...

 We were down for 2 days
> until I got logged in from my folks house and restarted it.
> 
> Made the queue 200 Mb and that was fine til yesterday, it tried
> upping again and boom. Same deal.  I don't know if this problem
> is specific to something about *that* machine or not. I have
> another SGI that I will put 6.5 on also and play around with it
> a bit, though I will eventually upgrade that one (and possibly 
> this first one too) to 6.5.3 and see if that changes anything.
> 
> To sum up, on my SGI running IRIX 6.5, I currently have my
> queue size set at 250 Mb to handle all UNIDATA feed (DDPLUS,
> HRS,MCIDAS,IDS), WSI 1+3floaters, and NLDN feeds. 250 is
> a bit more than enough, 200 is not.  Any time the ldm attempts
> to increase the size of the queue, it gets corrupted and the
> ldm dies.  It seems that the volume of data coming through 
> NOAAPORT keeps increasing, so this may continue to be a problem
> for a while..
> 
> Pete
> 
> 
> --
> +>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+
> ^ Pete Pokrandt                    V 1515  AOSS Bldg  1225 W Dayton St^
> ^ Systems Programmer               V Madison,         WI     53706    ^
> ^                                  V      address@hidden       ^
> ^ Dept of Atmos & Oceanic Sciences V (608) 262-3086 (W)  222-0919 (H) ^
> ^ University of Wisconsin-Madison  V       262-0166 (Fax)262-3086 (VM)^
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
> 

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