Re: Has something changed with RPMS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tuesday, June 2, 2020, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On June 1, 2020 7:13:51 p.m. PDT, Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
>I've noticed lately when doing mock builds that it takes a lot longer
>to
>install all the dependencies. Especially large -devel packages with
>tons of
>small files (boost-devel, vtk-devel, cmake-data).
>
>Checking on my NVME 970 EVO, all the stats look good:
>SMART/Health Information (NVMe Log 0x02)
>Critical Warning:                   0x00
>Temperature:                        60 Celsius
>Available Spare:                    98%
>Available Spare Threshold:          10%
>Percentage Used:                    0%
>Data Units Read:                    5,144,488 [2.63 TB]
>Data Units Written:                 16,635,882 [8.51 TB]
>Host Read Commands:                 138,600,710
>Host Write Commands:                223,768,039
>Controller Busy Time:               1,133
>Power Cycles:                       56
>Power On Hours:                     2,658
>Unsafe Shutdowns:                   36
>Media and Data Integrity Errors:    2
>Error Information Log Entries:      25
>Warning  Comp. Temperature Time:    0
>Critical Comp. Temperature Time:    0
>Temperature Sensor 1:               60 Celsius
>Temperature Sensor 2:               83 Celsius
>
>I run the fstrim service weekly...
>
>Ideas?
>
>Thanks,
>Richard

I've noticed the same problem but I'm not sure it's about the packages. It may be something to do with mock or the kernel, possibly. Are you running Rawhide on the machine where you're doing the mock builds?

I most recently noticed it when building lives with Python 3.9 for testing - that should take less than an hour per image, it actually took 12+ hours per image. When I attach an strace to the dnf process it seems like it doesn't really stick on any one call for a *long* time, but it seems to do a lot of fsyncs, and each one takes, like, a half second or so. I *think* the slowness is the result of all those fsyncs piling up.

I've tried installing nosync (both i686 and x86-64) on the host but it didn't seem to make a difference, I didn't check for sure that it actually kicked in. I'll try and do a bit more of a systematic look at it tomorrow, since at least now I know I'm not the only one...


Educated guess: it's the sqlite rpm db change.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux