Starting the service at boot remains slow

[LinuxOnTheDesktop]

I appreciate ananicy very much. I appreciate too that the developer has made efforts to speed up how fast is starts. However, on my - fast - system, it still takes between 1.5 and 3 seconds to start. I'd like to see that lower.

I have some 30 custom rules.

My system details are as follows.

OS: Linux Mint 19.1 Tessa x86_64
Host: 20KHCTO1WW ThinkPad X1 Carbon 6th
Kernel: 5.1.14-050114-generic
Uptime: 3 mins
Packages: 3169 (dpkg), 5 (snap)
Shell: bash 4.4.19
Resolution: 2560x1440 @ 60.01Hz
DE: Cinnamon 4.2.0
WM: Mutter (Muffin)
CPU: Intel i7-8550U (8) @ 4.000GHz
GPU: Intel UHD Graphics 620
Memory: 2089MiB / 15928MiB
Disk (/dev/nvme0n1p4): 14G / 40G (38%)
Disk (/dev/nvme0n1p2): 150G / 405G (39%)
Disk (udev): 0 / 7.8G (0%)

Ananicy version: I'm having trouble determining this, but just now I reinstalled ananicy from the git.

Admittedly I think my CPU might be thermal throttling on some boots.

EDIT: cf. #142?

[LinuxOnTheDesktop]

I'm seeing the following (in the syslog) too, if it is relevant.

ananicy.service: Consumed 5min 29.723s CPU time

[Timofey Titovets]

@LinuxOnTheDesktop,

~ systemd-analyze critical-chain
graphical.target @4.755s
└─upower.service @2.302s +2.450s
  └─basic.target @2.242s
    └─dbus-broker.service @1.834s +401ms
      └─dbus.socket @1.832s
        └─sysinit.target @1.832s
          └─systemd-timesyncd.service @1.262s +567ms
            └─systemd-tmpfiles-setup.service @1.106s +153ms
              └─systemd-journal-flush.service @567ms +536ms
                └─systemd-journald.service @357ms +202ms
                  └─systemd-journald-dev-log.socket
                    └─-.mount
                      └─system.slice
                        └─-.slice

If ananicy slowdown something you will see it here

[LinuxOnTheDesktop]

Thanks. I get this:

systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @32.080s
└─multi-user.target @32.080s
  └─vboxautostart-service.service @32.070s +9ms
    └─vboxdrv.service @12.907s +19.162s
      └─basic.target @12.775s
        └─sockets.target @12.773s
          └─snapd.socket @12.767s +3ms
            └─sysinit.target @12.740s
              └─haveged.service @12.738s
                └─apparmor.service @10.805s +1.930s
                  └─local-fs.target @10.783s
                    └─home.mount @10.684s +97ms
                      └─systemd-fsck@dev-disk-by\x2duuid-18b9ad28\x2dd429\x2d4f42\x2dbefd\x2d8619f5fd92b
                        └─dev-disk-by\x2duuid-18b9ad28\x2dd429\x2d4f42\x2dbefd\x2d8619f5fd92bc.device @1
lines 1-17/17 (END)

But I also get this (which is what prompted my report):

systemd-analyze blame
         19.162s vboxdrv.service
          9.655s dev-nvme0n1p4.device
          8.625s NetworkManager-wait-online.service
          3.711s tlp.service
          3.291s ananicy.service
          [. . .]

[xuiqzy]

@nefelim4ag The CPU usage of processes in a service can also make other services slower to start even without showing up in the critical chain, since there is also another slower (possibly slowed down) service which has to be finished to go on with the boot.
@LinuxOnTheDesktop A way to test if there is an impact would be to measure boot times a few times and compare with the service disabled.
One could also measure the cpu time consumed by the service.

[LinuxOnTheDesktop]

@xuiqzy

Thanks. I have found that according to systemd-analyze blame, the ananicy service takes between < 1 second and over 10 seconds at boot. Strange! Also - and partly, but seemingly only partly, because of that - my boot time, with ananicy enabled, varies from 27 seconds to approximately 50.

[LinuxOnTheDesktop]

I've booted twice now with ananicy disabled. (Well, three times, but one time I'd installed a new kernel, which lengthened the boot). One boot took 28 seconds, the other 30. But what matters seem to come down to is: sometimes - but only sometimes - ananicy (when enabled) holds up my boot for ten seconds.