=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <[email protected]> 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
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
