Re: setproctitle_fast() - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: setproctitle_fast()
Date
Msg-id CAEepm=2YjsvHkOfLa9FMA0J4e0NiTdE9WSt4W=9cRRy4u5qNvQ@mail.gmail.com
Whole thread Raw
In response to Re: setproctitle_fast()  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: setproctitle_fast()  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Sat, Jul 7, 2018 at 11:57 PM, Emre Hasegeli <emre@hasegeli.com> wrote:
>> FreeBSD's setproctitle() is a bit slow because it contains a syscall
>> or two, so people often run PostgreSQL with update_process_title set
>> to off on that OS.  That makes the user experience not quite as nice
>> as Linux.  As a weekend learn-me-some-kernel-hacking project I fixed
>> that and got the patch committed to FreeBSD 12, though I was asked to
>> use a new libc entry point _fast().  Here's a patch to teach
>> PostgreSQL about that.  It doesn't have much effect on small systems,
>> but it makes "pgbench -c 40 -j 40 -S -M prepared" do ~10% more
>> transactions per second on an AWS m4.10xlarge instance.
>
> I am curious why they asked you to use a new libc entry point.  The
> function signatures are the same.  More people could benefit from
> making the existing function faster.

There is a small trade-off: ps/top/htop do a bit more work (the kernel
has to go and pull the data out of the source process's memory instead
of keeping its own copy maintained via syscalls).  Originally I
proposed to make setproctitle() adaptive, figuring out who were the
frequent updaters, but the heuristics I proposed were rejected and it
looked hard to come up with better ones[1].  There may also be an
argument that you should have to opt into the fast and loose
consistency of this approach explicitly (though no one seems to mind
about that on Linux).

Anyway, I guess there aren't too many other applications that want to
do this kind of thing at 1MHz or whatever!

[1] https://lists.freebsd.org/pipermail/freebsd-hackers/2018-July/052975.html

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Brent Kerby
Date:
Subject: Re: Transition relations: correlating OLD TABLE and NEW TABLE
Next
From: Stephen Frost
Date:
Subject: Re: Desirability of client-side expressions in psql?