what if native systemd service is slower than old sysvinit script?

Tom Lane tgl at redhat.com
Wed Sep 14 17:06:59 UTC 2011

=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4 at 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

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

More information about the devel mailing list