[gelöst] SQL Performance NAV 2013

Bild Microsoft Dynamics NAV 2013 (aka "NAV 7")

[gelöst] SQL Performance NAV 2013

Beitragvon Pablo1985 » 31. Oktober 2014 09:35

Hallo Leute,

ich habe ein Problem mit meinem SQL Server und weiĂź leider ĂĽberhaupt nicht mehr weiter.

Problem:
Sobald ich im Navision irgendeine Page aufmache erscheinen im SQL Server Aktivitätsmonitor Wartende Tasks. Diese verschwinden erst nach ca. 10-15 min (vorrausgesetzt ich mache nichts mehr mit NAV) oder wenn ich das NAV schließe. Je mehr User es werden umso mehr wartende Tasks habe ich und das NAV wird langsamer und langsamer bis es sich dann komplett aufhängt. Ganz auffällig ist es beim Öffnen der Item Card oder bei Pages wo Lagerbestände o.ä. berechnet werden müssen.
Ich dachte zuerst es könnte an der Netzwerkverbindung vom Server zum Client liegen. Aber das Problem taucht auch auf wenn ich den NAV Client direkt lokal auf dem SQL Server öffne.
Im Anhang habe ich Bild vom Aktivitätsmonitor angefügt. Ich weiß leider überhaupt nicht mehr wo ich suchen soll.

Folgende Versionen habe ich:
SQL Server 2012 Vers11
NAV 2013 7.0
Alles läuft auf einer virtuellen Umgebung mit ESX Hosts (VMware)

GrĂĽĂźe
Paul
Dateianhänge
wartende Tasks.png
Zuletzt geändert von Pablo1985 am 10. November 2014 11:44, insgesamt 1-mal geändert.
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon fiddi » 31. Oktober 2014 10:06

Hallo,

- ist das Ă„nderungsprotokoll aktiviert?
- welches Build setzt ihr ein?
- Sind auf der Page sehr viele Flowfields?

GruĂź, Fiddi
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7088
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: SQL Performance NAV 2013

Beitragvon Pablo1985 » 31. Oktober 2014 10:36

Hallo Fiddi,

- ist das Ă„nderungsprotokoll aktiviert?
Ja das ist aktiviert, allerdings bin ich im Moment der einzgste der auf der Datenbank arbeitet da diese erst am Montag online geht.

- welches Build setzt ihr ein?
Wir setzen Build 7.0.35469.0 ein

- Sind auf der Page sehr viele Flowfields?
Auf der Item Card sind schon viele FlowFields. Allerdings tritt das Problem auch auch wo nur ein FlowField drauf ist.

GrĂĽĂźe
Paul
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon defiant701 » 31. Oktober 2014 10:43

Moin,

das Problem scheint tatsächlich in Richtung Netwerk Problem zu gehen. Es kommt häufiger bei SQL Clustern vor. Prüfe doch bitte mal die Verbindung zwischen dem Service Tier und dem SQL Server. Der Client hat damit ja nicht mehr viel zu tun und bietet hier keinerlei Aussage.

BG
Debuggers don't remove bugs, they only show them in slow-motion

LinkedIn
XING
defiant701
 
Beiträge: 128
Registriert: 28. März 2007 15:01
Wohnort: Hamburg
Realer Name: Dirk Zastrow
Arbeitsort: Hamburg
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics 365

Re: SQL Performance NAV 2013

Beitragvon fiddi » 31. Oktober 2014 10:56

Hallo,

bevor wir weiter diskutieren und testen bitte NAV auf das aktuelle Build 38052 bringen. Es gab mehrere Probleme mit der Performance, die inzwischen verbessert wurden.

Eine weitere Möglichkeit ist Verbindung vom Servicetier zum SQL-Server, wie Dirk schon sagte, ist nicht der Client für die SQL- Performance zuständig, sondern der Servicetier.

Wie ist eure Struktur des Systems (auf welchen Servern läuft was, wie sind die (virtuellen) Maschinen ausgestattet (Speicher, Cores, Platten...) )?

GruĂź, Fiddi
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7088
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: SQL Performance NAV 2013

Beitragvon Pablo1985 » 31. Oktober 2014 11:12

Hallo Zusammen,

