Re: [doc fix] Correct calculation of vm.nr_hugepages
От | Justin Pryzby |
---|---|
Тема | Re: [doc fix] Correct calculation of vm.nr_hugepages |
Дата | |
Msg-id | 20180219121602.GC30278@telsasoft.com обсуждение исходный текст |
Ответ на | [doc fix] Correct calculation of vm.nr_hugepages ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
RE: [doc fix] Correct calculation of vm.nr_hugepages
|
Список | 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@pryzbyj:~$ sudo pmap `pgrep -P 1 -u postgres` |awk '/rw-s/&&/zero/{print $2}' # check PPID=1 144848K or: pryzbyj@pryzbyj:~$ sudo pmap `pgrep -u postgres |sed q` |awk '/rw-s/&&/zero/{print $2}' # check any backend, not just postmasterparent 144848K Or (this is even less clean but gives an alternative which continues to use /proc directly): pryzbyj@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@pryzbyj:~$ sudo sh -c 'cat /proc/`pgrep -u postgres -P1`/smaps |grep -c "KernelPageSize: *2048 kB"' || echo NOT FOUND 0 NOT FOUND Justin
В списке pgsql-hackers по дате отправления: