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
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
max no. of values in WHERE ... IN clause
Hi all,
can anyone tell mey what the maximum number of values (if there is any) which can be used in the WHERE ... IN clause?
ex:
... WHERE ID IN (1, 2, 3 ... , n) ...
what is the maximum number of values which I can put between paranthesis?
10x in advance
mihai.That's decided by the specific DB system.|||10x in advance
"10X" = "thanks"? Whatever next...!|||How many can you put there is one question. How many can you put there and still get an answer while you are young enough to care is a different question. The answer to both questions varies significantly from one query and database engine to another.
-PatP
can anyone tell mey what the maximum number of values (if there is any) which can be used in the WHERE ... IN clause?
ex:
... WHERE ID IN (1, 2, 3 ... , n) ...
what is the maximum number of values which I can put between paranthesis?
10x in advance
mihai.That's decided by the specific DB system.|||10x in advance
"10X" = "thanks"? Whatever next...!|||How many can you put there is one question. How many can you put there and still get an answer while you are young enough to care is a different question. The answer to both questions varies significantly from one query and database engine to another.
-PatP
Max no. of parameters in functions
Hi,
Can anybody tell me the max no of parameters that we can use in a single
UDF?
Thanks!!BOL:
A function can have a maximum of 1,024 parameters.|||BOL:
A function can have a maximum of 1,024 parameters.
Thanks a lot Sean.|||Hi,
Can anybody tell me the max no of parameters that we can use in a single
UDF?
Thanks!!Half of me shudders every time I see a post about SQL Server's maximum capacity, and the other half tingles with excitement at the future potential consulting income.|||anybody ever made a UDF with that many no of parameters ?|||anybody ever made a UDF with that many no of parameters ?|||anybody ever made a UDF with that many no of parameters ?
Plz listen,don't blame me for that,I found the question in an online test for the MCDBA 70-229 exam (Designing and Implementing Databases with Microsoft SQL Server 2000 Enterprise Edition).:D
and the other half tingles with excitement at the future potential consulting income.
Batman is an experienced person and has all the future insights which protect him from danger. :D ;)|||not blaming you for anything ... i was just thinking aloud ;)|||not blaming you for anything ... i was just thinking aloud ;)
yea,there you are,I too was running in that same road a few hours ago.:D :D|||I am a late riser ... mostly go out on evening walks :D
Can anybody tell me the max no of parameters that we can use in a single
UDF?
Thanks!!BOL:
A function can have a maximum of 1,024 parameters.|||BOL:
A function can have a maximum of 1,024 parameters.
Thanks a lot Sean.|||Hi,
Can anybody tell me the max no of parameters that we can use in a single
UDF?
Thanks!!Half of me shudders every time I see a post about SQL Server's maximum capacity, and the other half tingles with excitement at the future potential consulting income.|||anybody ever made a UDF with that many no of parameters ?|||anybody ever made a UDF with that many no of parameters ?|||anybody ever made a UDF with that many no of parameters ?
Plz listen,don't blame me for that,I found the question in an online test for the MCDBA 70-229 exam (Designing and Implementing Databases with Microsoft SQL Server 2000 Enterprise Edition).:D
and the other half tingles with excitement at the future potential consulting income.
Batman is an experienced person and has all the future insights which protect him from danger. :D ;)|||not blaming you for anything ... i was just thinking aloud ;)|||not blaming you for anything ... i was just thinking aloud ;)
yea,there you are,I too was running in that same road a few hours ago.:D :D|||I am a late riser ... mostly go out on evening walks :D
max no of datafiles
whats the maximum no of datafiles & logfiles sqlserver
supports.
thanksFrom BOL
32,767 files per database
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"kumar" <sqldba2004@.yahoo.com> wrote in message
news:149c401c414cd$7f963c60$a301280a@.phx
.gbl...
> whats the maximum no of datafiles & logfiles sqlserver
> supports.
> thanks
supports.
thanksFrom BOL
32,767 files per database
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"kumar" <sqldba2004@.yahoo.com> wrote in message
news:149c401c414cd$7f963c60$a301280a@.phx
.gbl...
> whats the maximum no of datafiles & logfiles sqlserver
> supports.
> thanks
Max mirroring DB on a 64-bit sysstem?
According to BOL we know
"On a 32-bit system, database mirroring can support a maximum of about 10 databases per server instance because of the numbers of worker threads that are consumed by each database mirroring session."
My question is: What is maximum number of mirrored DB we can deploy on 64-bit system per one sql instance?
It depends. Do you have a 64-CPU box with 1 TB of RAM or a 4 CPU box with 4 GB? The variety of 64-bit hardware available makes specific guidance difficult.
You will need to test your configuration appropriately regardless.
|||Peter thanks for you answer.
We have got the next configuration :
HP Superdome (1 cell) 4 CPU?(Dual core Itanium 2 1.6GHz, 24 MB Cache),?32GB.
|||In the case of multiple databases, I use a different tack to overcome the problem. If I find any database failed over, I run SQL commands to fail them all over. "ALTER DATABASE [dbname] SET PARTNER FAILOVER" you must proceed the command with "USE [master]". It works in my case as i am running web code against multiple databases at any given point in time, so I have to have them all failover at the same time anyways. The statement to return the state of each database is "SELECT * from sys.database_mirroring WHERE mirroring_guid IS NOT NULL" I read the values programatically and run the appropriate failover statements depending on the values returned.
|||This was extremely useful, I copied it verbatim into a scheduled task that runs every minute and checks this, because we've had the same issue where only some but not all databases fail over. There should be an SQL Server feature to make multiple databases "atomic" for the purpose of failover.sql
Subscribe to:
Posts (Atom)