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 >