On Wed, 18 Jan 2006, Troy Dawson wrote:

> Jaroslaw Polok wrote:
> > Randy Merritt wrote:
> > 
> >>  /etc/cron.daily/yum.cron:
> >>
> >> Yum crontab starting
> >>   Sleeping for 153 minutes
> >>   No other yum process running.
> >> ********** Starting ***** errata ***** STARTING ********
> >>    Creating Config File
> >> *********START** errata YUM.CONF FILE **START**********
> >> .  .  .
> >>
> >> Can someone illuminate why yum.cron (or cron itself?) is sleeping for 
> >> 153 minutes?
> > 
> > 
> > In order not to kill servers serving you updates yum cron job
> > sleeps for a random time (not longer than 180 minutes - see
> > /etc/cron.daily/yum.cron):
> > 
> > If every  SL user would update at the same time ...
> > Connie would have to have a real http serving farm at 
> > scientificlinux.org ;-)
> > 
> > Cheers
> > 
> > Jarek
> 
> Exactly.
> I don't know if you've seen the stat's, but there are currently 12,000 

See the following data

https://www.scientificlinux.org/about/stats/2005/high.detail

These numbers are "unique" ip addresses.

-Connie Sieh

> machines doing their updates from us.  Currently, by using this delay, 
> and the fact that they are distributed around the world, the load on the 
> machine is fairly consistant.
> 
> (side note: we are working on a program to identify 'clusters' of 
> machines.  If you have several machines getting their updates from us, 
> we encourage people to mirror us and point their yum at their mirror. 
> This saves our bandwidth, as well as gives you faster responses.)
> 
> If everyone took the randomizing out of their cron job's, we'd see huge 
> spikes of traffic each hour, and then this e-mail wouldn't be about long 
> sleeps, it would be about long lags when doing updates.
> 
> At Fermilab we have our own servers we point our yum at (so we arn't 
> hitting the main server) and it is usually quite obvious when even a 
> cluster of 100 machines takes that randomizing out.
> 
> Troy
>