I'm glad that the memory worked, but another trick we found was using http
instead of ftp.
Even if the ftp and http server are just as fast at getting a file to you, the
python getUrl code is very different, and with ftp takes quite a few more
interactions with the server.
That is the reason we switched the default yum-conf configurations from ftp to
http.
Troy
Killian De Volder wrote:
Thank you, that solved the issue !
(odly enough i check for swapping issues, but it didn't seem to use it, must
have
overlooked it)
On Mon, 21 Apr 2008, Killian De Volder wrote:
Hello,
Since a certain point in time (i'm afraid I do not recall what
triggered it),
yum is slow. Not slow as in ... lets wait, 5 or even 20 mins. But
longer...
I don't even know how long it takes ... that's how slow it is.
I'm not sure how I can begin to debug or resolve this issue ? Any
advise ?
(64mb ram, 23MB/Sec hdparm speed, yum version 2.4.3)
Try adding more memory!
At some point we discovered that the sl5 installations we were doing
just stalled on machines with < 768M ram. These are kickstart installs
where we were pointing at two repos:
the base sl50 repo (well our local mirror of it)
an additional repo containing *all* sl50 security updates plus our local
packages
At some point the total number of available packages causes the anaconda
(using the yum code!) to need rather more memory than was available.
(during install there is no swap and some memory is already taken by the
initrd and tmpfs stuff).
When we first started using this kickstart setup with sl50 384M was
enough (though pretty slow), and since little else has changed so I
assume that it is a problem with the number of available packages that
the yum code has to check.
Oddly enough the installer gets as far as starting the actual
installation but then after a few hundered packages gets 'stuck'.
Switching to a text VC shows that anaconda is swapping furiously and we
have loads of disk i/o but no useful progress.
A machine with ~512M ram installed at a time before there were so many
updates doesn't seem to have a big problem with doing yum updates but
that may simply be that it doesn't have so much memory stolen by initrd
etc.
We are about to globally update to sl51 which may help simply because
there are (currently) fewer security updates...
--
__________________________________________________
Troy Dawson [EMAIL PROTECTED] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________