On 06/15/2014 12:50 PM, Kai Krakow wrote: > Goffredo Baroncelli <kreij...@libero.it> schrieb: > >>>> I have enabled all the services (collect, replay, done), but I was >>>> unable to see any gain. >>> >>> I don't think you can actually enable the "done" service because it is >>> static... But if it placed a symlink in /etc/systemd that is probably >>> wrong and you should undo it. It is automatically activated a few seconds >>> after booting is done to store the collected data for replaying on next >>> reboot. >> >> I checked the output of systemd-analyze: systemd-readahead-done is called >> at the end of the chart. The sym-links exist only for the collect and >> replay services, which were called at the beginning. > > Then all is good. > >>>> I don't know why but system.journal is not considered by readahead: >>>> >>>> # /usr/lib/systemd/systemd-readahead analyze | grep journal >>>> >>>> >>>> 100% ( 1) 770: /etc/systemd/journald.conf >>>> 50% ( 1) 4194304: >>>> /var/log/journal/36f10f5379ec4a1398ac303a0ce20fd0/user-997.journal >>>> 50% ( 1) 4194304: >>>> /var/log/journal/36f10f5379ec4a1398ac303a0ce20fd0/user-1000.journal >>> >>> I tried that on my system and it looks vice-versa somehow: >>> >>> $ sudo /usr/lib/systemd/systemd-readahead analyze|fgrep journal >>> 100% ( 1) 812: /etc/systemd/journald.conf >>> 100% ( 1) 8388608: >>> /var/log/journal/121b87ca633e8ac0016656680000001b/system.journal >>> >>> Strange... ;-) >> >> May be this is a reason of my degraded performance. However I tried on two >> machines (all fedora) and after several reboot; I tried also removing the >> /.readahead file... Nothing. > > I'm not sure but generally it is said that readahead utilities may need a > few reboots before fully working. Did you try that? Will it take the journal > into account then?
I hope that today I will publish my results. Anyway I performed about 50-70 reboot on each configuration. > > Maybe there is something special about your setup and your system.journal > does not become touched during boot because of this? You said you also use > rsyslogd. Maybe logs are redirected there instead of written to both logging > mechanisms? Maybe most logging by system daemons is turned off or they write > directly to log files? > > I tuned all my daemons and services to not write to any log files at all, > instead log everything to stderr/stdout (which is captured by systemd) or > into the syslogger which is journald as the only mechanism in my system. I > just prefer to have everything in one place, and journalctl is a great way > to filter the logs or create custom views. Maybe that's a reason why it is > taken into account by readahead on my system? I can only guess but maybe > worth a try for you... I don't have any idea... definitely I will investigate a bit. > >>> To get back to your performance problem: Did you try "systemctl enable >>> bootchart" and then (after a reboot) look at the png generated in >>> /run/log (at least in my system it is placed there, look at the configs >>> if in doubt). It can give some interesting clues about why a service >>> starts late or takes long to execute. >> Unfortunately bootchart doesn't work on fedora, because CONFIG_SCHEDSTATS >> is not enabled in the kernel. > > Well, I'm on Gentoo so my kernel is custom built by design. But I checked my > config, I even have no config option "CONFIG_SCHEDSTATS" but bootchart works > for me: I am talking about systemd-bootchart. I have to look if Fedora has the classic bootchart. > > $ zfgrep SCHED /proc/config.gz > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y > CONFIG_CGROUP_SCHED=y > CONFIG_FAIR_GROUP_SCHED=y > CONFIG_RT_GROUP_SCHED=y > CONFIG_SCHED_AUTOGROUP=y > CONFIG_IOSCHED_NOOP=y > CONFIG_IOSCHED_DEADLINE=y > CONFIG_IOSCHED_CFQ=y > CONFIG_CFQ_GROUP_IOSCHED=y > CONFIG_IOSCHED_BFQ=y > CONFIG_DEFAULT_IOSCHED="deadline" > CONFIG_SCHED_OMIT_FRAME_POINTER=y > CONFIG_SCHED_SMT=y > CONFIG_SCHED_MC=y > CONFIG_SCHED_HRTICK=y > # CONFIG_NET_SCHED is not set > CONFIG_USB_EHCI_TT_NEWSCHED=y > > BTW: After migrating to systemd, I had a boot time of 15s to DM on > rotational with serveral heavy services enabled. I did not measure time to > desktop back then. But after I did a btrfs balance (I use multidevice > btrfs), the time to DM went up to around 25s and never went back no matter > what I tried (even when I disabled some services). I switched to autologin > DM since then so at least systemd-readahead catches some of the KDE > services, too, now. But it still feels slow. I'm probably redoing my btrfs > in the future, switching to 16k leaf size in that process. But I'll wait > with that until I migrate to bigger hard disks. Currently I have still > plenty of space left. According to bootchart I never had a problem with time > spent processing the journal. But since a few kernel versions, auto-suspend > works great for me, so I usually do not switch the system off, just leave it > running and it suspends to RAM after 2 hours. As a nice side effect, it > wakes up instantly (especially since kernel 3.15), and I save a lot of > power. Still waiting for the systemd auto-wakeup facility to run timer jobs > like a backup. ;-) If readahead is able to defrag too, and if it handles also the journal file, your data seems reasonable. > -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
