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

[LDM #VVA-689466]: LDM eats 24GB of RAM in less than a day :: Memory Leak?



Phil,

> We recently installed LDM v. 6.9.8 on a new box running RHEL 6.  I noticed
> this afternoon when, after about 4 days of running non-stop, the LDM had
> consumed our entire 24GB of RAM (save about 40 MB)!  Is this expected
> behavior? Our old machine only had 1 GB of RAM, so I never thought much
> of it, but now I think I may have something configured incorrectly.

I think you encountered a "feature" of the Linux kernel: it will use as much 
physical memory as possible to make things faster (mostly for system buffers 
and cached pages).

> I also noticed that when I stopped the LDM, very little of the memory
> was actually released.  After rebooting the machine (without starting
> the LDM), we were using about 1GB of RAM and this remained stable.
> Since I restarted the LDM at around 4PM this afternoon (and this is
> the only user-level process running on this box outside of root), the
> physical RAM usage has slowly but steadily increased to now over 17GB
> (span of about 7.5 hours)  (after the expected initial jump to about
> 5GB as our Product Queue is 4GB)
> 
> Here are the top few processes when I run "top" -- nothing looks even
> remotely excessive.
> 
> top - 00:49:56 up  8:47,  1 user,  load average: 0.01, 0.02, 0.00
> Tasks: 493 total,   1 running, 492 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:  24592160k total, 17379852k used,  7212308k free,   268112k buffers
> Swap: 26836984k total,        0k used, 26836984k free, 14821172k cached
> 
> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 3936 ldm       20   0 3944m 129m 127m S  0.3  0.5   0:15.41 ldmd
> 3940 ldm       20   0 3942m 761m 760m S  0.3  3.2   0:30.77 ldmd

Note that the virtual memory usage of the LDM processes is reasonable given 
that your product-queue is about 4 GB.

> 8366 ldm       20   0 35136 9776 1264 S  0.3  0.0   0:00.30 dcgrib2
> 8379 ldm       20   0 15284 1532  928 R  0.3  0.0   0:00.11 top
> 1 root      20   0 19328 1508 1212 S  0.0  0.0   0:01.49 init
> 2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
> 3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
> 4 root      20   0     0    0    0 S  0.0  0.0   0:00.05 ksoftirqd/0
> 5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
> 6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
> 7 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
> 8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
> 9 root      20   0     0    0    0 S  0.0  0.0   0:00.19 ksoftirqd/1
> 10 root      RT   0     0    0    0 S  0.0  0.0   0:00.02 watchdog/1
> 11 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/2
> 12 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/2
...

> Thanks in advance for your help or insight on thisâ We appreciate itâ

As long as you don't start using significant amounts of swap space, I wouldn't 
worry.

> -- Phil  Birnie --
> Department of Geography
> The Ohio State University
> (614)519-6176
> 
> Cc. Jim DeGrand, Jens Blegvad

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: VVA-689466
Department: Support LDM
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.