On Wed, 2006-04-05 at 07:17 -0700, Robert Hanson wrote: > greetings! > > it appeared to me that previous upgrades were strained by sheer amount and > size of the update as well as the eagerness of the CentOS userbase to get > upgraded... > Lance Davis created the mirrorlist choose script (that hands out mirrorlist info based on location) and a make mirrorlist script (that polls the mirrors and lists only valid and up2date mirrors for each repo) This update system did the trick, as it spread the load out among more than 100 servers that were geographically accurate vice 10-15 that are in an rrdns. Lance also got powerDNS working on our normal rrdns names so that even using an rrdns name, you should only get 1 IP that is geographically accurate. With both of these things going, the updates seem to go well on our end. > this last one, well... it went so smooth that i believe many may have missed > it happening so to speak :-) > > initially having been a large Galacticom aka Worldgroup BBS operator > (remember those?) and then an ISP for going on 2 decades i sincerely > appreciate the smoothness of the last batch of upgrades and the distribution > of such around the world... it appeared almost effortless from this side... > > > :-) > > CentOS team, great job! and keep up the awesome work! > > ummm, do you have any statistics to share that show how much data was moved > around and by how many internal servers and external clients? > Well, I don't have any stats from the external public mirrors as we don't control those, but they picked up a substantial amount of the load this time. I can tell you that we had 18% increase in requests for files above the October 4.2 upgrade cycle for this upgrade cycle ... but that our machines served only 67% of the TB that they served last update cycle. The external public mirrors handled all the other traffic. We did about 11.12 Terabytes of yum/up2date transfers for 4.2, we did 7.48 Terabytes for 4.3, but based on the requests, I project that 13.12 Terabytes were required to fill the up2date and yum requests for 4.3. This means that 5.64 Terabytes were served by the external mirrors. Those stats are up2date and yum updates only. > again, way to go! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060405/8e325652/attachment-0005.sig>