Re: [GENERAL] Huge Pages - setting the right value

2017-06-12 Thread pinker
standard hugepages, transparent are disabled. They were set exactly following the procedure from postgres documentation. -- View this message in context: http://www.postgresql-archive.org/Huge-Pages-setting-the-right-value-tp5952972p5966064.html Sent from the PostgreSQL - general mailing list

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread Andrew Kerber
Yes, those should always be disabled using tuned or other methods. Using tuned is described here (second method). I think the grub.conf method described is unique to RHEL/OEL/CENTOS. http://houseofbrick.com/disabling-transparent-hugepages-using-tuned/ On Sun, Jun 11, 2017 at 5:00 PM, Lucas

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread Lucas Possamai
2017-06-12 9:52 GMT+12:00 Andrew Kerber : > Was that transparent hugepages or standard hugepages? databases commonly > have problems dealing with transparent hugepages. > > IN my case, it was the Transparent Hugepages Lucas

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread Andrew Kerber
Was that transparent hugepages or standard hugepages? databases commonly have problems dealing with transparent hugepages. On Sun, Jun 11, 2017 at 4:39 PM, Lucas Possamai wrote: > 2017-06-12 7:52 GMT+12:00 Andrew Kerber : > >> I am sure it does

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread Lucas Possamai
2017-06-12 7:52 GMT+12:00 Andrew Kerber : > I am sure it does not. > > Sent from my iPhone > > > On Jun 11, 2017, at 10:50 AM, pinker wrote: > > > > Andrew Kerber wrote > >> I can't give you an absolutely authoritative answer, but because of the > >> way

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread Andrew Kerber
I am sure it does not. Sent from my iPhone > On Jun 11, 2017, at 10:50 AM, pinker wrote: > > Andrew Kerber wrote >> I can't give you an absolutely authoritative answer, but because of the >> way hugepages are implemented and allocated, I can't think how they could >> be used

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread pinker
Andrew Kerber wrote > I can't give you an absolutely authoritative answer, but because of the > way hugepages are implemented and allocated, I can't think how they could > be used for other processes. Linux hugepages are either 2m or 1g, far too > large for any likely processes to require. They

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread Andrew Kerber
I can't give you an absolutely authoritative answer, but because of the way hugepages are implemented and allocated, I can't think how they could be used for other processes. Linux hugepages are either 2m or 1g, far too large for any likely processes to require. They cannot be allocated in

Re: [GENERAL] Huge Pages - setting the right value

2017-06-11 Thread pinker
We are experiencing some performance issues because of high CPU load. So I would like to ask one more time. The exact question is: Does PostgreSQL can use huge pages for processes or only for shared buffers? (Does it make any sense to set the number of huge pages above the shared_buffers?) Any

Re: [GENERAL] Huge Pages - setting the right value

2017-03-30 Thread pinker
W dniu 2017-03-30 11:45:55 użytkownik pinker napisał: > Hi, > I'm currently testing performance with and without huge pages. Documentation > says that in order to estimate the number of huge pages needed one should > check the postmaster's VmPeak value. I wonder if it's only

[GENERAL] Huge Pages - setting the right value

2017-03-30 Thread pinker
Hi, I'm currently testing performance with and without huge pages. Documentation says that in order to estimate the number of huge pages needed one should check the postmaster's VmPeak value. I wonder if it's only postmaster memory usage what's matters? Or I could get better estimation from the