Subject: | |
From: | |
Reply To: | |
Date: | Wed, 16 Nov 2005 15:26:46 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On 11/16/2005 14:12, Eric Thomas wrote:
> I think we have an assumption in this thread that the X-SPAM jobs are the
> cause of Paul's problems, and that Paul is forced to accept poor web
> response as a result of this legacy spam prevention function. Based on my
> knowledge of the code, I would challenge this assumption. Just because there
> are a lot of X-SPAM jobs doesn't necessarily mean that they tie up LISTSERV.
> There is an easy wait to find out: simply add DEBUG_TIME_ALL=1 to your
> configuration. This will make LISTSERV log execution timing for every
> command it processes. There is *some* overhead outside of what is captured
> by DEBUG_TIME_ALL=1, but it is not very much. I went looking for a really
> old backbone site where I have administrator access, and the oldest I could
> find was a 733MHz Intel server, where I get the following timings:
I will add this to our go.user file, however, with 32,000+ lists, LISTSERV
initialization takes approximately 75 minutes, so I will need to schedule
an outage to restart the service.
> As for jobs having priority over interactive requests, this is definitely
> not the way it is meant to be. If indeed this is what is happening at ND, it
> is a bug and needs to be fixed.
This has been an ongoing problem for some time, and I am virtually certain
that the LSTSRV-L archives contain similar reports from at least one other
site.
--
Paul Russell
Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
|
|
|