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.
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.
On Wed, 2007-08-29 at 10:00 -0500, Robert Mullenax wrote: > So can it be assumed that the sample pqact.confs in the GEMPAK > distributions are similar to what Unidata uses and suggests? > > Thanks, > Robert > > Robert, I provide the GEMPAK pqact files as separate templates for several reasons, and they are actions I run with here. The primary reasons are: 1) It is generally easier to install updated config files by swapping out the new file I provide rather than trying to edit the changes into a longer combined file, especially if you have multiple packages or local entries that you would otherwise have to pick through. 2) The pqact processes take time to process each product, and can fall behind waiting for a decoder that is heavily loaded, or for disk I/O. Issuing "kill -USR2" to cycle pqact into verbose, then again to debug mode will provide information on how long it took pqact to process a product once it got into the queue in a log message that state the "Delay". Don't run pqact in debug mode for long since logging that much info will introduce its own load (cycle back to silent with another "kill -USR2"). If the "Delay" reaches the time of the oldest product in the queue, the current LDM release will issue a log message about "processing oldest product in queue". In this event, incoming data would be pushing out the oldest data to make room, and so data may not get processed before it gets scoured out. Dividing the processing up to multiple pqact processes can help, unless the system IO just can't handle the load. 3) The original split to 4 pqact processes for the level2 radar data was based on each pqact process only having 32 streams, so dividing the load allowed FILE and PIPE streams to stay open so that pqact didn't have to spend so much time reaping the least recently used stream for a new stations/times. This number has been raised now to system limits which on many systems exceeds 1000 streams (some 16000 streams) so reaping isn't as much an issue now, but disk IO can high for sites receiving all level2 data, so there can still be benefits to splitting the load on systems. Note however that the new method of LDM using a .state file for pqact has side affects if you are using the same pqact.conf for more than one pqact process (using different "-p" patterns to split the level2 stations for instance). Since the state files should be unique per pqact process, creating a symbolic link from the conf file to unique names should be done so that unique pqact.*.state files will be created. 4) Allow sites to set up a test of new decoders, tables, output directories etc while continuing to keep current configurations for users depending on current configurations. 5) Make it easier for me to pack up a new distribution with pattern/actions If you have specific questions about the GEMPAK pattern files, let me know! Steve Chiswell Unidata User SUpport -- Steve Chiswell <chiz@xxxxxxxxxxxxxxxx> Unidata
ldm-users archives: