Seth Vidal wrote: > 3.2.23 is showing 3.186s for a yum list updates on my system > > 3.2.21 is shwoing 3.339s for the same. # time yum list updates Loaded plugins: downloadonly Updated Packages [snipped list with 70-80 package] real 1m28.537s user 1m23.830s sys 0m0.536s # rpm -Uhv --oldpackage yum-3.2.21-2.fc10.noarch.rpm Preparing... ########################################### [100%] 1:yum ########################################### [100%] [root@thinkpad etc]# time yum list updates Loaded plugins: downloadonly Updated Packages [snipped list with 70-80 package] real 0m7.296s user 0m6.549s sys 0m0.324s This is my yum.conf, where I justr added the last line, as you suggested. [main] cachedir=/var/cache/yum keepcache=0 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 installonly_limit=3 It is really CPU intensive. I see some unicode related stuff in the changelog and my memory goes to years ago (RedHat 8?) when the UTF8 enabled grep got a similar slowdown (the lib was then improved after that). Hmmmmm, made other experiments.... Really weird. #time yum list updates --disablerepo=\* --enablerepo=ROB10\* (less than 3 seconds) #time yum list updates --disablerepo=\* --enablerepo=updates (less than 3 seconds) #time yum list updates --disablerepo=\* --enablerepo=ROB10\* --enablerepo=updates (more than one minute) ROB10\* is some local repositories, containing mirrored stuff from some repositories, _including fedora_updates_, so the same rpms are found in two different repositories. How can this trigger such a slowdown, I don't know. I have to correct what I said before, the time is not always spent on read64() and gettimeofday(); there is a lot of strace-silent activity (just spurious brk() calls). Maybe something like hashing of some data structure is taking a really bad direction? -- Roberto Ragusa mail at robertoragusa.it -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