Bei uns ist alles auf einem Server (Servicetier, SQL-Server, etc.). Der Server hat ingsgesamt 24GB RAM, SSD Platten, 4x vCPU 2.00GHz)

Macht es sinn, die Verbindung zwischen dem Servicetier und dem SQL-Server zu testen wenn bei des auf einem Server liegt? Bzw. wie stelle ich das an?

Ich denke ich werde auch den Weg von fiddi probieren und NAV auf das aktuelle Build bringen bevor ich noch weiter rumprobiere. Vielleicht lösen sich dadurch einige Probleme von allein.

GrĂĽĂźe
Paul
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon defiant701 » 31. Oktober 2014 11:30

Alles auf einer Umgebung? Hm, na ja wem es gefällt. Schließt aber einige Punkte aus. Ich habe keine Plattform oder Applikations Updates gefunden die entsprechend lauten, aber das sollt ja nichts heißen. Fiddi's Aussage macht in jedem Fall Sinn. Falls es dann immernoch hakt, schau mal ob du das Shared Memory Protokoll aktiviert hast, da die DATA Loads ja jetzt auf dem DB Server selber liegen.

BG
Debuggers don't remove bugs, they only show them in slow-motion

LinkedIn
XING
defiant701
 
Beiträge: 128
Registriert: 28. März 2007 15:01
Wohnort: Hamburg
Realer Name: Dirk Zastrow
Arbeitsort: Hamburg
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics 365

Re: SQL Performance NAV 2013

Beitragvon MichaelK » 31. Oktober 2014 11:31

Hallo,

in Deinem Fall könnten auch die folgenden Werte interessant sein:

SQL_Server.jpg


Was ist da bei Dir eingestellt?

GruĂź

Michael
MichaelK
Microsoft Partner
Microsoft Partner
 
Beiträge: 550
Registriert: 4. März 2009 10:21
Realer Name: Michael Kaluza
Arbeitsort: Lustenau
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 3.70,4.00,5,2009,2013,2015

Re: SQL Performance NAV 2013

Beitragvon fiddi » 31. Oktober 2014 11:41

Hallo,

Der Server hat ingsgesamt 24GB RAM, SSD Platten, 4x vCPU 2.00GHz


Wieviele VMs laufen denn auf dem Server?

Hoffentlich sind die SSDs nicht mit einem simpel Onboard- SATA- RAID5 verschaltet, und der komplette ESX läuft auf einem RAID5. Dann ist es mit der Performance trotz SSD nicht weit her.

GruĂź, Fiddi
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7088
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: SQL Performance NAV 2013

Beitragvon Pablo1985 » 31. Oktober 2014 12:01

@fiddi
die Serverkonfiguration die ich geschrieben habe ist nur für den SQL auf diesem ESX Host läuft noch zuätzlich eine VM. Der ESX hat insgesamt 64GB RAM und 12 CPUs.

@Michael
Ich habe die selben Werte wie in deinem Screenshot

@Dirk
Das Shared Memory Protokoll ist aktiviert.
Dateianhänge
xxx.jpg
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon stryk » 31. Oktober 2014 17:22

Mal bitte dieses Script im Management Studio ausfĂĽhren:

