I tried to test v8 version of patch. Firstly, I was able to start the
postgresql server process with 'huge_pages' set to on. I had to
follow the instructions given in MSDN to enable lock pages in
memory option and also had to start the postgresql server process as
test=# show huge_pages;
To start with, I ran the regression test-suite and didn't find any
failures. But, then I am not sure if huge_pages are getting used or
not. However, upon checking the settings for huge_pages and I found it
as 'on'. I am assuming, if huge pages is not being used due to
shortage of large pages, it should have fallen back to non-huge pages.
I also ran the pgbench tests on read-only workload and here are the
results I got.
pgbench -c 4 -j 4 - T 600 bench
huge_pages=on, TPS = 21120.768085
huge_pages=off, TPS = 20606.288995
 - https://msdn.microsoft.com/en-IN/library/ms190730.aspx
On Thu, Feb 23, 2017 at 12:59 PM, Tsunakawa, Takayuki
> From: Amit Kapila [mailto:amit.kapil...@gmail.com]
>> > Hmm, the large-page requires contiguous memory for each page, so this
>> error could occur on a long-running system where the memory is heavily
>> fragmented. For example, please see the following page and check the memory
>> with RAMMap program referred there.
>> I don't have RAMMap and it might take some time to investigate what is going
>> on, but I think in such a case even if it works we should keep the default
>> value of huge_pages as off on Windows. I request somebody else having
>> access to Windows m/c to test this patch and if it works then we can move
> You are right. I modified the patch so that the code falls back to the
> non-huge page when CreateFileMapping() fails due to the shortage of large
> pages. That's what the Linux version does.
> The other change is to parameterize the Win32 function names in the messages
> in EnableLockPagePrivileges(). This is to avoid adding almost identical
> messages unnecessarily. I followed Alvaro's comment. I didn't touch the two
> existing sites that embed Win32 function names. I'd like to leave it up to
> the committer to decide whether to change as well, because changing them
> might make it a bit harder to apply some bug fixes to earlier releases.
> FYI, I could reproduce the same error as Amit on 32-bit Win7, where the total
> RAM is 3.5 GB and available RAM is 2 GB. I used the attached largepage.c.
> Immediately after the system boot, I could only allocate 8 large pages. When
> I first tried to allocate 32 large pages, the test program produced:
> large page size = 2097152
> allocating 32 large pages...
> CreateFileMapping failed: error code = 1450
> You can build the test program as follows:
> cl largepage.c advapi32.lib
> Takayuki Tsunakawa
> Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
> To make changes to your subscription:
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: