LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Scott Elder <[log in to unmask]>
Mon, 25 Feb 2008 13:46:35 -0600
text/plain (81 lines)
Very interesting.  Thank you for the helpful information!  I appreciate it.

Scott


On 2/25/08 12:15 PM, "Al Lilianstrom" <[log in to unmask]> wrote:

>> -----Original Message-----
>> From: LISTSERV site administrators' forum [mailto:LSTSRV-
>> [log in to unmask]] On Behalf Of Scott Elder
>> Sent: Tuesday, January 15, 2008 11:47 AM
>> To: [log in to unmask]
>> Subject: Re: Web interface 'slow'
>>
>> I'd appreciate being included in any responses to this.  We are
>> experiencing
>> the same problem.
>>
>> Thank you,
>> Scott
>>
>>
>> On 1/15/08 10:44 AM, "Al Lilianstrom" <[log in to unmask]> wrote:
>>
>>> Hi,
>>>
>>> We're running LISTSERV(R) for Windows version 14.5 on a Windows 2003
>> system.
>>> We're getting to the point where the web interface can be unusable
>> during part
>>> of the business day as it becomes very slow. We have ~3000 lists on
>> the box at
>>> this time. The physical server (single to dual proc and double the
>> RAM) and
>>> the storage (DAS to SAN - doubled the IO) that listserv uses have
>> been
>>> upgraded and we have seen improvements (at least till the number of
>> lists grew
>>> again).
>>>
>>> The server itself isn't running out of resources. Disk queues
>> occasionally get
>>> above 2 but average around .02 for both read and write. Disk read and
>> writes
>>> max out around 4 to 5 MB/sec but average much less. To me it seems
>> like a
>>> classic case of too many files to parse in the listserv\main
>> directory as
>>> being responsible for the slow response.
>>>
>>> Is there any listserv tuning that can be done? Any suggestions would
>> be
>>> appreciated.
>>>
>>>         al
>>> --
>
> It turns out the problem was too many files in the listserv\main directory.
> Not too many lists.
>
> We enabled content_filter a while back - moderating any message that our spam
> tagging system designated as spam. Most of the list owners were just ignoring
> the messages about approval so the .OK files were just hanging around. 29000
> of them. Moved those that were definitely for spam email out of the way and
> the web interface started acting a lot more like it should. Still a little
> slow but a huge improvement.
>
>         al
>
> --
>
> Al Lilianstrom
> CD/LSC/CSI/CSG
> [log in to unmask]
>

---
Scott Elder                      [log in to unmask]
IT-TSS Web Technologies
University of Houston             713-743-1518

ATOM RSS1 RSS2