Code: Alles auswählen
WITH Waits AS
(SELECT
wait_type,
wait_time_ms / 1000.0 AS WaitS,
(wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS,
signal_wait_time_ms / 1000.0 AS SignalS,
waiting_tasks_count AS WaitCount,
100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (
'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK',
'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE',
'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH',
'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',
'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER',
'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE',
'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES',
'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK')
 AND wait_type NOT LIKE 'HADR_%'
)
SELECT
W1.wait_type AS WaitType,
CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S,
CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S,
CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S,
W1.WaitCount AS WaitCount,
CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage,
CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S,
CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S,
CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum
GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage
HAVING SUM (W2.Percentage) - W1.Percentage < 99.9; -- percentage threshold
GO

Wo liegen die Werte bei CXPACKET und ASYN_NETWORK_IO, ggf. auch OLEDB (Screenshot)?

Auf der Maschine muss folgendes eingestellt werden:
  • Windows Power Options: High Performance
  • SQL Server: Instance: Max. Degree of Parallelism: halbe Anzahl der CPU (dann sehen wir weiter)
  • SQL Server: tempdb: so viele Data-Files wie CPU vorhanden sind; jede Datei ausreichend groĂź (zB. 1000 MB), AutoGrowth fix auf 100 MB
Wenn der ASYNC_NETWORK_IO (das scheint gem. Screenshot das Problem hier zu sein!) weit aus höher ist, als eine normale LAN Latenz (die sollte unter 1 msec sein), dann deutet das auf zwei Probleme hin:
1. Falsche Konfiguration der Netzwerkkarte:
(Netzwerkverbindung -> Eigenschaften -> Konfigurieren -> Erweitert)
Die Funktionen "TCP Offloading", "UDP Offloading" und alles was mit "Checksum Offloading" (ipv4, ipv6, large, usw) vorhanden ist deaktivieren.
Die Option "RSS" (Receive Side Scaling) auch erstmal deaktivieren.
Vorherige Einstellungen merken damit die ggf. zurückgesetzt werden können.
(Auch wenn beide Dienste auf der selben Maschine sind kommuniziert der NST via Netzwerkadapter!)
2. Der NST ist nicht in der Lage, die SQL Daten zeitnah zu verarbeiten:
==> NST auf eigene Maschine setzen (siehe dann auch Punkt 1)
==> NST patchen so gut es geht
==> NST DataCache auf 10; MetaDataCache auf 1000

Damit ist erstmal die Basis halbwegs solide. Aber: das AutoCalc-Feature der FlowFields auf den Pages erzeugt brutalst teure Abfragen - jede FlowField-Info wird ĂĽber in der Abfrage eingebundenen APPLY Joins berechnet, was i.d.R. sehr "sub-optimal" ist und zu erheblichen Index-Scans etc. fĂĽhrt!
Sowas müsste dann präzise Indiziert werden, was aber ziemlich aufwendig werden kann ...
(Die SQL Abfrage, die solche Pages absetzen, geht schon mal entspannt ĂĽber 300 Zeilen, wenn man sie formatieren wĂĽrde ...)
Leider ist NAV 2013 genauso schlecht indiziert (aus SQL Server Sicht) wie alle Vorgänger; hier besteht grundsätzlich Handlungsbedarf, um teure Index Scans weitmöglichts einzudämmen.

Schau'n wir mal ...

Bleibt die schlechte Nachricht zum Schluss: der NST 2013 ist nicht ausgereift und hat erhebliche Probleme mit dem "Verdauen" größerer Ergebnismengen. SQL Abfragen die zig tausend Datensätze pumpen müssen identifiziert werden und dann durch Programmierung/Filterung in kleinere Häppchen zerlegt werden ...
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon Pablo1985 » 3. November 2014 08:36

Hallo Jörg,

vielen Dank fĂĽr deine ausfĂĽhrliche Beschreibung. Ich lege gleich damit los und berichte heute im Laufe des Vormittags.

GrĂĽĂźe
Paul
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon stryk » 3. November 2014 09:03

Toi Toi Toi.
Der nächste Schritt wäre dann via SQL Profiler mitzuschneiden, welche Abfrage(n) hier ausgeführt werden; ggf. auch mit diesem Script aus dem Prozedur Cache lesen:

Code: Alles auswählen
USE [Database] -- set db name
GO

SET NOCOUNT ON
GO

-- Server Uptime
select cast((datediff(hh, create_date, getdate()))/24 as varchar(3)) + ' days, '
     + cast((datediff(hh, create_date, getdate())) % 24 as varchar(2)) + ' hours'
     as [SQL Server Service Uptime]
from sys.databases where name = 'tempdb'
GO

SELECT TOP 100
SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END
- qs.statement_start_offset)/2) + 1) as statement_text,
case when st.text like '%LIKE%' then 'LIKE' else '' end AS [Wildcard],
execution_count,
case
when execution_count = 0 then null
else total_logical_reads/execution_count
end as avg_logical_reads,
case
when execution_count = 0 then null
else (total_worker_time/execution_count) / 1000
end as [avg_cpu_(msec)],
case
when execution_count = 0 then null
else (total_elapsed_time/execution_count) / 1000
end as [avg_duration_(msec)],
case
when execution_count = 0 then null
else total_rows/execution_count
end as [avg_rows],

