Date: Sun, 14 Oct 2018 18:33:49 -0400 From: Mark Johnston <markj@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Thomas Munro <munro@ip9.org>, alc@freebsd.org, freebsd-hackers@freebsd.org, mjg@freebsd.org Subject: Re: PostgresSQL vs super pages Message-ID: <20181014223349.GA9022@raichu> In-Reply-To: <20181014114544.GA5335@kib.kiev.ua> References: <CADLWmXU=7QM-oHmY=TMAQanQE-dnXY4v74Zm1kkEz3Gc=ip21A@mail.gmail.com> <20181011001954.GV5335@kib.kiev.ua> <CADLWmXWS6qjt02bxUkd7BewfhYw69at8OYe%2Bh15%2B1OCpnpi6ng@mail.gmail.com> <20181013235021.GX5335@kib.kiev.ua> <CADLWmXVN=anzRfP0kGkCVW2NR%2Bu9Gcx=O1GVdbn_ZJuvzC7gHg@mail.gmail.com> <20181014114544.GA5335@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> > On Sun, 14 Oct 2018 at 12:50, Konstantin Belousov <kostikbel@gmail.com> wrote:
> > > On Thu, Oct 11, 2018 at 02:01:20PM +1300, Thomas Munro wrote:
> > > > On Thu, 11 Oct 2018 at 13:20, Konstantin Belousov <kostikbel@gmail.com> wrote:
> > > > > On Thu, Oct 11, 2018 at 12:59:41PM +1300, Thomas Munro wrote:
> > > > > > shm_open("/PostgreSQL.1721888107",O_RDWR|O_CREAT|O_EXCL,0600) = 46 (0x2e)
> > > > > > ftruncate(46,0x400000) = 0 (0x0)
> > > > > Try to write zeroes instead of truncating.
> > > > > This should activate the fast path in the fault handler, and if the
> > > > > pages allocated for backing store of the shm object were from reservation,
> > > > > you should get superpage mapping on the first fault without promotion.
> > > >
> > > > If you just write() to a newly shm_open()'d fd you get a return code
> > > > of 0 so I assume that doesn't work. If you ftruncate() to the desired
> > > > size first, then loop writing 8192 bytes of zeroes at a time, it
> > > > works. But still no super pages. I tried also with a write buffer of
> > > > 2MB of zeroes, but still no super pages. I tried abandoning
> > > > shm_open() and instead using a mapped file, and still no super pages.
> > >
> > > I did not quite scientific experiment, but you would need to try to find
> > > the differences between what I did and what you observe. Below is the
> > > naive test program that directly implements my suggestion, and the
> > > output from the procstat -v for it after all things were set up.
> > >
> > ...
> > > 98579 0x800e00000 0x801200000 rw- 1024 1030 3 0 --S- df
> >
> > 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.
>
> You can try the test programs right after booting into single user mode.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181014223349.GA9022>