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.
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/ ===============================================================================