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
