Re: [doc fix] Correct calculation of vm.nr_hugepages - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [doc fix] Correct calculation of vm.nr_hugepages
Date
Msg-id 20180301095437.shuf3hf4g6n3kchn@alap3.anarazel.de
Whole thread Raw
In response to RE: [doc fix] Correct calculation of vm.nr_hugepages  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: [doc fix] Correct calculation of vm.nr_hugepages  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 2018-02-20 02:43:32 +0000, Tsunakawa, Takayuki wrote:
> diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
> index d162acb..1aed070 100644
> --- a/doc/src/sgml/runtime.sgml
> +++ b/doc/src/sgml/runtime.sgml
> @@ -1472,14 +1472,14 @@ export PG_OOM_ADJUST_VALUE=0
>      the kernel setting <varname>vm.nr_hugepages</varname>. To estimate the
>      number of huge pages needed, start <productname>PostgreSQL</productname>
>      without huge pages enabled and check the
> -    postmaster's <varname>VmPeak</varname> value, as well as the system's
> +    postmaster's anonymous shared memory segment size, as well as the system's
>      huge page size, using the <filename>/proc</filename> file system.  This might
>      look like:
>  <programlisting>
>  $ <userinput>head -1 $PGDATA/postmaster.pid</userinput>
>  4170
> -$ <userinput>grep ^VmPeak /proc/4170/status</userinput>
> -VmPeak:  6490428 kB
> +$ <userinput>pmap 4170 | awk '/rw-s/ && /zero/ {print $2}'</userinput>
> +6490428K
>  $ <userinput>grep ^Hugepagesize /proc/meminfo</userinput>
>  Hugepagesize:       2048 kB
>  </programlisting>

One disadvantage of this is that it relies on the presence of pmap,
which IIRC is not installed by default in a number of distributions. Are
we concerned about that?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: 2018-03 Commitfest starts tomorrow
Next
From: 马来酸
Date:
Subject: [GSOC 18] Performance Farm Project