=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4@gmail.com> writes:
> 2011/9/13 Tom Lane <tgl@redhat.com>:
>> (This isn't new with 9.1, btw --- the last version or so of 9.0
>> for F16 was the same, since we switched over to native systemd
>> files.)

> I used this service file on F15 and it starts slower
> 4214ms postgresql.service

> if we compare with an old SysVinit script
> 2469ms postgresql.service

> So I wonder if it makes sense to convert in such case?

The reason it makes sense to convert is that sysv init scripts are
second-class citizens in the eyes of systemd, and the systemd developers
exhibit no interest in making such scripts actually usable. In
particular the handling of error reports is several steps south of
unacceptable --- cf bug #622663, which is more than a year old and has
been steadfastly ignored. I don't think this is accidental; the
systemd developers want to force all packages to migrate to native
systemd scripts eventually, and one of the best ways to do that is to
make sure that the old scripts are as unfriendly to use as possible.
Minor performance differences aren't going to outweigh complaints
like "my database didn't start and there is no useful error message
anywhere, especially not where systemd told me to look".

Still, given that we were told that eliminating the use of shell
scripting ought to make things faster, your report surprises me.
Certainly postgresql.init was never exactly lean-and-mean, so it
seems like it ought to have been doing more work than the unit file
requires. Are you sure you were comparing apples to apples as far as
the state of the database, kernel disk cache, etc goes?

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4@gmail.com> writes:
> 2011/9/14 Tom Lane <tgl@redhat.com>:
>> Certainly postgresql.init was never exactly lean-and-mean, so it
>> seems like it ought to have been doing more work than the unit file
>> requires. *Are you sure you were comparing apples to apples as far as
>> the state of the database, kernel disk cache, etc goes?

> I copied the service to /etc/systemd/system and changed PGDATA
> variable, then I enabled the service and rebooted. After boot I
> checked system boot time with systemd-analyze - I saw that it starts
> slow, so I disabled it and deleted from /etc/systemd/system. After
> another reboot again checked boot time with systemd-analyze.

> I'll check tomorrow how repeatable is native service boot time.

I'd suggest first timing some rounds of manual "service postgresql start",
"service postgresql stop" to see what things look like without all
the other noise involved in a system boot.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

=?ISO-8859-2?Q?Miloslav_Trma=E8?= <mitr@volny.cz> writes:
> 2011/9/14 "Jóhann B. Guðmundsson" <johannbg@gmail.com>:
>> An simple test to measure this reliably is to strip down the legacy sysv
>> init script to the start up command only and have a strip down unit file to
>> the startup command only.
>>
>> Then time the startup of either.

> Why? The current numbers show that the service file is _slower_ even
> when the old init script is supposedly doing much more work in shell.
> If anything, stripping the unessential parts should make the service
> file _even slower_ in relative terms.

Yes. The unit file is already stripped down: it does nothing except
"pg_ctl start". The init script had accumulated a whole lot of
perhaps-unnecessary sanity-checking, which frankly I'd rather have kept
but the systemd mantra seems to be "no shell scripting" so I didn't.

Michal's numbers look pretty damning, and I find it remarkable that the
systemd advocates seem to have managed not to read them, let alone admit
that they suggest something's seriously wrong.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 09/14/2011 11:28 AM, Tom Lane wrote:

=?ISO-8859-2?Q?Miloslav_Trma=E8?= <mitr@volny.cz> writes:


2011/9/14 "Jóhann B. Guðmundsson" <johannbg@gmail.com>:


An simple test to measure this reliably is to strip down the legacy sysv
init script to the start up command only and have a strip down unit file to
the startup command only.

Then time the startup of either.






Why? The current numbers show that the service file is _slower_ even
when the old init script is supposedly doing much more work in shell.
If anything, stripping the unessential parts should make the service
file _even slower_ in relative terms.



Yes. The unit file is already stripped down: it does nothing except
"pg_ctl start". The init script had accumulated a whole lot of
perhaps-unnecessary sanity-checking, which frankly I'd rather have kept
but the systemd mantra seems to be "no shell scripting" so I didn't.

Michal's numbers look pretty damning, and I find it remarkable that the
systemd advocates seem to have managed not to read them, let alone admit


Don't confuse we with facts! I've already made up my mind! ;-)


that they suggest something's seriously wrong.

regards, tom lane






--

Stephen*Clark

NetWolves

Sr.*Software*Engineer*III

Phone:*813-579-3200

Fax:*813-882-0209

Email:*steve.clark@netwolves.com

http://www.netwolves.com




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4@gmail.com> writes:
> Ok, I made four series of tests:
> - start/stop an old init script
> - start/stop an old init script with dropping caches - should simulate
> system booting
> - start/stop service file
> - start/stop service file with dropping caches

> In each series of tests were repeated five times.
> series 1 - start - 2.2+ sec
> series 1 - stop - 1.2+ sec

> series 2 - start - 2.4+ sec
> series 2 - stop - 1.3+ sec

> series 3 - start - 3.1+ sec
> series 3 - stop - 1.1+ sec

> series 4 - start - 4.2+ sec
> series 4 - stop - 1.1+ sec

> Results are reproducible.

I tried to replicate these results on my own F15 laptop, and could not
--- the service file method doesn't really seem significantly faster
than the init script, but it's not slower either.

Here's what I did:

1. Install the postgresql-9.1.0 RPMs (rebuilt for F15 of course)
and do "postgresql-setup initdb".

2. Set log_line_prefix = '%m %p ' and log_connections = on in
postgresql.conf, so that log messages will be timestamped. Also set
timezone and log_timezone to desired values (I use 'US/Eastern');
if you don't do that, the server startup time is increased significantly
while Postgres tries to figure out the system timezone setting.

3. As root, do
date --rfc-3339=ns ; systemctl start postgresql.service ; date --rfc-3339=ns

4. Note the time from the first "date" output to the "database system is
ready to accept connections" message getting logged (in the appropriate
file under /var/lib/pgsql/data/pg_log, if you haven't changed any other
logging settings). Stop and restart a few times to get a good average.

5. Install the F15 version of postgresql.init (be sure to adjust the
PGVERSION setting near the top of the file to be 9.1.0).

6. Start it that way a few times, note the same elapsed time.

I'm seeing numbers consistently around 0.3 second for the unit file,
and a bit less consistent but maybe 0.35 - 0.5 second for the script.

Note that the time for the service to report itself ready after the
database has started is likely to be quite a bit different between the
two methods, but that is not systemd's fault. The init script just
launches the postmaster, sleeps for 2 seconds, and then reports "OK"
if it sees the postmaster has created a PID file. The unit file uses
pg_ctl, which actually waits till it can make a successful connection
to the postmaster, sleeping 1 second between tries. So it's a bit of a
crapshoot which will be longer, though if you are starting from a clean
database shutdown I'd expect pg_ctl to usually come back after the first
sleep.

So I'm not sure what's happening on Michal's machine, but from here I
don't see anything egregiously wrong with systemd's performance on
this test.

regards, tom lane
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel