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

20021112: dmraob.k and dmsyn.k hanging on weather2; LDM memory leak (cont.)



>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200210050242.g952g0127088 McIDAS-XCD DMRAOB DMSYN

Gilbert,

I spent a profitable weekend on weather2 finding and fixing small
memory leaks in C routines used by McIDAS-XCD data monitors.  By
the time I logged off last night, I had gotten to the point that
DMSYN would run without sucking up all of the CPU.  I also found
out when this happens, it is when data comes in for a day in the
future AND the MD file into which that data is to be written does
not yet exist.  For some reason, right after making the new MD file,
the memory image of the decoder more than doubles in size.  Even
with that, it is relatively small in the overall scheme of things,
less than 3 MB.

I have not been able to figure out why DMSYN grows appreciably, but
with all of the memory leaks I fixed, it grows to a smaller size than
previously: now, when it expands, it stays under 3 MB.

Now after DMSYN grows, it continues to decode data while using little
of the CPU.  Interestingly, after some time (greater than 10 minutes)
DMSYN suddenly drops in size.  Again, I am at a loss for why/how this
happens.  It is almost as if memory allocated and then freed is
not freed for some time.  After that time, it is suddenly returned
to the pool.  This makes little sense to me, but it fits the observations.

Now, the fact that DMSYN gets bigger should have never affected its
running.  The same thing happens on all other OS that XCD runs on
including RedHat 6.x and 7.x Linux, and DMSYN keeps humming along.
So, my conclusion is that there is something magic about either
an executable that more than doubles in size or is greather than
3 MB.  I doubt the second case since there are plenty of routines
running on your system that are significantly larger than 3 MB (e.g.,
pqact, gnome, etc.)

Any way, I just wanted to let you know that there have been code changes
made that are inaddition to your new kernel install.  When it gets
near 0Z, we will be able to see if either/both of these changes is
sufficient to allow DMSYN to continue decoding and not hammer your system.

As far as your earlier conjecture that the LDM also hitting the wall,
I have not seen this happen on weather2.  If the problem was not the
5.2.0 rtstats leak, then I am back to being suspicious of RH 8.

Tom