[mirror-admin] Slow syncing?

[Will Foster]

On 30/12/09 11:55 -0600, Chris Adams wrote:
>Once upon a time, Mike McGrath <mmcgrath at redhat.com> said:
>> On Tue, 29 Dec 2009, Rob van Nieuwkerk wrote:
>> 
>> > On Mon, 28 Dec 2009 21:46:30 -0600
>> > Chris Adams <cmadams at hiwaay.net> wrote:
>> >
>> > > Is anyone else seeing slow syncing recently?  I just noticed that I have
>> > > an rsync job for fedora-enchilada that started over 7 hours ago;
>> > > checking my bandwidth graphs, it appears to be puttering along at maybe
>> > > 2 megabits per second.  I see that a number of my jobs over the last few
>> > > days have taken many hours to complete.
>> >
>> > Hi Chris,
>> >
>> > I see the same here: its about 3-4 times slower than it used to be.
>> 
>> can you guys pinpoint exactly when that started?
>
>It looks like more than 7 days ago (which is all I keep my rsync
>reports).  Sorry I can't be more specific.
>
>Also, I get a bunch of "@ERROR: max connections (9) reached -- try again
>later" messages, which I assume is because others are taking longer to
>sync as well.
>-- 
>Chris Adams <cmadams at hiwaay.net>
>Systems and Network Administrator - HiWAAY Internet Services
>I don't speak for anybody but myself - that's enough trouble.
>
>--

Hi Chris,

The (9) slot connection limit per node was put in place several months ago to curb heavy I/O usage during filelist builds, since we only have 4 nodes instead of 5 we can revisit bumping up the limit if it becomes a hindrance.

I've done some tests internally/externally and I see around 3 to 4 megabits/second from PHX2 to a private host in St. Louis.  Internally I see around the same speeds to RDU and normal gigabit traffic inside PHX2.

On the storage end I see nothing out of the ordinary (Netapp disk utilization hovers around 6-8%) and the download nodes are not under significant load or I/O.

Please keep in mind that the physical location of the download services have changed recently (12-19-09) as part of our datacenter migration project so these are not the same links you are used to.  I cannot comment on the speed expectations or capacity but we will engage Networking to get more specifics on that to see that we are achieving our throughput expectations.

-- 
Will Foster
IT Operations
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.ale.org/pipermail/mirror-admin/attachments/20091230/1f004e73/attachment.bin 
-------------- next part --------------
--