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.
Jeff, > -bash-3.2$ ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 147456 > max locked memory (kbytes, -l) 32 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 10240 > cpu time (seconds, -t) unlimited > max user processes (-u) 147456 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited The data segment size, maximum memory size, and virtual memory size are all unlimited, so the O/S isn't preventing you from obtaining as much memory as you can, so the 4 GB mmap(2) system-call should have worked. Odd. I've attached a C file that, if compiled into a program, will tell you how much memory can be allocated. You might try it. > this server is a dead end, that is, all I do is file the radar data for http > retreival via desktop software > so holding a huge queue for downstream hosts is not needed as there are no > ALLOW's for downstream supply .. Because the server is a "dead end", you should ensure that the "/reconciliation-mode" parameter is set to "decrease maximum latency" (e.g., "regutil -s 'decrease maximum latency' /reconciliation-mode"). > -Jeff Regards, Steve Emmerson Ticket Details =================== Ticket ID: DNN-647229 Department: Support LDM Priority: Normal Status: Closed