From: Malkesh on
Hi All,

Since last 2-3 weeks, our system has been experiencing issue of deadlocks
and slow performance.

The configuration is SQL Server 2005 SP3 64 bit Standard edition with 8
processor and 64 GB RAM (57 GB for SQL Server). Though it is not required but
AWE is enabled and lock pages in memory priviledge granted on service
account. We are using Quest SpotLight to monitor performance. The database
file configurations are: on E drive we have SQL installation and all the data
files and on F drive we have log files and tempdb. I'm not sure but it is on
RAID 1+0

Issues are:
1- High log flush wait time frequently on the server
2- High number of deadlocks

Does log file placement alongwith tempdb leads to high log flush wait time
issue? Also could it be possible cause for deadlocks? My doubt is on high log
flush time for slow performance. If i isolate tempdb from other log files,
does it solve problem of high log flush time. Also let me know the possible
solution.

Thanks in advance.

Thanks & Regards
Malkesh
From: Eric Isaacs on
Database:Log Flush Waits/sec: The number of commits that are waiting
on log flush. Although transactions do not wait for the log to be
flushed in tempdb, a high number in this performance counter indicates
and I/O bottleneck in the disk(s) associated with the log.

Look at finding ways to speed up your log file drive.

Deadlocks may be related, or may be a separate issue.

-Eric Isaacs

From: Erland Sommarskog on
Malkesh (Malkesh(a)discussions.microsoft.com) writes:
> Since last 2-3 weeks, our system has been experiencing issue of deadlocks
> and slow performance.
>
> The configuration is SQL Server 2005 SP3 64 bit Standard edition with 8
> processor and 64 GB RAM (57 GB for SQL Server). Though it is not
> required but AWE is enabled and lock pages in memory priviledge granted
> on service account. We are using Quest SpotLight to monitor performance.
> The database file configurations are: on E drive we have SQL
> installation and all the data files and on F drive we have log files and
> tempdb. I'm not sure but it is on RAID 1+0
>
> Issues are:
> 1- High log flush wait time frequently on the server
> 2- High number of deadlocks
>
> Does log file placement alongwith tempdb leads to high log flush wait
> time issue? Also could it be possible cause for deadlocks? My doubt is
> on high log flush time for slow performance. If i isolate tempdb from
> other log files, does it solve problem of high log flush time. Also let
> me know the possible solution.

Moving the log files may remove that symptom, but I don't think the
overall performance will improve very much.

Most likely what has happened is that a query plan for one or more queries
has changed from good to bad. There are a number of reasons why that could
happen. It could be because the plan of the cache, and statististics are
not up to date. Or it could be because statistics changed, and the optimizer
now does a misestimation.

So you need to find the slow queries. There are a number of ways to find
them: run a trace are dm_exec_query_stats two examples. But since you are
getting deadlocks, it may be a start to analyse the deadlock traces. It
is not unlikely that any of the bad plans are involved in the deadlock.
You will get deadlock tracaes in the SQL Server error log by adding
-T1222 as a start-up parameter to SQL Server. You can also enable it
without a server restart by issuing DBCC TRACEON (1222, -1), but Books
Online suggest that we should use it only when the server is idle.

--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

From: Malkesh on
Thank you all for the feedback.

Deadlock were already there in the system. We have eConnect application
which was initially run in multi thread. We have changed it to single thread
and deadlocak numbers have come down but still it is high there.

Before this issues, we were exeperiencing avg. disk queue length and page
life expectancy issues. So we have increased RAM and now those two issues
gone, but comes the high log flush time issue and system is slow down. Now
page life expectany is around 10 minutes and Buffer cache hit ratio is almost
99%. Also procedure cache hit ration is just above 90% however Soptlight
sometime throws message "56% of all the SQL compilation is recompilation" and
"Size of Virtual page file down to 8%'. Are these also bottlenecks?

We have following user defined settings:
1. SQL Server 2005 64 bit Standard with 8 processor
2. 64 GB RAM
3. AWE Enabled
4. Min 0 and Max 57 GB RAM allocation
5. Max Worker Thread 1024 9 (We almost have around 400-500 sessions running
all the time)
6 Max DOP 1 (since multi threading was creating deadlocks we have changed
this from 0 to 1)
7. Great planes database is on the same server/

