Thanks Laurent for the detailed explanations. We did a bootup speed
comparison between S6 and systemd. S6 is able to boot up slightly faster
than systemd. Actual result is 4-4.5% faster but we were expecting
something near to 20%.
Ours is a bit complex setup with more than 140 services (includes a lot of
long run services and a lot of dependencies). The main advantage in systemd
is, it starts many critical processes very quickly since it has no
dependency to logging services. We collect the logs from journalctl and
store it in log files. Whereas in S6, the critical services start up is a
bit delayed since it has to depend on logging services which in turn
depends on other services (responsible for backing up the previous logs).
Arjun
On Mon, Aug 2, 2021 at 1:57 PM Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:
> >1. In systemd, the services are grouped as targets and each target depends
> >on another target as well. They start as targets. [ex: Reached
> >local-fs.target, Reached network.target, Reached UI target,...]. Is there
> >any way in S6 to start the init system based on bundles?
>
> Yes, that is what bundles are for. In your stage 2 boot script
> (typically /etc/s6-linux-init/current/scripts/rc.init), you should
> invoke s6-rc as:
> s6-rc change top
> if "top" is the name of your default bundle, i.e. the bundle that
> contains all the services you want to start at boot time. You can
> basically convert the contents of your systemd targets directly into
> contents of your s6-rc bundles; and you decide which one will be
> brought up at boot time via the s6-rc invocation in your stage 2
> init script.
>
>
> >2. Are there any ways to have loosely coupling dependencies? In systemd,
> we
> >have After=. After option will help the current service to start after the
> >mentioned service (in after). And the current service will anyway start
> >even if the mentioned service in After fails to start. Do we have such
> >loosely coupled dependency facility in S6?
>
> Not at the moment, no. The next version of s6-rc will allow more types
> of dependencies, with clearer semantics than the systemd ones (After=,
> Requires= and Wants= are not orthogonal, which is unintuitive and causes
> misuse); but it is still in early development.
>
> For now, s6-rc only provides one type of dependency, which is the
> equivalent of Requires+After. I realize this is not flexible enough
> for a lot of real use cases, which is one of the reasons why another
> version is in development. :)
>
>
> >3. Is there any tool available in S6 to measure the time taken by each
> >service to start? We can manually measure it from the logs, but still
> >looking for a tool which can provide accurate data.
>
> Honestly, if you use the -v2 option to your s6-rc invocation, as in
> s6-rc -v2 change top
> and you ask the catch-all logger to timestamp its lines (which should
> be the default, but you can change the timestamp style via the -t
> option to s6-linux-init-maker)
> then the difference of timestamps between the lines:
> s6-rc: info: service foo: starting
> and
> s6-rc: info: service foo successfully started
> will give you a pretty accurate measurement of the time it took service
> foo to start. These lines are written by s6-rc exactly as the
> "starting" or "completed" event occurs, and they are timestamped by
> s6-log immediately; the code path is the same for both events, so the
> delays cancel out, and the only inaccuracy left is randomness due to
> scheduling, which should not be statistically significant.
>
> At the moment, the s6-rc log is the easiest place to get this data
> from. You could probably hack something with the "time" shell command
> and s6-svwait, such as
> s6-svwait -u /run/service/foo ; time s6-svwait -U /run/service/foo
> which would give you the time it took for foo to become ready; but
> I doubt it would be any more accurate than using the timestamps in the
> s6-rc logs, and it's really not convenient to set up.
>
>
> >4. Does the S6 init system provide better boot up performance compared to
> >systemd ? One of our main motives is to attain better bootup performance.
> >Is our expectation correct?
>
> The boot up performance should be more or less *similar* to systemd.
> The code paths used by the s6 ecosystem are much shorter than the ones
> used by systemd, so _in theory_ you should get faster boots with s6.
>
> However, systemd cheats, by starting services before their dependencies
> are ready. For instance, it will start services before any kind of
> logging is ready, which is pretty dangerous for several reasons. As a
> part of its "socket activation" thing, it will also claim readiness
> on some sockets before even attempting to run the actual serving
> processes (which may fail, in which case readiness was a lie.)
> Because of that, when everything goes well, systemd cuts corners that
> s6 does not, and may gain some advantage.
>
> So all in all, I expect that depending on your system, the difference
> in speed will not be remarkable. On very simple setups (just a few
> services), systemd's overhead may be noticeable and you may see real
> improvements with s6. On complex setups with lots of dependencies, s6
> might still have the speed advantage but I don't think it will be
> anything amazing. The real benefit of s6 is that it achieves
> roughly the same speed as systemd *while being more reliable and
> predictable*.
>
> If you actually make bootup speed comparisons between systemd and s6,
> please share them! I am interested in that kind of benchmarks, and
> I'm sure the community would like to see numbers as well.
>
> --
> Laurent
>
>
Received on Wed Aug 11 2021 - 13:05:56 CEST