This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Gilbert, > While it's not pegging my CPU at 99% anymore, it's still pretty high on my > machine running Fedora 8: > > top - 12:28:28 up 3 days, 2:34, 3 users, load average: 2.21, 1.85, 1.29 > > Tasks: 240 total, 1 running, 239 sleeping, 0 stopped, 0 zombie > Cpu0 : 13.2%us, 5.6%sy, 0.0%ni, 77.5%id, 3.6%wa, 0.0%hi, 0.0%si, > 0.0%st > Cpu1 : 1.6%us, 5.6%sy, 0.0%ni, 92.5%id, 0.0%wa, 0.0%hi, 0.3%si, > 0.0%st > Cpu2 : 18.9%us, 5.6%sy, 0.0%ni, 73.8%id, 1.7%wa, 0.0%hi, 0.0%si, > 0.0%st > Cpu3 : 16.4%us, 5.6%sy, 0.0%ni, 77.4%id, 0.7%wa, 0.0%hi, 0.0%si, > 0.0%st > Mem: 3368604k total, 3243140k used, 125464k free, 74872k buffers > Swap: 2031608k total, 18484k used, 2013124k free, 2672508k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 4396 ldm 20 0 50548 7752 832 S 30 0.2 1:08.31 dcgrib2 > > ---- > Just thought you'd want to know in case it's not as good as you want it > to be. It is what it is. The dcgrib2(1) program uses a lot of resources. The changes I made just stop it from being interrupted by SIGCONTs from the LDM process group: it's still going to use a lot of resources. > Take care! You too. Thanks for reporting on this. Regards, Steve Emmerson Ticket Details =================== Ticket ID: DSW-144649 Department: Support LDM Priority: Normal Status: Closed