Also could you please tell me any of the above settings especially Max DOP
or Max Worker thread affect the issue?
--
Thanks & Regards
Malkesh


"Erland Sommarskog" wrote:

> Malkesh (Malkesh(a)discussions.microsoft.com) writes:
> > Since last 2-3 weeks, our system has been experiencing issue of deadlocks
> > and slow performance.
> >
> > The configuration is SQL Server 2005 SP3 64 bit Standard edition with 8
> > processor and 64 GB RAM (57 GB for SQL Server). Though it is not
> > required but AWE is enabled and lock pages in memory priviledge granted
> > on service account. We are using Quest SpotLight to monitor performance.
> > The database file configurations are: on E drive we have SQL
> > installation and all the data files and on F drive we have log files and
> > tempdb. I'm not sure but it is on RAID 1+0
> >
> > Issues are:
> > 1- High log flush wait time frequently on the server
> > 2- High number of deadlocks
> >
> > Does log file placement alongwith tempdb leads to high log flush wait
> > time issue? Also could it be possible cause for deadlocks? My doubt is
> > on high log flush time for slow performance. If i isolate tempdb from
> > other log files, does it solve problem of high log flush time. Also let
> > me know the possible solution.
>
> Moving the log files may remove that symptom, but I don't think the
> overall performance will improve very much.
>
> Most likely what has happened is that a query plan for one or more queries
> has changed from good to bad. There are a number of reasons why that could
> happen. It could be because the plan of the cache, and statististics are
> not up to date. Or it could be because statistics changed, and the optimizer
> now does a misestimation.
>
> So you need to find the slow queries. There are a number of ways to find
> them: run a trace are dm_exec_query_stats two examples. But since you are
> getting deadlocks, it may be a start to analyse the deadlock traces. It
> is not unlikely that any of the bad plans are involved in the deadlock.
> You will get deadlock tracaes in the SQL Server error log by adding
> -T1222 as a start-up parameter to SQL Server. You can also enable it
> without a server restart by issuing DBCC TRACEON (1222, -1), but Books
> Online suggest that we should use it only when the server is idle.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se
>
> Links for SQL Server Books Online:
> SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
> SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
> SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
>
> .
>
From: Erland Sommarskog on
Malkesh (Malkesh(a)discussions.microsoft.com) writes:
> Deadlock were already there in the system. We have eConnect application
> which was initially run in multi thread. We have changed it to single
> thread and deadlocak numbers have come down but still it is high there.
>
> Before this issues, we were exeperiencing avg. disk queue length and
> page life expectancy issues. So we have increased RAM and now those two
> issues gone, but comes the high log flush time issue and system is slow
> down. Now page life expectany is around 10 minutes and Buffer cache hit
> ratio is almost 99%. Also procedure cache hit ration is just above 90%
> however Soptlight sometime throws message "56% of all the SQL
> compilation is recompilation" and "Size of Virtual page file down to
> 8%'. Are these also bottlenecks?

Not necessarily.

> We have following user defined settings:
> 1. SQL Server 2005 64 bit Standard with 8 processor
> 2. 64 GB RAM
> 3. AWE Enabled
> 4. Min 0 and Max 57 GB RAM allocation
> 5. Max Worker Thread 1024 9 (We almost have around 400-500 sessions
> running all the time)
> 6 Max DOP 1 (since multi threading was creating deadlocks we have changed
> this from 0 to 1)
> 7. Great planes database is on the same server/
>
> Also could you please tell me any of the above settings especially Max DOP
> or Max Worker thread affect the issue?

It's common to set MaxDOP to 1 for OLTP systems. I don't want to venture
about what is a good setting for Max Worker Threads.

I will have to admit that server configuration is not my field of
expertise. I rather look on a server from what queries are doing,
to see if queries can be improved or indexes be added. I can understand
that if you are running third-party applications only, your options are
a bit limited in that regard. Nevertheless, poorly tuned queries is
usually the root of all evil.

So I think you still need to dig under the surface to determine where
the slowness is coming from.

--
Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx