[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About the broken jigdos and gluck's load



In article <[🔎] 20041014165844.GE31767@osuosl.org> kveton@oregonstate.edu writes:
[spohr.debian.org]
>> It's not usually desperately loaded, although occasionally a big spam
>> run can cause issues.

>spohr is hosted here at the OSL (http://osuosl.org) and if handling mail
>is an issue, we actually have mail relays here that you could off load
>that to to free up cycles for doing the CD images.  We're already doing
>this for several projects ('host -t mx' on mozilla.org, php.net and
>freenode.net).  We'd be more than willing to do this for you all ...
>obviously this would involve discussion but it might help.

The problem we have with spam on bugs.debian.org isn't accepting
incoming mail, it's in determinating if it is spam or not.  Additional
MX servers would not help.  With the current software, scanning for
spam doesn't put much load on the machine, but the latency of using
external DNSBLs (as part of the spamassassin scoring) was killing
throughput.  I've looked into rewriting it to be multi-threading.

Every time I've seen spohr with a high (for it -- as high as 3.5 on a
dual hyperthreading system) load, it was due to rsync and/or web
server processes.  The latter may be partly due to spammers scanning
the BTS for email addresses.

>The other thing we need to do is move spohr to our new network segment
>here which essentially has all-you-can-eat Internet2 connectivity which
>would help in disseminating ISO's out to secondary mirrors.

Thank you for hosting spohr, you have been doing an excelent job as
far as I can tell.  I joined the BTS team after it became
bugs.debian.org, so I can't compare to previous hosting.  (I think
most of the issues before I joined the BTS were due to CPU and disk
space issues.)
-- 
Blars Blarson			blarson@blars.org
				http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.



Reply to: