Bug 892064

Summary:	hourly dnf makecache too frequent, also consider using ionice
Product:	[Fedora] Fedora	Reporter:	Hin-Tak Leung <htl10>
Component:	dnf	Assignee:	Ales Kozumplik <akozumpl>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	akozumpl, jzeleny
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	dnf-0.3.1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-03-26 13:23:00 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Hin-Tak Leung 2013-01-05 02:45:03 UTC

Description of problem:
hourly dnf makecache too frequent, and quite noticeable when it kicks in. I have multiple repos configured, rpmfusions-*, adobe (acrobat reader), google-chrome, texlive (the experimental texlive 2012 updates for f17, which I just disabled now f18 provides it), cert, etc. So one of them always expires every so often. I see that the longest period is about 5 hours but it seems to kick in every hour.

also please consider using ionice for the cron job, just like updatedb, and others. (and they don't run every hour!).

Version-Release number of selected component (if applicable):
# rpm -q dnf
dnf-0.2.17-1.git6a055e6.fc18.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ales Kozumplik 2013-01-07 07:55:59 UTC

Hello, thanks for the report, I didn't know people were noticing this so much.

Related: bug 878826.

Comment 2 Hin-Tak Leung 2013-01-08 01:07:23 UTC

As I wrote, it kicks in almost every hour according to /var/log/dnf.log, since different repositories expire at different times. Also, do these entries mean it is downloading the whole metainfo every hour?!

-------------
Jan 06 05:15:54 not found deltainfo for: Adobe Systems Incorporated
Jan 06 05:15:56 not found deltainfo for: google-chrome
Jan 06 05:15:57 not found deltainfo for: RPM Fusion for Fedora 18 - Free
Jan 06 05:15:57 not found deltainfo for: RPM Fusion for Fedora 18 - Free - Updates
Jan 06 05:15:57 not found deltainfo for: RPM Fusion for Fedora 18 - Nonfree
Jan 06 05:15:57 not found deltainfo for: RPM Fusion for Fedora 18 - Nonfree - Updates
Jan 06 05:15:57 not found deltainfo for: Fedora 18 - x86_64 - Updates
------------

Anyway, you notice your hard disk is churning for a few minutes (and every hour!) if you sit in front of it just doing some light reading/editing.

Comment 3 Ales Kozumplik 2013-01-08 09:08:06 UTC

No, it just means it tried to contact the server about still missing metadata (deltainfo in this case) and found out it's still missing there.

Comment 4 Ales Kozumplik 2013-01-17 15:05:12 UTC

Bug 896572 asks for NetworkManager feature that would let DNF (and other progrmas) distinguish if given network connection is expensive.

Comment 5 Ales Kozumplik 2013-03-26 13:15:42 UTC

bug 878826 is resolved now, dnf-0.3.1 and later runs the regular makecache through a systemd timer with the following options:

Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

So, it is 'niced down' and should help in the reported scenario.

Comment 6 Ales Kozumplik 2013-03-26 13:23:00 UTC

Commit 07e0b68 deals with the default refresh frequency. Starting with dnf-0.3.1, the makecache will only perform the metadata check and resynchronization every three hours by default. This can be further tweaked with the metadata_timer_sync config option.