Subject: | |
From: | |
Reply To: | |
Date: | Mon, 21 Apr 2008 13:23:02 +0200 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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...
>
|
|
|