NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
-----Original Message-----
From: Arthur A. Person Sent: 5/10/2005 11:52 AM On Mon, 9 May 2005, Robert Mullenax wrote:Gabe, Either one of your scripts isn't running gpend (look into running the _gf versions), or you have run into another issue (sorry Art, but it's true)Hmmm, not sure what you mean here, could you elaborate?
Just joking with you..another Linux issue :))
where gf or gplt will hang if you have too many GEMPAK processes running sequentially in a GEMPAK script, even if you are running gpend or using the _gf versions.Our whole ewall (web map wall) runs primarily on gempak scripts, many of which run simultaneously. By-and-large, we see very few problems doing this. However, we do run cleanup scripts twice daily that kill-off hung gplts, etc... We also increased our ipc queue limits to 72 since many gempak processes can chew these up pretty fast.
We had to resort to cleanup scripts as well. This is something I don't have to do on Solaris with the same load.
Maybe ours aren't long enough to hit this problem you're seeing... how long do yours get before they start having trouble?
It has been a while, but I believe if we had more than 18 consecutive iterations of say, gdplot2, then we would see issues under Linux (RH7.2, RH9, and Debian (2.4.20) kernel). I also briefly tested under RH Enterprise WS 3.0 and saw the same thing. I could copy the same script over to a Solaris SPARC box (too slow for operational use) and a Solaris x86 box (dedicated to LDM at that time) and it would run without problems using the same GEMPAK version. The cleanup scripts that we both had to resort to under Linux may beGabe's best bet.
Robert
gembud
archives: