On Tue, 22.04.14 10:44, Thomas Woerner (twoerner@xxxxxxxxxx) wrote: > >>firewalld is not the "number 1 slowest component on Fedora, right now.", but > >>it is plymouth-quit-wait. > > > >No it just waits for other services to finish (as you have seen it > >went down without firewalld). > > > Yes, but all others increased. Therefore the question: Why are other > services taking longer to start if firewalld is not started and not > installed anymore? Without firewalld the other services in the > system should start in the same time as before with firewalld > installed and started. Otherwise the calculation is just some number > and only partly related to the started service itself. > > Lennart, I think you should be able to explain this discrepancy. systemd-analyze will tell you the raw numbers how long a service needs to start. It can provide you with an indication what is going on, but you have to read it with a grain of salt, since it will always include times a service just waits for another service and doesn't actually consume CPU nor IO. Moreover, the buffer cache is a major source of noise here, since earlier services pay a greater penalty for IO accesses than later services. The readahead logic adds even more noise. Ultimately this means: it's a system where performance behaviour of services influence each other even if they don't directly communicate. To make the data more reliable, you'd could drop the read-ahead caches, disable excatly one service of the boot, then boot 2 times and measure the resulting total boot speed over a number of subsequent boots. Then, reenable that one service, and disable another one, repeat... This will tell you how much every service actually contributes to the boot time, while staying close to the full system where all services are enabled. The data systemd-analyze is hence merely a trend. It indicates that firewalld is the worst offender, and given the margin I am pretty sure this will also be the case if you do the more accurate testing suggested above. Lennart -- Lennart Poettering, Red Hat -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
