In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