-- Query Plan Information
--ph.query_plan,
qs.creation_time,
qs.last_execution_time,
case when
ph.query_plan.exist('declare namespace ns="http://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtCursor/ns:CursorPlan/@CursorRequestedType)[1]') = 0
then '' else
ph.query_plan.value('declare namespace ns="http://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtCursor/ns:CursorPlan/@CursorRequestedType)[1]','nvarchar (max)')
end as cursor_type

-- Missing Indexes
,case when ph.query_plan.exist('declare namespace ns="http://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtSimple/ns:QueryPlan/ns:MissingIndexes/ns:MissingIndexGroup)[1]') = 0
then ''
else ph.query_plan.value('declare namespace ns="http://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtSimple/ns:QueryPlan/ns:MissingIndexes/ns:MissingIndexGroup/@Impact)[1]','nvarchar (max)')
end as missing_index_impact,
case when ph.query_plan.exist('declare namespace ns="http://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtSimple/ns:QueryPlan/ns:MissingIndexes/ns:MissingIndexGroup/ns:MissingIndex/@Table)[1]') = 0
then ''
else ph.query_plan.value('declare namespace ns="http://schemas.microsoft.com/sqlserver/2004/07/showplan";(/ns:ShowPlanXML/ns:BatchSequence/ns:Batch/ns:Statements/ns:StmtSimple/ns:QueryPlan/ns:MissingIndexes/ns:MissingIndexGroup/ns:MissingIndex/@Table)[1]','nvarchar(max)')
end as missing_index_table

FROM sys.dm_exec_query_stats as qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) as ph

WHERE (st.text is not null)

--AND (execution_count >= 100)  -- change threshold
AND (total_logical_reads/execution_count >= 1000) -- change threshold

ORDER BY total_worker_time DESC
GO

---

SELECT migs.group_handle, mig.index_handle, migs.user_seeks, migs.last_user_seek, migs.user_scans, migs.last_user_scan, migs.avg_user_impact,
       db_name(mid.database_id) as db, object_name(mid.object_id) as object, mid.equality_columns, mid.inequality_columns, mid.included_columns

    --,'CREATE INDEX [ssi_' + convert(varchar, migs.group_handle) + '_' +  convert(varchar, mig.index_handle) + '] ON [' +  object_name(mid.object_id) + '] ' + '(' +
    --  CASE WHEN mid.equality_columns is not null THEN mid.equality_columns ELSE '' END +
    --  CASE WHEN mid.equality_columns is null AND mid.inequality_columns is not null THEN mid.inequality_columns ELSE '' END +
    --  CASE WHEN mid.equality_columns is not null AND mid.inequality_columns is not null THEN ', ' + mid.inequality_columns ELSE '' END + ')' +
    --  CASE WHEN mid.included_columns is not null THEN ' INCLUDE (' + mid.included_columns + ')' ELSE '' END as tsql
      
FROM sys.dm_db_missing_index_group_stats AS migs
INNER JOIN sys.dm_db_missing_index_groups AS mig
    ON (migs.group_handle = mig.index_group_handle)
INNER JOIN sys.dm_db_missing_index_details AS mid
    ON (mig.index_handle = mid.index_handle)
WHERE (mid.database_id = db_id())

AND (migs.user_seeks >= 100)  -- change threshold
AND (migs.avg_user_impact >= 90)  -- change threshold

ORDER BY object_name(mid.object_id) ASC, migs.user_seeks DESC, migs.user_scans DESC
GO
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon Pablo1985 » 4. November 2014 14:33

Hallo Jörg,

anbei die Auswertung von deinem ersten Skript.
folgende Punkte habe ich auch schon erledigt:
- Windows Power Options: High Performance
- SQL Server: Instance: Max. Degree of Parallelism: halbe Anzahl der CPU (dann sehen wir weiter)
- SQL Server: tempdb: so viele Data-Files wie CPU vorhanden sind; jede Datei ausreichend groĂź (zB. 1000 MB), AutoGrowth fix auf 100 MB
- Netzwerkkarte nach deinen Angaben konfiguriert.


den Punkt 2 habe ich noch nicht gmeacht. Wir hatten gestern den ersten Tag mit der neuen Version und ich hatte dementsprechen Stress... deswegen auch die verspätete Rückmeldung.

GrĂĽĂźe
Paul
Dateianhänge
auswertung.jpg
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon stryk » 4. November 2014 16:03

