--===============5436227139496708681== Content-Type: multipart/alternative; boundary="000000000000204df305a713393a" --000000000000204df305a713393a Content-Type: text/plain; charset="UTF-8" On Tuesday, June 2, 2020, Adam Williamson wrote: > On June 1, 2020 7:13:51 p.m. PDT, Richard Shaw > 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. --000000000000204df305a713393a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tuesday, June 2, 2020, Adam Williamson <adamwill@fedoraproject.org> wrote:
On June 1, 2020 7:13:51 p.m. PDT, Richard Shaw &l= t;hobbes1069@gmail.com> wrot= e:
>I've noticed lately when doing mock builds that it takes a lot long= er
>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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A00x00
>Temperature:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 60 Celsius
>Available Spare:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 98%
>Available Spare Threshold:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10%
>Percentage Used:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 0%
>Data Units Read:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 5,144,488 [2.63 TB]
>Data Units Written:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A016,635,882 [8.51 TB]
>Host Read Commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0138,600,710
>Host Write Commands:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 223,768,039
>Controller Busy Time:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01,133
>Power Cycles:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A056
>Power On Hours:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02,658
>Unsafe Shutdowns:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A036
>Media and Data Integrity Errors:=C2=A0 =C2=A0 2
>Error Information Log Entries:=C2=A0 =C2=A0 =C2=A0 25
>Warning=C2=A0 Comp. Temperature Time:=C2=A0 =C2=A0 0
>Critical Comp. Temperature Time:=C2=A0 =C2=A0 0
>Temperature Sensor 1:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A060 Celsius
>Temperature Sensor 2:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A083 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 p= ackages. It may be something to do with mock or the kernel, possibly. Are y= ou 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 does= n'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* t= he 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 a= ctually kicked in. I'll try and do a bit more of a systematic look at i= t tomorrow, since at least now I know I'm not the only one...


Educated guess: it's the sqlite rpm db= change.
--000000000000204df305a713393a-- --===============5436227139496708681== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFp bGluZyBsaXN0IC0tIGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnClRvIHVuc3Vic2NyaWJl IHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVk b3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVT L3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3Jh cHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBo dHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3JnL2FyY2hpdmVzL2xpc3QvZGV2ZWxAbGlzdHMu ZmVkb3JhcHJvamVjdC5vcmcK --===============5436227139496708681==--