found something out that was confirmed by Gilbert..thanks Gilbert
according to the ldmadmim-pl.config we can specify
K or M or G for the queue size
" Understood suffixes include "K", "M", and "G" for
# "kilo", "mega", and "giga", respectively. The default requested size
# is 500 megabytes (i.e., "500M")."
so for my radar (NEXRAD3 & NEXRAD2) storage/redistribution servers
I felt safe with a 3 GB queue for each (12GB ram on servers)
so I put 3G in the field ..
low and behold when ANY type of wide area returns are on radar
all my products became at a minimum of 10 to a max of 45 minutes late
so I took my problem to Gilbert, he suggested I entered the Byte equivalent
of 3 GB.. so that's what I did and after catching me up,
my products are right on time and have been..
So this leads us to believe 'G' is not understood by ldmadmin.pl ...
also..
is it just me or when scour is running do others see your loads and memory
usage go through to roof??
the loads every once and a while would hit 1.5 with maybe 7-7.5 Gb ram used
during normal usage
when scour ran loads would bounce from 4 to 6 and max out all 12Gb of ram
so I wrote a simple bash script to do essentially the same thing.
The loads and memory usage barely move with it running
after switching to my NEXRAD2 directory
these are run
find K*/K* -type f -mmin +120 -exec rm {} \;
find P*/P* -type f -mmin +120 -exec rm {} \;
find N*/N* -type f -mmin +120 -exec rm {} \;
find T*/T* -type f -mmin +120 -exec rm {} \;
find R*/R* -type f -mmin +120 -exec rm {} \;
I do it this way as each radar directory has a php file,
and yes my scour is altered to delete by minutes old..
scour handles NEXRAD3 with no problem, but
kills me when doing NEXRAD2..
ideas??
Jeff Lake K8JSL
http://www.MichiganWxSystem.com
https://www.TheWeatherCenter.net
