[ATrpms-users] atrpms.net blocking?

[Axel Thimm]

Thanks for the suggestion, I'll try filtering out TIME_WAIT.

But that's a bug in yum, as it is supposed to reuse connections. Are
you perhaps using an ancient version of yum?

Blocking is neccessary, as otherwise this leads to oom conditions and
crashes of the server. The IP separation of web and dl wasn't possible
until now (low on IP space), but I now have a larger IP space where
ATrpms will migrate to.

On Fri, May 05, 2006 at 02:17:19PM +0200, ds3 at destruction.dystopic.org wrote:
> 
> Hi Axel,
> 
> First, I want to say thankyou for the _great_ work on the atrpms 
> repository! :)
> 
> Second, I've recently had horrific problems reaching atrpms.net; at first 
> I thought the site was down, but eventually I found some mailinglist 
> archives on the mythtv list that suggested the site reacts to (and 
> blocks) multiple concurrent requests.
> 
> If you're still using a script similar (based on netstat -pan output) to 
> what i found on the mailinglists from 2005, this will interact very badly 
> with, for example, yum (if you're not, well, then this mail might be 
> completely irrelevant :).
> 
> After finally figuring out this might be the problem (as both the webpages 
> with bugzilla and mailinglists as well as the repo becomes unavailable, 
> tracing the problem was quite... frustrating. searching mailing lists on 
> googles cache is painful), I set up my own local mirror to do a controlled 
> test, and got output like this:
> 
> (on client)
> yum update
> 
> (on webserver)
> while (true); do netstat -pan | grep :80 | wc -l; sleep 1; done
> 
> 2
> 3
> 4
> 6
> 7
> .
> . all the way up to... 
> .
> 45
> 47
> 
> As far as I can tell, yum opens a connection for each file it pulls, 
> however, they're not concurrent connections, the sockets are in TIME_WAIT 
> which means the socket is closed and just waiting for any stray trailing 
> packets before finalizing the close. Now, when you're running a yum 
> update and yum starts pulling a bazillion small header files, you'll get 
> a whole bunch of those TIME_WAIT sockets lying around because yum is 
> simply opening and closing connections faster than the timer runs out for 
> the close, but by themselves they should take negligable resources (and 
> you should be able to tune the timer down if you want to get rid of them 
> faster, lowering /proc/sys/net/ipv4/tcp_fin_timeout from default 60 
> seconds should do the trick)
> 
> For a better working blocking script, you might want to filter out the 
> TIME_WAIT sockets.
> 
> Various other ramblings; while searching around the site for an 
> explanation to what had happened when I thought it had been down I ran 
> across some bugzilla page and pressed some 'generate report' link in 
> hopes of finding some recent bug activity. I got a creeping suspicion 
> that this might not necessarily have been a good thing; the entire site 
> became quite unresponsive at once. It might have been a coincidence, 
> but...
> 
> For other rambling suggestions which might not really be productive, but 
> anyways; if at all possible, I'd suggest separating the website and 
> repository, at the very least to different IP adresses so you can block 
> just the repository, and make a note about the risk of certain clients 
> triggering the block and suggest pointing them at mirrors.
> 
> Anyways, best regards, hope that helps, and thankyou again.
> David Sundqvist

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20060505/7b51a2e9/attachment.bin