[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #DNN-647229]: Ugly 32bit CentOS bug

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