From: Gabriel Barazer <gabriel@oxeva.fr>
To: "Kottaridis, Chris" <chris.kottaridis@windriver.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: Rpc.mountd growing 6 MB/day
Date: Mon, 30 Apr 2007 19:47:52 +0200 [thread overview]
Message-ID: <46362BC8.9040305@oxeva.fr> (raw)
In-Reply-To: <37B62E0F71C9E14B9859FADB1FC3E3E133E51B@ala-mail02.corp.ad.wrs.com>
I have this problem too for a long time and already reported it, but
propably forgotten. My rpc.mountd is actually 350MB and continue
growing, with nfs-utils 1.1.0-rc2:
# rpc.mountd --version
kmountd 1.1.0-rc2
# top
2259 root 15 0 340m 331m 744 S 0.0 16.5 0:20.12 rpc.mountd
I already provided a copy of the /proc/<pid>/smaps which show the main
problem :
00514000-15033000 rw-p 00514000 00:00 0
[heap]
Size: 339068 kB
Rss: 338204 kB
I think there is a memory leak here.
Gabriel Barazer
On 04/30/2007 19:41:07 +0200, "Kottaridis, Chris"
<chris.kottaridis@windriver.com> wrote:
> I have a situation where rpc.mountd is growing continuously and I am not
> sure if it's a memory leak or expected behavior that can be controlled
> with some configuration option.
>
> Top is used to watch rpc.mountd over time and I can see Virtual size
> continually growing. In this environment there is no swap space so RSS
> is growing also. When RSS gets close to Virtual size, Virtual size
> jumps up by 128K until RSS again "catches up" to VIRTUAL which then
> jumps up by 128K again:
>
>
> VIRT RES
> 9951 root 16 0 1812 1052 668 S 0.0 0.0 0:20.07 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 16 0 1812 1052 668 S 0.0 0.0 0:20.19 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 15 0 1812 1052 668 S 0.0 0.0 0:20.44 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 15 0 1940 1056 668 S 0.0 0.0 0:20.57 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 16 0 1940 1056 668 S 0.0 0.0 0:20.69 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 16 0 1940 1056 668 S 0.0 0.0 0:20.70 rpc.mountd
> --nfs-version 2 --nfs-version 3
>
> RES keeps incrementing every so often and eventually:
>
> VIRT RES
> 9951 root 16 0 1940 1180 668 S 0.0 0.0 0:38.85 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 16 0 1940 1180 668 S 0.0 0.0 0:38.99 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 16 0 2068 1184 668 S 0.0 0.0 0:39.14 rpc.mountd
> --nfs-version 2 --nfs-version 3
> 9951 root 16 0 2068 1184 668 S 0.0 0.0 0:39.33 rpc.mountd
> --nfs-version 2 --nfs-version 3
>
> This pattern continues.
>
> I added some xlog() statements in rpc.mountd to try and show me if there
> were some malloc's without free's. I didn't see anything, but here are
> the routines that seemed to get called frequently:
>
> Apr 26 18:55:13 unit0 mountd[24268]: auth_unix_ip client alloced 0x80695e0
> Apr 26 18:55:13 unit0 mountd[24268]: auth_unix_ip client freed 0x80695e0
> Apr 26 18:55:13 unit0 mountd[24268]: nfsd_export alocated dom 0x80695e0
> Apr 26 18:55:13 unit0 mountd[24268]: nfsd_export alocated path 0x80695f0
> Apr 26 18:55:13 unit0 mountd[24268]: nfsd_export : free dom 0x80695e0
> Apr 26 18:55:13 unit0 mountd[24268]: nfsd_export : free path 0x80695f0
> Apr 26 18:55:13 unit0 mountd[24268]: nfsd_fh : dom allocated 0x8069600
> Apr 26 18:55:13 unit0 mountd[24268]: nfsd_fh : freed dom 0x8069600
> Apr 26 19:10:33 unit0 mountd[24268]: auth_unix_ip client alloced 0x8069618
> Apr 26 19:10:33 unit0 mountd[24268]: auth_unix_ip client freed 0x8069618
> Apr 26 19:10:33 unit0 mountd[24268]: nfsd_export alocated dom 0x8069618
> Apr 26 19:10:33 unit0 mountd[24268]: nfsd_export alocated path 0x8069628
> Apr 26 19:10:33 unit0 mountd[24268]: nfsd_export : free dom 0x8069618
> Apr 26 19:10:33 unit0 mountd[24268]: nfsd_export : free path 0x8069628
> Apr 26 19:10:33 unit0 mountd[24268]: nfsd_fh : dom allocated 0x8069638
> Apr 26 19:10:33 unit0 mountd[24268]: nfsd_fh : freed dom 0x8069638
>
> It seems to be these three routines that get called over and over, at
> least so far that I have added xlog()'s to. These seem to be making some
> interactions with the kernel nfsd via /proc, but I am not real sure how
> that would impact rpc.mountd's virtual size.
>
> I am using the kernel NFSD, the kernel version is 2.6.10, the nfs-utils
> version is nfs-utils-1.0.7
>
> I don't know if this growth is expected or if it will eventually stop,
> over a period of days it has not stopped growing, and if there may be
> some configuration option that can control it.
>
> Has anyone seen this behavior before ?
>
> Is it expected and controllable or is there a memory leak here ?
>
> Thanks
>
> Chris Kottaridis
> Senior Engineer
> Wind River Systems
> 719-522-9786
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-04-30 17:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-30 17:41 Rpc.mountd growing 6 MB/day Kottaridis, Chris
2007-04-30 17:47 ` Gabriel Barazer [this message]
2007-04-30 20:06 ` Kottaridis, Chris
2007-04-30 21:24 ` Neil Brown
2007-04-30 22:19 ` Gabriel Barazer
2007-05-01 3:47 ` Neil Brown
2007-05-02 9:20 ` Gabriel Barazer
2007-05-02 11:30 ` Neil Brown
2007-04-30 22:49 ` Gabriel Barazer
2007-05-01 3:49 ` Neil Brown
2007-04-30 21:19 ` Neil Brown
2007-04-30 21:27 ` Kottaridis, Chris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46362BC8.9040305@oxeva.fr \
--to=gabriel@oxeva.fr \
--cc=chris.kottaridis@windriver.com \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.