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  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________