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.
> > I had turned off the LDM and the files were not being purged. > The LDM is independent from AWIPS purging, since release 16.2.2 both /awips2/data_store (which is written by the LMD) and /awips2/edex/data/hdf5 are purged by EDEX itself every hour. > I have a 1 TB SSD drive. It appears there were two main culprits: grid > (460G) and radar (395G). > 395G for radar is about right for the default retention of 7 days defined in /awips2/edex/data/utility/common_static/base/purge/radarPurgeRules.xml - simply change the value defined there and the next purge kickoff will reread the file (no need to restart EDEX when editing purge rules). 460G is large for /awips2/edex/data/hdf5/grid/, on edex-cloud with about 40 different grids ingesting I store less than 300G. You should take a look at /awips2/edex/data/utility/common_static/base/purge/gridPurgeRules.xml and see about trimming some of the retention periods or "versionsToKeep" for grids you don't use. You can also turn these grids off in pqact.conf followed by an "ldmadmin pqactHUP". > Searching the log files it appears all of the feed types were exceeding > their failure limit. > When disk capacity reaches 100% and EDEX/LDM are running, EDEX purge turns itself off (really) which obviously does not solve the problem instead it makes it worse. I need to adjust the default feeds, pattern actions, and purge rules again to ensure that a 1TB disk does not fill up.
awips2-users archives: