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

No comments:

Post a Comment