[gelöst] SQL Performance NAV 2013

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

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von Pablo1985 am 10. November 2014 11:44, insgesamt 1-mal geändert.

Hallo,

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

Gruß, Fiddi

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

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

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

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

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

Hallo,

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

SQL_Server.jpg

Was ist da bei Dir eingestellt?

Gruß

Michael

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

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

@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.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Mal bitte dieses Script im Management Studio ausführen:

Code:

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 ...

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

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:

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


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

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

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:

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
GO

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

Code:

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 ...

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).

..., 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!

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

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 ...

Code:

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) ...

Netzwerkadaptereinstellung wurden entsprechend geändert. Leider keine Änderungen. Also müssen wir jetzt auf ein neues Build hoffen, wo die Probleme behoben werden?

• 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?

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.

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

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

• 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.