Hi everyone,
I need to know what is the relationship between the "Maxium Number of Worker Threads" setting (default = 255) and user connections/sessions/logins.
From time to time, we are experiencing random login failure for several busy databases. On average, we see about 264 total sessions on the box and we were wondering if the max worker threads number, bumping it up would fix the issue.
Can anyone offer any suggestions?
Thanks in advance,
Errol Neal
As long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)
"Errol U. Neal" <eneal@.enhtech.com> wrote in message
news:09B0F39B-1468-4069-A8A1-BF2AF2E645C8@.microsoft.com...
> Hi everyone,
> I need to know what is the relationship between the "Maxium Number of
Worker Threads" setting (default = 255) and user
connections/sessions/logins.
> From time to time, we are experiencing random login failure for several
busy databases. On average, we see about 264 total sessions on the box and
we were wondering if the max worker threads number, bumping it up would fix
the issue.
> Can anyone offer any suggestions?
>
> Thanks in advance,
>
> Errol Neal
|||Okay. I understand that. Thanks!
But why are we having random login failures? We are per-processor licensing so I am confused. Its not that the login is timing out. They are outright failing and I know because I am doing a SQL Server Trace and watching them as they fail.
-- Wayne Snyder wrote: --
As long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)
|||Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Errol Uriel Neal" <eneal@.enhtech.com> wrote in message
news:94D7AB61-A7F2-4FA1-B19C-D79B64B3B23D@.microsoft.com...
> Okay. I understand that. Thanks!
> But why are we having random login failures? We are per-processor
licensing so I am confused. Its not that the login is timing out. They are
outright failing and I know because I am doing a SQL Server Trace and
watching them as they fail.
>
> -- Wayne Snyder wrote: --
> As long as there are fewer than "Max worker threads" number of
connections,
> each connection gets its own individual thread... Once you go over
that
> number, several connections will share the same thread... You can
increase
> the number of worker threads, but that uses more memory ( even if
there are
> fewer connections.)
> Thread sharing could result in front end timeouts ( especially if the
other
> connection you are sharing the thread with is a busy one.)
>
|||No. There is nothing like that or remotely similiar to that in the logs.
I've been having this issue now for over a month. I even completely rebuilt my SQL Server because
of it.
-- Jasper Smith wrote: --
Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
Showing posts with label default. Show all posts
Showing posts with label default. Show all posts
Friday, March 30, 2012
Max Num of Worker Threads and User Connections/Logins
Hi everyone,
I need to know what is the relationship between the "Maxium Number of Worker
Threads" setting (default = 255) and user connections/sessions/logins.
From time to time, we are experiencing random login failure for several busy
databases. On average, we see about 264 total sessions on the box and we we
re wondering if the max worker threads number, bumping it up would fix the i
ssue.
Can anyone offer any suggestions?
Thanks in advance,
Errol NealAs long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)
"Errol U. Neal" <eneal@.enhtech.com> wrote in message
news:09B0F39B-1468-4069-A8A1-BF2AF2E645C8@.microsoft.com...
> Hi everyone,
> I need to know what is the relationship between the "Maxium Number of
Worker Threads" setting (default = 255) and user
connections/sessions/logins.
> From time to time, we are experiencing random login failure for several
busy databases. On average, we see about 264 total sessions on the box and
we were wondering if the max worker threads number, bumping it up would fix
the issue.
> Can anyone offer any suggestions?
>
> Thanks in advance,
>
> Errol Neal|||Okay. I understand that. Thanks!
But why are we having random login failures? We are per-processor licensing
so I am confused. Its not that the login is timing out. They are outright fa
iling and I know because I am doing a SQL Server Trace and watching them as
they fail.
-- Wayne Snyder wrote: --
As long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)|||Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Errol Uriel Neal" <eneal@.enhtech.com> wrote in message
news:94D7AB61-A7F2-4FA1-B19C-D79B64B3B23D@.microsoft.com...
> Okay. I understand that. Thanks!
> But why are we having random login failures? We are per-processor
licensing so I am confused. Its not that the login is timing out. They are
outright failing and I know because I am doing a SQL Server Trace and
watching them as they fail.
>
> -- Wayne Snyder wrote: --
> As long as there are fewer than "Max worker threads" number of
connections,
> each connection gets its own individual thread... Once you go over
that
> number, several connections will share the same thread... You can
increase
> the number of worker threads, but that uses more memory ( even if
there are
> fewer connections.)
> Thread sharing could result in front end timeouts ( especially if the
other
> connection you are sharing the thread with is a busy one.)
>|||No. There is nothing like that or remotely similiar to that in the logs.
I've been having this issue now for over a month. I even completely rebuilt
my SQL Server because
of it.
-- Jasper Smith wrote: --
Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.orgsql
I need to know what is the relationship between the "Maxium Number of Worker
Threads" setting (default = 255) and user connections/sessions/logins.
From time to time, we are experiencing random login failure for several busy
databases. On average, we see about 264 total sessions on the box and we we
re wondering if the max worker threads number, bumping it up would fix the i
ssue.
Can anyone offer any suggestions?
Thanks in advance,
Errol NealAs long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)
"Errol U. Neal" <eneal@.enhtech.com> wrote in message
news:09B0F39B-1468-4069-A8A1-BF2AF2E645C8@.microsoft.com...
> Hi everyone,
> I need to know what is the relationship between the "Maxium Number of
Worker Threads" setting (default = 255) and user
connections/sessions/logins.
> From time to time, we are experiencing random login failure for several
busy databases. On average, we see about 264 total sessions on the box and
we were wondering if the max worker threads number, bumping it up would fix
the issue.
> Can anyone offer any suggestions?
>
> Thanks in advance,
>
> Errol Neal|||Okay. I understand that. Thanks!
But why are we having random login failures? We are per-processor licensing
so I am confused. Its not that the login is timing out. They are outright fa
iling and I know because I am doing a SQL Server Trace and watching them as
they fail.
-- Wayne Snyder wrote: --
As long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)|||Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Errol Uriel Neal" <eneal@.enhtech.com> wrote in message
news:94D7AB61-A7F2-4FA1-B19C-D79B64B3B23D@.microsoft.com...
> Okay. I understand that. Thanks!
> But why are we having random login failures? We are per-processor
licensing so I am confused. Its not that the login is timing out. They are
outright failing and I know because I am doing a SQL Server Trace and
watching them as they fail.
>
> -- Wayne Snyder wrote: --
> As long as there are fewer than "Max worker threads" number of
connections,
> each connection gets its own individual thread... Once you go over
that
> number, several connections will share the same thread... You can
increase
> the number of worker threads, but that uses more memory ( even if
there are
> fewer connections.)
> Thread sharing could result in front end timeouts ( especially if the
other
> connection you are sharing the thread with is a busy one.)
>|||No. There is nothing like that or remotely similiar to that in the logs.
I've been having this issue now for over a month. I even completely rebuilt
my SQL Server because
of it.
-- Jasper Smith wrote: --
Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.orgsql
Max Num of Worker Threads and User Connections/Logins
Hi everyone
I need to know what is the relationship between the "Maxium Number of Worker Threads" setting (default = 255) and user connections/sessions/logins.
From time to time, we are experiencing random login failure for several busy databases. On average, we see about 264 total sessions on the box and we were wondering if the max worker threads number, bumping it up would fix the issue.
Can anyone offer any suggestions
Thanks in advance
Errol NealAs long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)
"Errol U. Neal" <eneal@.enhtech.com> wrote in message
news:09B0F39B-1468-4069-A8A1-BF2AF2E645C8@.microsoft.com...
> Hi everyone,
> I need to know what is the relationship between the "Maxium Number of
Worker Threads" setting (default = 255) and user
connections/sessions/logins.
> From time to time, we are experiencing random login failure for several
busy databases. On average, we see about 264 total sessions on the box and
we were wondering if the max worker threads number, bumping it up would fix
the issue.
> Can anyone offer any suggestions?
>
> Thanks in advance,
>
> Errol Neal|||Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Errol Uriel Neal" <eneal@.enhtech.com> wrote in message
news:94D7AB61-A7F2-4FA1-B19C-D79B64B3B23D@.microsoft.com...
> Okay. I understand that. Thanks!
> But why are we having random login failures? We are per-processor
licensing so I am confused. Its not that the login is timing out. They are
outright failing and I know because I am doing a SQL Server Trace and
watching them as they fail.
>
> -- Wayne Snyder wrote: --
> As long as there are fewer than "Max worker threads" number of
connections,
> each connection gets its own individual thread... Once you go over
that
> number, several connections will share the same thread... You can
increase
> the number of worker threads, but that uses more memory ( even if
there are
> fewer connections.)
> Thread sharing could result in front end timeouts ( especially if the
other
> connection you are sharing the thread with is a busy one.)
>|||No. There is nothing like that or remotely similiar to that in the logs.
I've been having this issue now for over a month. I even completely rebuilt my SQL Server because
of it.
-- Jasper Smith wrote: --
Do you see any errors on the SQL error log e.g. "could not spawn proces
login thread" or similar ? We have seen these under conditions of hig
memory contention especially in the MemToLeave area where new threads canno
allocate enough memory to start
--
HT
Jasper Smith (SQL Server MVP
I support PASS - the definitive, globa
community for SQL Server professionals
http://www.sqlpass.or
I need to know what is the relationship between the "Maxium Number of Worker Threads" setting (default = 255) and user connections/sessions/logins.
From time to time, we are experiencing random login failure for several busy databases. On average, we see about 264 total sessions on the box and we were wondering if the max worker threads number, bumping it up would fix the issue.
Can anyone offer any suggestions
Thanks in advance
Errol NealAs long as there are fewer than "Max worker threads" number of connections,
each connection gets its own individual thread... Once you go over that
number, several connections will share the same thread... You can increase
the number of worker threads, but that uses more memory ( even if there are
fewer connections.)
Thread sharing could result in front end timeouts ( especially if the other
connection you are sharing the thread with is a busy one.)
"Errol U. Neal" <eneal@.enhtech.com> wrote in message
news:09B0F39B-1468-4069-A8A1-BF2AF2E645C8@.microsoft.com...
> Hi everyone,
> I need to know what is the relationship between the "Maxium Number of
Worker Threads" setting (default = 255) and user
connections/sessions/logins.
> From time to time, we are experiencing random login failure for several
busy databases. On average, we see about 264 total sessions on the box and
we were wondering if the max worker threads number, bumping it up would fix
the issue.
> Can anyone offer any suggestions?
>
> Thanks in advance,
>
> Errol Neal|||Do you see any errors on the SQL error log e.g. "could not spawn process
login thread" or similar ? We have seen these under conditions of high
memory contention especially in the MemToLeave area where new threads cannot
allocate enough memory to start.
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Errol Uriel Neal" <eneal@.enhtech.com> wrote in message
news:94D7AB61-A7F2-4FA1-B19C-D79B64B3B23D@.microsoft.com...
> Okay. I understand that. Thanks!
> But why are we having random login failures? We are per-processor
licensing so I am confused. Its not that the login is timing out. They are
outright failing and I know because I am doing a SQL Server Trace and
watching them as they fail.
>
> -- Wayne Snyder wrote: --
> As long as there are fewer than "Max worker threads" number of
connections,
> each connection gets its own individual thread... Once you go over
that
> number, several connections will share the same thread... You can
increase
> the number of worker threads, but that uses more memory ( even if
there are
> fewer connections.)
> Thread sharing could result in front end timeouts ( especially if the
other
> connection you are sharing the thread with is a busy one.)
>|||No. There is nothing like that or remotely similiar to that in the logs.
I've been having this issue now for over a month. I even completely rebuilt my SQL Server because
of it.
-- Jasper Smith wrote: --
Do you see any errors on the SQL error log e.g. "could not spawn proces
login thread" or similar ? We have seen these under conditions of hig
memory contention especially in the MemToLeave area where new threads canno
allocate enough memory to start
--
HT
Jasper Smith (SQL Server MVP
I support PASS - the definitive, globa
community for SQL Server professionals
http://www.sqlpass.or
Monday, March 26, 2012
Matrix Zero Values
My Matrix presently shows results as follows.
column 1 column 2
row 1 23
row 2 34 34
How would I make the default null value to display as zero. Eg. Row 1, Column 1 would have a value of 0You will need an expression:
=iif(First(Fields!<FieldName>.Value) is Nothing, 0,
First(Fields!<FieldName>.Value))
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"SAcanuck" <SAcanuck@.discussions.microsoft.com> wrote in message
news:9D9A293F-1E84-439E-B1D5-EF6E76DFD068@.microsoft.com...
> My Matrix presently shows results as follows.
> column 1 column 2
> row 1 23
> row 2 34 34
> How would I make the default null value to display as zero. Eg. Row 1,
Column 1 would have a value of 0
column 1 column 2
row 1 23
row 2 34 34
How would I make the default null value to display as zero. Eg. Row 1, Column 1 would have a value of 0You will need an expression:
=iif(First(Fields!<FieldName>.Value) is Nothing, 0,
First(Fields!<FieldName>.Value))
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"SAcanuck" <SAcanuck@.discussions.microsoft.com> wrote in message
news:9D9A293F-1E84-439E-B1D5-EF6E76DFD068@.microsoft.com...
> My Matrix presently shows results as follows.
> column 1 column 2
> row 1 23
> row 2 34 34
> How would I make the default null value to display as zero. Eg. Row 1,
Column 1 would have a value of 0
Wednesday, March 7, 2012
Matrix - Column Grouping
I am using Matrix table for one of my reports
.
I would like to have three column groupings; where first grouping is
default. Other two should be based on the parameter selection. If '<None>'
is selected from the parameter option I do not want to show that secondary
grouping.
Is it possible?I'm not sure what you are trying to do.
If you just want to dynamically toggle the visibility of groups within a
matrix, you should install and check out the sample reports (e.g.
CompanySales.rdl). Also read BOL:
http://msdn.microsoft.com/library/en-us/rshowto/htm/hrs_designer_v1_0zvx.asp
However, if you want to statically "hide" detail groupings based on
parameter values you should use a dynamic column grouping expression based
on IIF. If you want to always "hide" a certain inner grouping based on a
parameter value, you would just group on a constant (and make sure to use a
similar expression for the column grouping label):
=iif(Parameters!P1.Value = "None", 1, Fields!ProductCategory.Value)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"RA" <rchaudhary-nospam@.storis.com> wrote in message
news:OTVO0hGZEHA.2840@.TK2MSFTNGP11.phx.gbl...
> I am using Matrix table for one of my reports
> .
> I would like to have three column groupings; where first grouping is
> default. Other two should be based on the parameter selection. If '<None>'
> is selected from the parameter option I do not want to show that secondary
> grouping.
>
> Is it possible?
>
.
I would like to have three column groupings; where first grouping is
default. Other two should be based on the parameter selection. If '<None>'
is selected from the parameter option I do not want to show that secondary
grouping.
Is it possible?I'm not sure what you are trying to do.
If you just want to dynamically toggle the visibility of groups within a
matrix, you should install and check out the sample reports (e.g.
CompanySales.rdl). Also read BOL:
http://msdn.microsoft.com/library/en-us/rshowto/htm/hrs_designer_v1_0zvx.asp
However, if you want to statically "hide" detail groupings based on
parameter values you should use a dynamic column grouping expression based
on IIF. If you want to always "hide" a certain inner grouping based on a
parameter value, you would just group on a constant (and make sure to use a
similar expression for the column grouping label):
=iif(Parameters!P1.Value = "None", 1, Fields!ProductCategory.Value)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"RA" <rchaudhary-nospam@.storis.com> wrote in message
news:OTVO0hGZEHA.2840@.TK2MSFTNGP11.phx.gbl...
> I am using Matrix table for one of my reports
> .
> I would like to have three column groupings; where first grouping is
> default. Other two should be based on the parameter selection. If '<None>'
> is selected from the parameter option I do not want to show that secondary
> grouping.
>
> Is it possible?
>
Subscribe to:
Posts (Atom)