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

2018-03-06 Thread Peter Eisentraut
On 3/1/18 04:54, Andres Freund wrote: > 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? It's in the same package as "top", so I think that's fine. -- Peter Eisentraut

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

2018-03-06 Thread Peter Eisentraut
On 2/26/18 08:25, Vasundhar Boddapati wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:tested, passed > > It works. Can

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

2018-03-01 Thread Andres Freund
On 2018-02-20 02:43:32 +, 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

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

2018-02-26 Thread Vasundhar Boddapati
The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed It works. Can be Merged.

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

2018-02-22 Thread Robert Haas
On Wed, Feb 21, 2018 at 3:28 PM, Justin Pryzby wrote: > On Wed, Feb 21, 2018 at 03:14:57PM -0500, Robert Haas wrote: >> On Mon, Feb 19, 2018 at 9:43 PM, Tsunakawa, Takayuki >> wrote: >> > Thanks, I'd like to take this. >> >> Why are these values so large? The example in the documentation shows >

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

2018-02-21 Thread Robert Haas
On Mon, Feb 19, 2018 at 9:43 PM, Tsunakawa, Takayuki wrote: > Thanks, I'd like to take this. Why are these values so large? The example in the documentation shows 6490428 kB, and in my test I got 8733888 kB. But 8733888 kB = 8.3 TB! 8.3 GB would make sense, but 8.3 TB does not. -- Robert Haa

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

2018-02-21 Thread Justin Pryzby
On Wed, Feb 21, 2018 at 03:14:57PM -0500, Robert Haas wrote: > On Mon, Feb 19, 2018 at 9:43 PM, Tsunakawa, Takayuki > wrote: > > Thanks, I'd like to take this. > > Why are these values so large? The example in the documentation shows > 6490428 kB, and in my test I got 8733888 kB. But 8733888 kB

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

2018-02-19 Thread Tsunakawa, Takayuki
From: Justin Pryzby [mailto:pry...@telsasoft.com] > 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 Thanks, I'd like to take this. Regards Takayuki Tsunakawa hugepage_size_doc_v2.patch Description: hu

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

2018-02-19 Thread Justin Pryzby
On Mon, Feb 19, 2018 at 07:05:47AM +, 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 me

[doc fix] Correct calculation of vm.nr_hugepages

2018-02-18 Thread Tsunakawa, Takayuki
Hello, 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. FYI,