fedup performance
Alex G.
mr.nuke.me at gmail.com
Wed Jul 3 08:29:49 UTC 2013
On 07/03/2013 03:23 AM, Panu Matilainen wrote:
> On 07/03/2013 09:59 AM, Panu Matilainen wrote:
>> On 07/03/2013 07:42 AM, Alex G. wrote:
>>> On 07/02/2013 08:28 PM, Neal Becker wrote:
>>>> Not d/l speed related. I just want to share. I update a very fast 8
>>>> core
>>>> server, with a conventional disk drive. Took 2-3 hours, not
>>>> including d/l.
>>>>
>>>> I update my laptop which has an ssd (and MORE packages). Took 10-15
>>>> minutes.
>>>>
>>> I think this might simply have to do with rpm running ldconfig (a very
>>> disk IO expensive operation) for a large number of packages. I'm not
>>> sure yum/rpm has deferred ldconfig processing.
>>>
>>> DISCLAIMER: I may be very wrong. Please don't quote me on this.
>>
>> ldconfig gets run a lot yes, but its also really fast these days.
>> fdatasync() which gets called even more (a lot more at that) seems like
>> a more likely painpoint on upgrades.
>
> Oh and here are some numbers for your entertainment. This is a 185 core
> package install to empty chroot on my laptop with a conventional disk,
> with the two worst script-offenders (kernel and selinux-policy-targeted
> have) taken out of the picture as they'd very much dominate the running
> time on a set this small:
>
> fdatasync, no scripts 1m16s
> fdatasync, scripts 1m29s
>
> no fdatasync, no scripts 16s
> no fdatasync, scripts 25s
>
> When fdatasync() is disabled (on initial install where there's no data
> to lose), sure all the scripts start taking a considerable portion of
> the running time. But for normal operation (such as upgrades),
> fdatasync() is where the vast majority of time gets spent.
>
> Of course on real-world upgrades there are many many more things at play
> than in the simple test-case above, but to improve performance you need
> to figure out where the time is getting spent, guessing gets you nowhere.
>
Guessing gets other people to research the matter. A great way to get
others to work for you for free. :p
Alex
> - Panu -
>
> - Panu -
>
More information about the devel
mailing list