OK, ASYNC_NETWORK_IO ist mit 22 msec zu hoch; CXPACKET gerade noch akzeptabel, wird aber besser mit dem neuen MAXDOP.

Jetzt bitte mal die WaitStats zurĂĽcksetzen:

Code: Alles auswählen
DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
GO


Dann ein paar Stunden warten, und neu ĂĽberprĂĽfen - hier ein leicht optimiertes Script:

Code: Alles auswählen
WITH Waits AS
(SELECT
wait_type,
wait_time_ms / 1000.0 AS WaitS,
(wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS,
signal_wait_time_ms / 1000.0 AS SignalS,
waiting_tasks_count AS WaitCount,
100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (
'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK',
'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE',
'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH',
'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',
'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER',
'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE',
'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES',
'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK', 'DIRTY_PAGE_POLL', 'SP_SERVER_DIAGNOSTICS_SLEEP')
 AND wait_type NOT LIKE 'HADR_%'
)
SELECT
W1.wait_type AS WaitType,
CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S,
CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S,
CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S,
W1.WaitCount AS WaitCount,
CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage,
CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S,
CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S,
CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum
GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage
HAVING SUM (W2.Percentage) - W1.Percentage < 99; -- percentage threshold
GO


Dann sehen wir mal, ob sich der ASYNC_NETWORK_IO verbessert. Wenn nicht, dann ist unser "Problemkind" der NST an sich ...
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon SilverX » 4. November 2014 16:28

Dann möchte ich auch mal etwas Senf dazugeben. Ich weiß nicht ob die Tatsache, dass du sowohl den Dynamics NAV Server als auch den SQL Server auf einem virtuellen Rechner installiert hast einen Unterschied macht, aber wir hatten in der Vergangenheit mit VMWare einige Probleme, die mit folgenden Hinweisen gelöst werden konnten (englisch):

• Over provisioning and Balloon Drivers
o When over provisioning on a VM Host Server the server can begin to de-allocate memory to the individual VM’s via the Balloon Memory Drivers. This cause a drastic decrease in overall system performance, we recommend you either disable the Balloon Drivers on system critical VM’s or monitor its utilization.
• Synthetic Device Drivers
o The biggest issue we see with Virtualized servers is that the customer is not running the correct or most updated synthetic drivers for such things as Disk and Network Interface Cards. Please verify with VMware that all drivers are correct and up to date
• Server Side Scaling
o With the older version of VMware ESX server the synthetic NIC driver VMNXT 3 has “Receive Server Side Scaling” disabled. We recommend that you verify that this enabled on all NICs on all VM regardless of the driver.


Ich hab nicht alles von Jörg gelesen, möchte aber auch darauf hinweisen, dass der SQL Server Speicher begrenzt werden sollte, so dass der NAV Server genug Luft zum atmen hat. Im allgemeinen, sicherlich auch abhängig von der Anzahl an Benutzern, empfehlen wir 8-12 GB Speicher für den Dynamics NAV Server zu reservieren (also dem SQL Server zu klauen).
Cheers
Carsten


This post is my own opinion and does not necessarily reflect the opinion or view of my employer.
SilverX
Microsoft Partner
Microsoft Partner
 
Beiträge: 1252
Registriert: 16. September 2006 14:07
Realer Name: Carsten Scholling
Arbeitsort: GĂĽtersloh
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2013+

Re: SQL Performance NAV 2013

Beitragvon stryk » 4. November 2014 18:35

SilverX hat geschrieben:..., möchte aber auch darauf hinweisen, dass der SQL Server Speicher begrenzt werden sollte, so dass der NAV Server genug Luft zum atmen hat. Im allgemeinen, sicherlich auch abhängig von der Anzahl an Benutzern, empfehlen wir 8-12 GB Speicher für den Dynamics NAV Server zu reservieren (also dem SQL Server zu klauen).

Absolut! Darauf bin ich nicht eingegangen. Aber 8 bis 12 GB für einen NST??? Der Standard DataCache ist ja auf 512 MB eingestellt, ich habe im Thread mal geraten den behutsam auf 10 (also 1024 MB) zu setzen - wie um alles soll der NST 8GB+ allokieren? Ich habe bisher noch NIE einen NST dazu bringen können, annähernd 4GB zu nutzen???

Wenn das wirklich so erforderlich ist - und da wäre ich für ein offizielles MS Statement sehr dankbar! - dann ist es ein ABSOLUTES NO-GO den NST auf der SQL Maschine zu installieren!!!
Aber im konkreten Fall: das beschriebene Problem habe ich schon bei zig anderen NAV 2013 Installationen gesehen - auch da, wo der NST auf einer dedizierten Maschine ist.
Das ist in der Tat ein Problem im Zusammenspiel VMWare und NAV 2013 ...

Und um nochmal darauf zurĂĽckzukommen: im aktuellen Fall solltest Du "Max. Server Memory" m.E. mal auf 18000 MB setzen - also 18GB fĂĽr SQL, 2GB fĂĽr's OS und 4GB fĂĽr den NST. Wenn die 4GB fĂĽr den NST nicht ausreichen, dann WEG DAMIT auf eine eigene Maschine!
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon Patrick Ringert » 5. November 2014 12:24

Interessantes Thema...

Unser Kunde ist auch nicht so ganz zufrieden mit der Performance. Die Skript-Daten vom Kunden anbei. Da scheint wohl auch ein Problem mit der Service-Tier vorzuliegen. Und der Server ist tatsächlich auch virtualisiert. Was genau muss ich jetzt dem Infrastrukturpartner sagen, was geändert werden muss?

ASYNC_NETWORK_IO 39821.49 39816.06 Mai 43 191233 97.55 0.2082 0.2082 0.0000
Patrick Ringert
Microsoft Partner
Microsoft Partner
 
Beiträge: 152
Registriert: 19. Juli 2006 10:18
Wohnort: Berlin
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2.x-aktuelle Version

Re: SQL Performance NAV 2013

Beitragvon stryk » 5. November 2014 12:34

Also ich sehe das auch immer häufiger: VMWare mit NAV 2013/R2; Symptome: ASYNC_NETWORK_IO viel zu hoch (also deutlich über 1 msec) und alles (?) irgendwie zäh, ganz besonders diverse heftige "Page" Abfragen sind grotten-langsam ...
In einigen Fällen hat die oben beschriebene Netzwerkadapter Einstellung das Problem lösen können, in anderen Fällen aber nicht ...

ASYNC_NETWORK_IO bedeutet grundsätzlich, dass der SQL Server Daten an seine Gegenstelle (NAV, NAS, NST, Client, etc.) sendet und auf Rückmeldung wartet (quasi "Yo, ich hab's erhalten"). D.h. der SQL Server ist performance-technisch raus aus der Nummer, der hat seinen Job mit der "Lieferung" der Daten erledigt (gäbe es hier Probleme - e.g. teure Abfragen etc. - dann würde man das im Profiler sehen). Ergo, es gibt zwei mögliche Ursachen: die Netzwerkkommunikation ist gestört, oder der "Empfänger" braucht schlichtweg zu lange, um die erhaltenen Daten zu verarbeiten.
Letzeres ist m.E. ein grundsätzliches Problem vom NST - zumindest bei großen Datenmengen -; kommt erschwerend das VMWare/LAN Problem dazu ...
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon stryk » 5. November 2014 12:38

Patrick Ringert hat geschrieben:
Code: Alles auswählen
ASYNC_NETWORK_IO   39821.49   39816.06   Mai 43   191233   97.55   0.2082   0.2082   0.0000


D.h. 97.55 allen Wartens des SQL Servers (und der wartet immer auf irgendwas, ganz normal) ist ASYNC_NETWORK_IO; ein Vorgang dauert dabei im Schnitt 0.2082 Sekunden! Eine normale LAN-Latenz sollte unter einer msec (also 0.001) liegen (z.B. via PING) ...
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon Patrick Ringert » 5. November 2014 12:44

Netzwerkadaptereinstellung wurden entsprechend geändert. Leider keine Änderungen. Also müssen wir jetzt auf ein neues Build hoffen, wo die Probleme behoben werden?
Patrick Ringert
Microsoft Partner
Microsoft Partner
 
Beiträge: 152
Registriert: 19. Juli 2006 10:18
Wohnort: Berlin
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2.x-aktuelle Version

Re: SQL Performance NAV 2013

Beitragvon stryk » 5. November 2014 12:50

SilverX hat geschrieben:
• Over provisioning and Balloon Drivers
o When over provisioning on a VM Host Server the server can begin to de-allocate memory to the individual VM’s via the Balloon Memory Drivers. This cause a drastic decrease in overall system performance, we recommend you either disable the Balloon Drivers on system critical VM’s or monitor its utilization.
• Synthetic Device Drivers
o The biggest issue we see with Virtualized servers is that the customer is not running the correct or most updated synthetic drivers for such things as Disk and Network Interface Cards. Please verify with VMware that all drivers are correct and up to date
• Server Side Scaling
o With the older version of VMware ESX server the synthetic NIC driver VMNXT 3 has “Receive Server Side Scaling” disabled. We recommend that you verify that this enabled on all NICs on all VM regardless of the driver.


@Carsten: hast Du ggf. dazu noch mehr/konkretere Hinweise?
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon stryk » 5. November 2014 12:52

Patrick Ringert hat geschrieben:Netzwerkadaptereinstellung wurden entsprechend geändert. Leider keine Änderungen.

Bitte beachte, dass die SQL Wait Stats kumuliert sind! Wenn man was ändert, dann müssen die Stats erst gelöscht werden (siehe oben), dann erst sieht man, wie sich die Werte wirklich enpendeln - ansonsten lügen die Zahlen.
Jörg A. Stryk (MVP - Dynamics NAV)
NAV/SQL Performance Optimization & Troubleshooting
STRYK System Improvement
stryk
Microsoft Partner
Microsoft Partner
 
Beiträge: 767
Registriert: 30. November 2006 12:32
Wohnort: NĂĽrnberg
Realer Name: Jörg Stryk
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: SQL Performance NAV 2013

Beitragvon Pablo1985 » 5. November 2014 13:53

Hallo Jörg,

ich habe heute gegen 8h mit deinem Skript alles gelöscht und jetzt nochmal die Abfrage durchgeführt.
Leider keine Ă„nderung.

Ich habe mit einem guten Freund telefoniert der mir noch empfohlen hat die Treiber fĂĽr die VMware Tools und Netzwerkadapter zu aktualisieren. Das werde ich noch probireren.

Den SQL RAM habe ich jetzt auf 18 GB beschränkt. Ich habe der Maschine jetzt auch insgesamt 36GB RAM gegeben. Aber ich denke das Problem muss woanders liegen. User beschweren sich natürlich ununterbrochen :)

