Re: [doc fix] Correct calculation of vm.nr_hugepages

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [doc fix] Correct calculation of vm.nr_hugepages
Date: 2018-02-19 12:16:02
Message-ID: 20180219121602.GC30278@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 19, 2018 at 07:05:47AM +0000, Tsunakawa, Takayuki wrote:
> The current PostgreSQL documentation overestimates the number of huge pages
> (vm.nr_hugepages) because the calculation uses the maximum virtual address
> space. In practice, huge pages are only used for the anonymous shared memory
> segment. The attached patch fixes the documentation.

+ <userinput>pmap 4170 | grep rw-s | grep zero | awk '{print $2}'</userinput>

One can do with fewer greps:
pryzbyj(at)pryzbyj:~$ sudo pmap `pgrep -P 1 -u postgres` |awk '/rw-s/&&/zero/{print $2}' # check PPID=1
144848K

or:
pryzbyj(at)pryzbyj:~$ sudo pmap `pgrep -u postgres |sed q` |awk '/rw-s/&&/zero/{print $2}' # check any backend, not just postmaster parent
144848K

Or (this is even less clean but gives an alternative which continues to use
/proc directly):
pryzbyj(at)pryzbyj:~$ sudo cat /proc/`pgrep -P 1 -u postgres`/maps |awk --non-decimal-data 'BEGIN{FS="[ -]"} /zero/{a="0x"$1;b="0x"$2;print (b-a)/1024"kB"}'
144848kB

BTW when huge_pages=try, I've been verifying hugepages are in use by running:
pryzbyj(at)pryzbyj:~$ sudo sh -c 'cat /proc/`pgrep -u postgres -P1`/smaps |grep -c "KernelPageSize: *2048 kB"' || echo NOT FOUND
0
NOT FOUND

Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Levsha 2018-02-19 12:37:21 Tracking object modification time using event triggers
Previous Message Arthur Zakirov 2018-02-19 12:06:51 Re: Prefix operator for text and spgist support