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

Jef Spaleta jspaleta at gmail.com
Wed Sep 14 16:57:18 UTC 2011

2011/9/14 Michał Piotrowski <mkkp4x4 at gmail.com>

> Exactly. F15, PostgreSQL 9.0 and just service file from PostgreSQL
> 9.1. Root filesystem and database are on SSD and Ext4.
Okay... brace yourself.

I just ran this test on my non-SSD ext4 based F15 system and I get the
opposite result on start...repeatably.  On my system the systemd based start
up in the admittedly simple service postgresql start  testing is
consistently faster by about a second.   And just as interesting... my
sysinit times are slower than yours, that's a real head scratcher for me.
If my db test was less overall work to init for some reason I'd expect my
numbers to be faster than yourse in both cases. I have no off the top of my
head theory that could explain that except that your low level disk i/o is
significantly different than mine.

Both variants of "service postgresql stop" is within a 1/10 of a second in
my testing

I can give you the  screen log captures for my tests if you desire to review
my actions but here here is the summary for my simple timing test:  And
admittedly I'm using a simply initiated postgres db. It could be that your
real world database initialization workload is more intensive than my test
and the disk i/o is now a limiting factor in a different way.

And of course my numbers do not discount what your seeing as my test is as
anecdotal as your is. Your numbers may still be indicative of a more nuanced
problem that can be resolved and its good to have your numbers as a starting
point for a discussion around understanding optimization issues (like disk
i/o). We just can't jump to conclusions about why you are seeing what your
are seeing. I hope my numbers serve as a cautionary reminder to those others
on this list that benchmarking disk io intensive tasks can be very complex
and very system dependent.  Certain other people in this discussion are
being overly bombastic and seem to have forgotten this fact.  I hope for all
our sakes they can find a way to ratchet down the hyperbole and look at
these sort of issues with a more clinical approach.

Okay so here's my summary of the quick tests.  Please if you have an updated
methodology for me to test, let me know. I'm willing to reuse a specially
crafted pgsql database if you feel that will help you. Though I'd think we
wan't to do that sort of deep dive comparison off list until we are ready to
publish some summaries after we both feel comfortable with the test runs.


service postgresql status
postgresql.service - LSB: start and stop PostgreSQL server
          Loaded: loaded (/etc/rc.d/init.d/postgresql)
          Active: inactive (dead)
          CGroup: name=systemd:/system/postgresql.service

time service postgresql start
real    0m2.329s
user    0m0.028s
sys     0m0.046s

time service postgresql stop
real    0m1.281s
user    0m0.035s
sys     0m0.096s

time service postgresql start
real    0m2.242s
user    0m0.031s
sys     0m0.038s

time service postgresql stop
real    0m1.235s
user    0m0.031s
sys     0m0.036s

Systemd based:
status postgresql.service
postgresql.service - PostgreSQL database server
          Loaded: loaded (/lib/systemd/system/postgresql.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/postgresql.service

time service postgresql start
real    0m1.141s
user    0m0.019s
sys     0m0.019s

time service postgresql stop
real    0m1.146s
user    0m0.017s
sys     0m0.017s

time service postgresql start
real    0m1.153s
user    0m0.016s
sys     0m0.019s

time service postgresql stop
real    0m1.144s
user    0m0.026s
sys     0m0.014s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110914/f954909c/attachment.html 

More information about the devel mailing list