memory problem!!

[KO kwang tae]

web server : rp5470

we are only using webserver

application : iPlanet webserver

we have some problem.

memory are incresing everyday.

after rebooting, memory usage : 20%

but after 3 weeks, memory usage : 68%

i don't understand what happened.

please help!!

[Jeff Schussele]

Two words....

Memory Leak

Send that crap back to the programmers & demand they code it right.

To paraphrase a famous movie line....

If you give it to them, they must give it back.

Good Luck,
Jeff

[KO kwang tae]

memory 2G.

swapinfo

memory 1571368 993596 637772

[Michael Steele_2]

See above

[Jeff Schussele]

Hi,

I understand. But you could have 22 Gb of RAM, and if after each cycle of the binaries being run you lose 5K, how long would it take to exhaust that memory if each cycle occupied 1 minute?
ANY programmer knows how to grab RAM, the good ones know how to *properly* release it when they're done with it.

BOTTOM LINE: If the load's not growing & memory consumption KEEPS growing, you have a memory leak. And it will *never* fix itself...nor will you.
One of the high arts of being an SA is being able to spot these obvious programming flaws, backing that argument up with hard data & not being backed down by hollow arguments just because they *sound* more educated. Whenever somebody tries to pull the BS blanket over me I love to shove the FACTS down their throat & watch them try to squirm outta that with buzzwords.

My 2 cents,
Jeff

[Frank Slootweg]

*Which* field of *which* utility shows "memory usage"?

If that is *total* memory usage as shown for example by Glance ("Mem Util"), then 20% is *bad* and 68% is *good*. Why? Because HP-UX treats main memory as a chache and a good cache is always full. HP-UX keeps main memory *nearly* full, where "nearly" is upto some 95%, in order to speed up the startup of small processes.

So you *might* have a problem, but it is also quite possible that everything is OK. More details are needed to tell which.

[Bill Douglass]

Is your memory usage growing over time, or does it jump up to 68%+ and stay there. If growing, then you likely have a memory leak in one of your applications. If it levels off after a short time, then you're seeing normal buffer cache activity.

Collect vmstat output over several days and compare to deterime if you have a memory leak or just a large buffer cache.

vmstat 3600 > /tmp/vmstat.log

will collect statistics every hour and store them for later review.

[Tim Sanko]

If you are draining memory that quickly, I recommend a weekly, or bi-weekly maintenance reboot.

Explain that the application currently requires it, and request that the problem be remanded to the programming staff.

Explain that memory leaks occur when XYZ happens,

In C, calloc,malloc, without a free was a big no-no. look for the cores laying around , and examine them with "strings | pg" and other such techniques until the culprits are put to bed. It isn't your problem, but you will probably be the solution.

Tim

[Filosofo]

Hello.....I have not a soluctio to you prolems....I have a question.
What is "memory leak"?

Filo

[Hai Nguyen_1]

Can you run the command below and post the output:

# kmtune | grep dbc

It is possible that your dbc_max_pct has been set as default.

Hai

[Robert-Jan Goossens]

Filo,

I think in Italian something like "deposito falla"

Robert-Jan

[doug hosking]

Frank's comments may well be the key here.
It's not uncommon to think there's a serious
problem when the system is actually behaving exactly as expected.

You have to look at more than just memory usage. If the memory is just going into the buffer cache, it's usually a good thing. That memory is simply being borrowed while it's not needed for more important purposes, and will be freed when it is needed for a 'better' purpose, such as for programs. The kernel tries to intelligently allocate memory where it is most needed. Giving more memory to the file system buffer cache speeds up disk I/O (up to a point). When the kernel notices that free memory is getting low, it will take back the memory it loaned to the buffer cache. Sometimes half or more of total system memory gets loaned this way, making it *appear* that there is a massive memory leak.

Try this periodically (once an hour):
# /usr/sbin/sysdef | grep bufpages
# /usr/sbin/sysdef | grep nbuf
Are the numbers displayed going up over time?
If so, it's a sign that the memory is simply being used for the kernel's file buffer cache.

Adjusting the kernel tunable parameter dbc_max_pct lower may reduce this effect.
(For example, reducing it from 50 to 20%.)
However, setting it too low can hurt system performance. The correct value for this depends in large part on the specifics of your hardware configuration, the types of applications you run and how many files you access.

If some program has a true memory leak, it may or may not be a problem. Even if the program is leaking memory, the memory will be freed by the kernel when the program exits (unless the kernel is the one losing memory). Memory leaks can be a problem in the case of server processes that run 'forever' because this leaked memory can't be reclaimed until that program exits. You can often spot these leaks by using 'top' or 'ps -el' and looking at the
size fields.

[Geoff Wild]

There may not be an issue at all - unless it starts swapping.

Take DNS for example - it will, over time, grow the cache and use all the available memory (unless you restrict it with something like PRM [Process Resource Manager]).

Depends on what your Iplanet server is doing - but it could just be caching...

We have Iplanet here - and I believe the server's memory footprint does grow - but nebver more than the available ram...

Also check your DBC_MAX_PCT - default is 50% - for Oracle, we drop this down to 10% - that way the App has more system memory available...

Rgds...Geoff

[Jeff Schussele]

Hi Filo,

I define memory leak as code that does not release ALL the memory allocated to it during it's life when it completely, normally exits. I do not count abnormal termination.

Rgds,
Jeff