From dima@unixfreak.org  Sat Feb 24 00:44:21 2001
Return-Path: <dima@unixfreak.org>
Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138])
	by hub.freebsd.org (Postfix) with ESMTP id B3D7D37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 24 Feb 2001 00:44:20 -0800 (PST)
	(envelope-from dima@unixfreak.org)
Received: from hornet.unixfreak.org (hornet [63.198.170.140])
	by bazooka.unixfreak.org (Postfix) with ESMTP id 48A3A3E02
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 24 Feb 2001 00:44:20 -0800 (PST)
Received: (from dima@localhost)
	by hornet.unixfreak.org (8.11.1/8.11.1) id f1O8iJV15773;
	Sat, 24 Feb 2001 00:44:20 -0800 (PST)
	(envelope-from dima)
Message-Id: <200102240844.f1O8iJV15773@hornet.unixfreak.org>
Date: Sat, 24 Feb 2001 00:44:20 -0800 (PST)
From: dima@unixfreak.org
Reply-To: dima@unixfreak.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: [PATCH] New FAQ entry about rpc.statd(8) appearing to use 256MB of memory
X-Send-Pr-Version: 3.2

>Number:         25340
>Category:       docs
>Synopsis:       [PATCH] New FAQ entry about rpc.statd(8) appearing to use 256MB of memory
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 24 00:50:01 PST 2001
>Closed-Date:    Sat Feb 24 04:18:42 PST 2001
>Last-Modified:  Sat Feb 24 04:18:53 PST 2001
>Originator:     Dima Dorfman
>Release:        FreeBSD 4.2-20010102-STABLE i386
>Organization:
Private
>Environment:

Not relevant.

>Description:

rpc.statd(8) maps 256MB into its address space to facilitate status
file growth.  This makes it look like it's using all that memory,
which often causes concern when the average user (or admin) runs
top(1) or ps(1).

>How-To-Repeat:

Read -questions.

>Fix:

Apply the following patch to doc/en_US.ISO_8859-1/books/faq/book.sgml.

Index: book.sgml
===================================================================
RCS file: /st/src/FreeBSD/doc/en_US.ISO_8859-1/books/faq/book.sgml,v
retrieving revision 1.144
diff -u -r1.144 book.sgml
--- book.sgml	2001/02/17 01:07:43	1.144
+++ book.sgml	2001/02/23 23:42:37
@@ -6795,6 +6795,30 @@
 	     &man.rc.conf.5; man page for more information on rc.conf.</para>
         </answer>
       </qandaentry>
+
+      <qandaentry>
+        <question id="statd-mem-leak">
+          <para>There is a memory leak in &man.rpc.statd.8;!  It is using
+            256 Mbytes of memory!</para>
+        </question>
+
+        <answer>
+          <para>No, there is no memory leak, and it's not using 256 Mbytes
+            of memory.  It simply likes to (i.e., always does) map an
+            obscene amount of memory into its address space for convenience.
+            There is nothing terribly wrong with this from a technical
+            standpoint; it just throws off things like &man.top.1; and
+            &man.ps.1;.</para>
+
+          <para>&man.rpc.statd.8; maps its status file (resident on
+            <filename>/var</filename>) into its address space; to save
+            worrying about remapping it later when it needs to grow, it maps
+            it with a generious size.  This is very evident from the source
+            code, where one can see that the length argument to &man.mmap.2;
+            is <literal>0x10000000</literal>, or one sixteenth of the
+            address space on an IA32, or exactly 256MB.</para>
+        </answer>
+      </qandaentry>
     </qandaset>
   </chapter>
 


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: nik 
State-Changed-When: Sat Feb 24 04:18:42 PST 2001 
State-Changed-Why:  
Committed, thanks 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25340 
>Unformatted:
