On 6/2/20 8:31 AM, drago01 wrote:
On Tuesday, June 2, 2020, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx
<mailto:adamwill@xxxxxxxxxxxxxxxxx>> wrote:
On June 1, 2020 7:13:51 p.m. PDT, Richard Shaw <hobbes1069@xxxxxxxxx
<mailto: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.
Well, it's a guess.
Just tested the particular case of boost-devel install with plain rpm on
all of sqlite, bdb and ndb, and of the three, bdb is the slowest one.
The tested, expected behavior of sqlite is as fast or faster than bdb,
but of course it's *possible* previously unknown worst-case behaviors exist.
Lets start with the basics:
- is sqlite even involved - it will only be used on rawhide builds if
mock bootstrap is used
- does it make a difference if you override _db_backend to bdb/sqlite
from mock config / cli define
- a reproducer please (eg, what package is considerably slower to build
than before, and by how much)
- Panu -
_______________________________________________
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
