On Jun 26, 2009, at 10:03 AM, Seth Vidal wrote:
On Fri, 26 Jun 2009, Roberto Ragusa wrote:
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?
run:
time yum -d 3 --disablerepo=\* --enablerepo=ROB10\* \
--enablerepo=updates list updates | grep 'time:'
and post that output.
I disabled all repos and individually enabled one repo at a time. Each
individual repo performance was excellent (couple of seconds). When I
included two repos, I start to see the problem. local-mirror-updates
is a a low cost (500) local rsync mirror on a GbE network.
[root@fast ~]# time yum -d 3 --disablerepo=\* --enablerepo=local-
mirror-updates --enablerepo=updates list updates | grep 'time:'
Config time: 0.040
repo time: 0.000
pkgsack time: 39.956
rpmdb time: 0.002
up:Obs Init time: 0.054
up:simple updates time: 0.047
up:obs time: 0.002
up:condense time: 0.000
updates time: 0.388
real 0m40.547s
user 0m40.253s
sys 0m0.195s
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
