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

Re: 19990510: ldm-5.0.8 for linux and pqact probs



On Mon, 10 May 1999, Unidata Support wrote:

> 
> ------- Forwarded Message
> 
> >To: address@hidden
> >From: address@hidden (Pete Pokrandt)
> >Subject: ldm-5.0.8 for linux and pqact probs
> >Organization: .
> >Keywords: 199905102048.OAA13847
> 
> 
> Hi again,
> 
> I've had some trouble recently with the ldm on our redhat linux 5.1
> machine, in that the pqsurf program will sometimes stop creating
> GDBM files, though it looks like it is still running, and the raw
> (text) files are still created by it just fine.
> 
> Another curiosity is that under linux, things get very very slow
> if the size of the queue file aproaches that of the amount of memory
> in the machine.
> 
> Profhorn has 256 Mb of memory, and it is our primary ingest machine
> for the NMC2 and SPARE feeds. I currently have the queue file set
> to 180 Mb, but this is not large enough for those feeds apparently,
> since I regularly get these types of messages in the log file:
> 
>    nora-f[29150]: Deleting oldest to make space 19480 bytes
> 
> I used to have the queue file bigger, but doing so caused the machine
> to swap very badly, and other processes (map generation, etc) on that
> machine slowed to an unacceptable level.
> 
> I remember seeing some discussion on the ldm-users list that this
> was not a problem for many OS's, but it definitely is under linux.
> At least under my version of linux, perhaps the 2.2 kernel would
> improve the performance?
> 
Pete,

Our WSI machine has an ldm queue at least 3x the size of the physical
memory and it runs fine.  The difference is that it's running Solaris x86,
I know it's not RH(linux) but it works.  All the linux boxes I know about
have large amounts of physical memory, so I don't have any cases to
report about.   

I sent a seperate message about pqact problems.

Robb...

> Anyways, I figured I'd upgrade to the current version for linux (5.0.8)
> to see if that solved the problem.
> 
> Although the ldm compiled just fine from source, when I try to run it
> using the same pqact file that works with 5.0.5, I get:
> 
> May 10 20:12:32 ProfHorn pqact[970]: Starting Up 
> May 10 20:12:33 ProfHorn pqexpire[968]: Starting Up 
> May 10 20:12:33 ProfHorn pqsurf[971]: Starting Up (967) 
> May 10 20:12:34 ProfHorn pqact[984]: Starting Up 
> May 10 20:12:35 ProfHorn pqact[970]: damaged match string 
> May 10 20:12:37 ProfHorn last message repeated 95 times
> May 10 20:12:37 ProfHorn pqact[984]: damaged match string 
> May 10 20:12:37 ProfHorn pqact[970]: damaged match string 
> May 10 20:12:37 ProfHorn last message repeated 17 times
> May 10 20:12:37 ProfHorn pqact[984]: damaged match string 
> May 10 20:12:39 ProfHorn last message repeated 4 times
> May 10 20:12:37 ProfHorn pqact[970]: damaged match string 
> May 10 20:12:37 ProfHorn pqact[970]: damaged match string 
> May 10 20:12:42 ProfHorn pqact[984]: damaged match string 
> 
> 
> While looking through the source code for pqact (specifically
> that of palt.c) I see that the code for the regexp parsing has
> changed. Is this maybe a bug?
> 
> As I said, the same pqact file works fine with ldm 5.0.5, and
> 
> pqact -vxl- -q /dev/null pqact.conf
> 
> with the 5.0.8 version of pqact shows no errors.
> 
> I can set you up with a copy of my pqact.conf file if you'd like
> to check it out, let me know.
> 
> For now, I'm going back to 5.0.5, just wanted to let you know if
> the regexp stuff was a legitimate bug, and also about the strange
> behavior of pqsurf and the large queue files.
> 
> Thanks,
> 
> 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)^
> +<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+
> 
> 
> ------- 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/
===============================================================================