PostgresSQL vs super pages

[Thomas Munro]

On Mon, 15 Oct 2018 at 11:33, Mark Johnston <markj at freebsd.org> wrote:
> On Sun, Oct 14, 2018 at 02:45:44PM +0300, Konstantin Belousov wrote:
> > On Sun, Oct 14, 2018 at 10:58:08PM +1300, Thomas Munro wrote:

> > > Huh.  Your program doesn't result in an S mapping on my laptop, but I
> > > tried on an EC2 t2.2xlarge machine and there it promotes to S, even if
> > > I comment out the write() loop (the loop that assigned to every byte
> > > is enough).  The difference might be the amount of memory on the
> > > system: on my 4GB laptop, it is very reluctant to use super pages (but
> > > I have seen it do it, so I know it can).  On a 32GB system, it does it
> > > immediately, and it works nicely for PostgreSQL too.  So perhaps my
> > > problem is testing on a small RAM system, though I don't understand
> > > why.
> > How many free memory does your system have ? Free as reported by top. If
> > the free memory is low and fragmented, and I suppose it is on 4G laptop
> > which you use with X, browser and other memory-consuming applications,
> > system would have troubles filling the reverve, i.e reserving 2M of
> > 2M-aligned physical pages.
>
> BTW, this can be explicitly verified with the sysctl vm.phys_free
> sysctl.  Superpage promotion requires free 2MB chunks from freelist 0,
> pool 0.

Ah, I see.  Straight after rebooting without X I get super pages and
vm.phys_free looks more healthy.  I'd observed the same problem on
other machines including servers with a bit (but not a lot) more
memory, but clearly none of my FreeBSD systems are currently big
enough to keep suitable chunks around on the freelist.  I wonder if
ZFS is a factor.  Well, this was educational.  Thanks very much for
your help!