GrĂĽĂźe
Paul
Dateianhänge
auswertungheute.jpg
Pablo1985
 
Beiträge: 31
Registriert: 15. September 2014 11:29
Arbeitsort: MĂĽnchen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 7.0

Re: SQL Performance NAV 2013

Beitragvon SilverX » 5. November 2014 14:46

stryk hat geschrieben:
SilverX hat geschrieben:
• Over provisioning and Balloon Drivers
o When over provisioning on a VM Host Server the server can begin to de-allocate memory to the individual VM’s via the Balloon Memory Drivers. This cause a drastic decrease in overall system performance, we recommend you either disable the Balloon Drivers on system critical VM’s or monitor its utilization.
• Synthetic Device Drivers
o The biggest issue we see with Virtualized servers is that the customer is not running the correct or most updated synthetic drivers for such things as Disk and Network Interface Cards. Please verify with VMware that all drivers are correct and up to date
• Server Side Scaling
o With the older version of VMware ESX server the synthetic NIC driver VMNXT 3 has “Receive Server Side Scaling” disabled. We recommend that you verify that this enabled on all NICs on all VM regardless of the driver.


@Carsten: hast Du ggf. dazu noch mehr/konkretere Hinweise?
Leider nicht. Aber vielleicht ist ja das vSphere Performance Guide eine gute Anlaufstelle: Performance Best Practices for VMware vSphere™ 5.0.
Cheers
Carsten


This post is my own opinion and does not necessarily reflect the opinion or view of my employer.
SilverX
Microsoft Partner
Microsoft Partner
 
Beiträge: 1252
Registriert: 16. September 2006 14:07
Realer Name: Carsten Scholling
Arbeitsort: GĂĽtersloh
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2013+

Nächste

ZurĂĽck zu NAV 2013

Wer ist online?

Mitglieder in diesem Forum: Unbekannter Robot und 1 Gast