what if native systemd service is slower than old sysvinit script?
tgl at redhat.com
Tue Sep 13 23:57:28 UTC 2011
=?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4 at gmail.com> writes:
> 2011/9/13 Tom Lane <tgl at 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
> 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
More information about the devel