View | Details | Raw Unified | Return to bug 25340
Collapse All | Expand All

(-)book.sgml (+24 lines)
Lines 6795-6800 Link Here
6795
	     &man.rc.conf.5; man page for more information on rc.conf.</para>
6795
	     &man.rc.conf.5; man page for more information on rc.conf.</para>
6796
        </answer>
6796
        </answer>
6797
      </qandaentry>
6797
      </qandaentry>
6798
6799
      <qandaentry>
6800
        <question id="statd-mem-leak">
6801
          <para>There is a memory leak in &man.rpc.statd.8;!  It is using
6802
            256 Mbytes of memory!</para>
6803
        </question>
6804
6805
        <answer>
6806
          <para>No, there is no memory leak, and it's not using 256 Mbytes
6807
            of memory.  It simply likes to (i.e., always does) map an
6808
            obscene amount of memory into its address space for convenience.
6809
            There is nothing terribly wrong with this from a technical
6810
            standpoint; it just throws off things like &man.top.1; and
6811
            &man.ps.1;.</para>
6812
6813
          <para>&man.rpc.statd.8; maps its status file (resident on
6814
            <filename>/var</filename>) into its address space; to save
6815
            worrying about remapping it later when it needs to grow, it maps
6816
            it with a generious size.  This is very evident from the source
6817
            code, where one can see that the length argument to &man.mmap.2;
6818
            is <literal>0x10000000</literal>, or one sixteenth of the
6819
            address space on an IA32, or exactly 256MB.</para>
6820
        </answer>
6821
      </qandaentry>
6798
    </qandaset>
6822
    </qandaset>
6799
  </chapter>
6823
  </chapter>

Return to bug 25340