memory measurement : different value between top/ps and mallinfo

[lxu4net]

There's a huge hash table in my application. I use it as a main
memory database. A lot of client write random data into the hash
table, so it call a lot of malloc() / free(). But after it run for
days, I watched it used a lot of memory. Finally it failed to call
malloc (). I use mallinfo() to watch the detail info. I found the
memory usage is different between the RSS value of "top" and
mallinfo().
"top" / "ps" tell me the application memory usage is 1.8G, but
mallinfo() say mallinfo.arena + mallinfo.hblkhd=1G.
Then I use pmap to see detail infomation. The "pmap" report 800M
"anon" blocks.

What's the "anon" blocks that "pmap" reported? Are they memory leak
or fragmentation? How can I avoid it?

[lxu4net]

My software env is SUSE 10 (with GCC and libc).

[Keith Thompson]

lxu4net <lx*****@gmail.comwrites:

There's a huge hash table in my application. I use it as a main
memory database. A lot of client write random data into the hash
table, so it call a lot of malloc() / free(). But after it run for
days, I watched it used a lot of memory. Finally it failed to call
malloc (). I use mallinfo() to watch the detail info. I found the
memory usage is different between the RSS value of "top" and
mallinfo().
"top" / "ps" tell me the application memory usage is 1.8G, but
mallinfo() say mallinfo.arena + mallinfo.hblkhd=1G.
Then I use pmap to see detail infomation. The "pmap" report 800M
"anon" blocks.

What's the "anon" blocks that "pmap" reported? Are they memory leak
or fragmentation? How can I avoid it?

The C language doesn't refer to mallinfo, RSS, top, ps, pmap, or
"anon" blocks. Try asking in a forum that deals with your system,
perhaps comp.unix.programmer or one of the Linux groups.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

lxu4net wrote:

>
There's a huge hash table in my application. I use it as a main
memory database. A lot of client write random data into the hash
table, so it call a lot of malloc() / free(). But after it run for
days, I watched it used a lot of memory. Finally it failed to call
malloc (). I use mallinfo() to watch the detail info. I found the
memory usage is different between the RSS value of "top" and
mallinfo().

"top" / "ps" tell me the application memory usage is 1.8G, but
mallinfo() say mallinfo.arena + mallinfo.hblkhd=1G. Then I use
pmap to see detail infomation. The "pmap" report 800M "anon" blocks.

What's the "anon" blocks that "pmap" reported? Are they memory leak
or fragmentation? How can I avoid it?

If you have problems with it, why use the non-standard hash table
in the first place? I have a system that is written entirely in
portable standard C, and is available under GPL licensing. If you
don't like GPL you can negotiate a different license with me (which
will no longer be free).

Just try out <http://cbfalconer.home.att.net/download/hashlib.zip>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[lxu4net]

I found the mallinfo() only give main arena info. malloc_stats() can
give all arena info.

[lxu4net]

I found the mallinfo() only give main arena info. malloc_stats() can
give all arena info.

[CBFalconer]

lxu4net wrote:

>
I found the mallinfo() only give main arena info. malloc_stats()
can give all arena info.

Is this intended to have some meaning? From the 'Re' it is
apparantly a response to something, but absolutely nothing is
quoted.

Some useful links on quoting:
<http://www.xs4all.nl/%7ewijnands/nnq/nquote.html>
<http://www.complang.tuwien.ac.at/anton/mail-news-errors.html>
<http://www.netmeister.org/news/learn2quote2.html>
<http://www.star-one.org.uk/computer/format.htm>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **