[Top] [All Lists]

Re: Distributor slows to an imperceptable crawl (weekly or so)

Subject: Re: Distributor slows to an imperceptable crawl weekly or so
From: Joe Webb
Date: Fri, 27 Jan 2006 08:58:50 -0600
Newsgroups: microsoft.public.sqlserver.notificationsvcs
David - 

That's for posting the follow up on how you appear to have resolved
the issue. I agree, SQLNS is a great product, but sometimes diagnosing
and resolving performance related issues are quite challenging. 

I'd love to hear more about the ways in which you're using SQLNS. You
can email me off line if you'd like (and are free to discuss). 


Joe Webb
SQL Server MVP

Get up to speed quickly with SQLNS 

I support PASS, the Professional Association for SQL Server.

On 27 Jan 2006 06:42:42 -0800, "David" <[email protected]> wrote:

>We're running 2 8-way boxes.  The instance is running on one.  SQL
>server on the other.
>While we were at one time very very very far behind on vacuuming, we
>are now caught up and it runs pretty quickly.
>The slowdown went on for 8 or more hours and no increase in load
>corresponded to this period of time.
>Based on other threads on this group,  we realized that we were
>accepting the defaults for Distributor Thread Count and
>Work Item Timeout.
>Following an increase of both,  the slow down ended.
>While I can see the intuitive connection between increasing the
>avaialble threads from 3 to 20 and an increase in speed,
>I never saw anything in the sql profiler or diagnostic sp's that said
>what was wrong.  I basically amounted to
>"I'm doing nothing very fast and I'm not going to tell anyone why."
>I do not wish to be critical of NS.  It serves as the back-bone of a
>big chunk of our business with a growing number of big customers.
>It does a lot of things very well that I certainly would not want to
>have to re-invent, but it sure does have its mysteries and the secrets
>it keeps tend to make my development team and company look bad from
>time to time (usually by Thursday ;-) )
>We've turned this thing upside down and shaken it every way we can
>think.  For the moment the aforementioned config changes APPEAR
>to have remedied the problem, but I don't I'm not going to bet the
>house on it.

<Prev in Thread] Current Thread [Next in Thread>