=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
