|
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> |