Hi David -
You've probably already checked this, but is the vacuumer running
during the slow downs?
What kind of deployment do you have? Single server? Remote database?
Or Scale out (where the distributor may be sitting on a different box
entirely)?
Have you monitored the load on the SQL Server box during the slowdown
to see if it's the bottleneck?
Anything else running on the server that the distributor is on that
could be eating up resources?
Is the slowdown very repeatable - same day of week, same time of day?
HTH...
Joe
--
Joe Webb
SQL Server MVP
http://www.sqlns.com ~~~
Get up to speed quickly with SQLNS
http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 I support PASS, the Professional Association for SQL Server.
(
www.sqlpass.org)
[quoted text, click to view] On 26 Jan 2006 13:21:03 -0800, "David" <david@vandevate.com> wrote:
>We have a notification services installation that stops performing (or
>slows to an imperceptable crawl) almost weekly.
>
>This week, the Distributor stops (or crawls at) generating work items.
>We are getting plenty of seemingly valid notifications, but no work
>items are assigned
>We're hours behind now.
>
>NSCreateDistributorWorkitems is running as defined in the config (3
>seconds).
>
>Only about 1 of 10 times run does it pick up a batch although there are
>over 1000 batches in the generated state waiting to be distributed.
>
>We're currently running with the default 3 threads in Enterprise
>Edition.
>(We're in the process of increasing it).
>
>We do have unused delivery channels (noted other thread indicating this
>could be a problem).
>
>We're pretty indepth NS users. We need some good indepth guidance as
>to what can make the distributor behave so.
>
>Thanks in advance,
>
Joe:
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.
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).
Cheers!
--
Joe Webb
SQL Server MVP
http://www.sqlns.com ~~~
Get up to speed quickly with SQLNS
http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 I support PASS, the Professional Association for SQL Server.
(
www.sqlpass.org)
[quoted text, click to view] On 27 Jan 2006 06:42:42 -0800, "David" <david@vandevate.com> wrote:
>Joe:
>
>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
Don't see what you're looking for? Try a search.
