NAV 2009 Performance ?

Liebe Kollegen,
nach nunmehr ~6 Monaten NAV 2009 R1 Betrieb (RTC) fällt uns immer mehr die Trägheit des Systems bei Ausführen von Berichten aller Art auf.
Ein Beispiel wäre der Bericht VK-Preisliste (715), der über 2 min. braucht (erzeugt dabei eine 100 Seiten Vorschau)- viel zuviel für ad hoc Abfragen.
Es gibt dabei keine Aktivitäten auf den Festplatten - die DB ist im Cache des 16GB Hauptspeichers. Das Netzwerk rührt sich auch kaum und die 6-Kerner CPU dümpelt auf 2 Kernen mit 30%.

Wo ist also der Flaschenhals und was kann man da machen?

Vielen Dank für Eure Tips

GGA

Eine ungefilterte Preisliste zu erstellen ist doch keine ad-hoc Aufgabe
Du solltest mal CPU/Netzwerk von DB Server, Service Tier und Client loggen, wenn Du diesen Report aufrufst.

Das Netzwerk rührt sich auch kaum und die 6-Kerner CPU dümpelt auf 2 Kernen mit 30%.

30% Auslastung ist aber schon ein bisschen.

Welcher Server hat 30, Der SQL oder der Service-Tier?

Mach mal im Taskmanager, wenn du auf dem Reiter Leistung bist, unter Ansicht den Haken bei "Kernelzeiten anzeigen". Sollte die dann erscheinende rote Linie der Kernelauslastung sehr nah an der grünen Linie der CPU-Auslastung sein, hast du ein Resourcen-Problem im Rechner. Ist der grüne Balken beim Arbeitsspeicher höher als der physikalische Speicher ist die Ursache, das der Rechner Arbeitsspeicher auslagert, was zu einer absolut bescheidenen Performance führt.

Was passiert denn, wenn du den Report mit dem CC ausführst?

Gruß, Fiddi

ich kann das auf unserer R2 Version (32012) nicht nachvollziehen. Unsere VK-Preisliste erzeugt über alle Debitoren zwar nur 30 Seiten, aber CPU geht für den NAV-Server auf max 20%, SQL auf max 12%, beides auf einer Maschine mit 12 GB RAM und 2xDualCore.

Warum nutzt euer Server aber nur 2 der 6 Kerne? Ist das gewollt?

Volker

Edit: Berichterstelung dauert max 10 Sekunden

Zunächst schonmal Danke für Eure Beteiligung!

Der Server ist ein SBS2008, auf dem alle Services zentral laufen. Es sind zur Testzeit aber keine anderen Anwender aktiv.
Die CPU-Last wird nur bei 3 Kernen erzeugt (darauf habe ich keinen Einfluß), dort liegt Sie im Schnitt bei 30%. Die KErnelzeiten sind ca. halb so groß wie das Gesamtmaximum (siehe auch Anhang)
Der Classic-Client erzeugt interessanterweise nur die halbe Last, ist aber unterm Strich nicht schneller in der Gesamtzeit.
Auf dem Client PC selbst ist die Last gegen Null; die Zeiten insgesamt ändern sich auch nicht wenn ich den Bericht auf dem Server selbst ausführe.

Laut Resourcenmonitor gibt es keine Auslagerungen von RAM, keine I/Os.
Die 10sec. Ausführungszeit von VSNASE sind schon viel plausibler;

Was ist denn bei sowas noch der Flaschenhals wenn es keine offensichtlichen Überlastungen gibt?

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

SBS2008: Wie ist die genaue Konfiguration? Ich meine wieviele HDD? Wie ist die Partitionierung? Welche Daten liegen wo? Virenscanner? SBS komplett mit Assistenten konfiguriert? Welche SQL-Version? Servicepacks? Freier Plattenpltaz?

Volker

Volker,
ich würde das gern sofort listen. aber ich denke das sprengt den Rahmen für dieses Forum.
Ich würde aber sehr gern jemanden mit entsprechender Erfahrung (kommerziell) auf den Server schauen zu lassen.
Womöglich ist es ja nur irgendein offensichtlicher Schalter ...

Gruß

Hallo,

an deinem Foto Taskmanager kann ich schon mal erkennen, das die Kernelzeiten sehr hoch sind, d.h. i.d.R. das System hat sehr viel mit sich selbst zu tun (z.B. Auslagern von Speicher). Schau mal welche Prozesse (Alle Prozesse anzeigen) wirklich die Rechenzeit ziehen. und welcher Prozess wieviel Speicher (mehr Spalten im taskmanager anzeigen) benötigt bzw. wie sicher der Speicherbedarf verändert. evtl. hilft uns das weiter bei der Suche wo der "Schalter" falsch eingestellt ist.

Hast du schon mal geprüft wie lange der Classic Client für den Report benötigt, und wie der Server dann belastet wird?

@vsnase: Wenn der Report 100 Seiten Vorschau liefert, gibt es einiges zu tun, da das System hier alle möglichen Konstellationen prüfen muss. Evtl. ist der Report für gga's Preiskonstellation auch nur bedingt geeignet, oder die zugrunde liegenden Stammdaten sind nicht so gepflegt, dass der Report damit schnell arbeiten kann .

Gruß, Fiddi

Ich glaube nicht, dass es an der Menge der zu berechnenden Daten liegt. Er sagt ja auch, dass es bei anderen Berichten ähnlich wäre.

Es gibt dabei keine Aktivitäten auf den Festplatten - die DB ist im Cache des 16GB Hauptspeichers.

Glaub ich nicht.

RAM ist mit 13 GB belegt. Ich rate mal ins blaue: Exchange belegt hiervon den größten Teil (4-6 GB), Sharepoint mit dazugehörigen SQL-Diensten (2-6GB), AV-Lösung, ...

Aber ohne Daten zu Hard- und Software, Patchstand und Useranzahl ist es nur raten.

Volker


PS
Ich geb mal einen Tip ab: Virenscanner - nicht aktuell oder Fehlkonfiguration bei ausgeschlossenen Dateien

Ich geb mal einen Tip ab: Virenscanner - nicht aktuell oder Fehlkonfiguration bei ausgeschlossenen Dateien

Dem würde aber widersprechen, dass die Ausführung des Berichts im CC etwa genauso lange dauert. Das dann die Last auf dem Server geringer ist, liegt daran, dass der Middle Tier, der offensichtlich auch auf dem Server läuft, nichts zu tun hat und somit nur die DB-Abfragen den Server belasten.

Ich kann mir schon vorstellen, dass der SQL-Server zu wenig Speicher hat und wahrscheinlich auch nicht begrenzt ist, was die Speichernutzung angeht. Das ist eine performancefressende Kombi. Ganz grundsätzlich bleibt festzuhalten: 16GB RAM ist für einen Server der "alles" machen soll einfach viel zu wenig. 16GB würde ich selbst bei kleinen Datenbanken als absolutes Minimum alleine für den SQL-Server ansetzen (bei den Speicherpreisen sollte man aus meiner Sicht eher bei 48GB aufwärts starten).

Da du ja einen Profi suchst: was SQL-Performance angeht gibt es wohl keinen besseren als Jörg Stryk. Ich durfte selbst schon von ihm lernen und mit das erste was er macht, ist sowieso die Konfiguration und Leistungsfähigkeit des SQL-Servers zu prüfen. Ich behaupte mal: dort findet er meistens schon Schwachstellen, auch wenn die nicht immer das absolut ausschlaggebende sind. Danach widmet er sich aber auch noch den im Code und den SQL-Abfragen bedingten Schwachstellen.

Edit: ich habe gerade gesehen, auf der Web-Site von Jörg Stryk gibt es einen Performance Quick Check. Vielleicht kann der zumindest die eine oder andere These stützen.

Wurde beim SQL Server ein Minimum-Speicherzuweisung vorgenommen? In den SQL Server Properties unter "Memory/Speicher" gibts zwei Zahlen. Die erste darf bei dir NICHT 0 sein!

Liebe Kollegen,
erstmal vielen Dank für Eure Mühen.
Ich habe nochmal einige Screenshots angehangen, die die Speicherauslastung etc. belegen.
Die Speicherzuweisung für den SQL habe ich auf 500MB Min. sowie 5000MB Max gesetzt (min war auf Null, Max auf irgendwas bei Petabyte).
Man sieht aber sehr schön, das es die SQL-Instanzen sind, die sich die Backen mit Speicher vollstopfen.
Nochmal :Während der Berichtausführung gibt es keine nennenswerten Plattenaktivitäten.

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

Das ist der Sinn, dass der SQL Server den Speicher vollpackt.
Es gibt eine KPI "Cache Hit Ratio". Cache sind Datenbankteile, die im Speicher liegen.
Alles unter 95% Cache Hit Ratio ist schlecht. Du wirst garantiert eine schlechte Hit Ratio haben.
Grund: Speichermangel.
Wenn die andere Serveranwendungen den Speicher vollstopfen, wird der SQL Server bei 500 MB oder etwas mehr rumdümpeln. Jetzt scheint es mit 3-4GB besser auszusehen.

Der SQL Server belegt den Speicher nicht sofort vor (ausser die 500 MB), und wenn dann nix mehr da ist, kann er sich nicht mehr nehmen.

Ich meine irgendwo mal gelesen zu haben, dass der Exchange vorzugsweise immer auf einer eigenen Maschine laufen soll. ;)

Vergiss die Sharepoint und Exchange Performance nicht ;)

Ich meine irgendwo mal gelesen zu haben, dass der Exchange vorzugsweise immer auf einer eigenen Maschine laufen soll. ;)

Im Prinzip richtig, aber hier nicht möglich, da beim SBS Exchange immer auf dem SBS (und somit auch DC) laufen muss. Allerdings kann man denSQL-Server auf eine separate Maschine ziehen.

Vorher könnte man aber noch mit dem SQL-Server Profilermal nachsehen wo genau die Berichtserstellung so lange dauert.

ACHTUNG: Falls es sich um einen SQL-Server 2005 handelt darf das Managment Studio NICHT AUF DEM SBS installiert werden. Dies ist nicht supported.

Volker

Verstehe das Argument mit dem limitierten Speicher, allerdings ist die DB-Größe verwirrend:
auf den Platten ist die DB ca. 1,2GB groß, beim Backup laut NAV ca. 2GB. Dies gilt für Test als auch Live - DB.
Nun wird es wirklich verwirrend, wenn man die Eigenschaften im SQL-Mgr. heranzieht:
dort ist die Test-DB (Abzug der Live-DB) ca. 3,3GB, die Live-DB aber ca. 10GB groß....

Welche Größe hat denn so eine DB effektiv?

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

Das Backup komprimiert die DB. Das kann nichts über die echte DB aussagen.

Ich würde mal behaupten, dass der Unterschied im Log-File liegt. Ein Sicherung der DB durch den SQL-Server ist wohl schon länger her oder hat noch nie stattgefunden.

Aber mit Deinen Problem dürfte das nicht allzu viel zu tun haben, außer dass vielleicht in der Grundkonfigurration des Servers (besonders der Partionierung) bereits einiges subotimal gelaufen ist und die Platte immer mehr fragmentiert.

Volker

Hallo,

was mich stutzig macht, ist die hohe Auslastung von System. Die sollte eigentlich nicht sein. Ist das auch so, wenn du den Report nicht laufen lässt?
Kann es sein, das die Datenbank auf automatisch verkleinern steht, und ihr eine automatische Vergrößerung in % angegeben habt, bzw, das Ihr die SQL-Datenbank- Dateien regelmäßig verkleinert?

Die Datenbank ist mir bei der Reportlänge (100 Seiten) eigentlich ein bisschen zu klein. Habt ihr die ursprünglich mal mit den Standardwerten aus NAV angelegt?

Gruß, Fiddi

Die DB ist seinerzeit von einem 'wenig begabten' Berater eingerichtet worden und vermutlich in Ihrem Auslieferungszustand.

Daher auch meine Frage nach einem SQL-Spezialisten, der mal drauf schaut.

Gruß
GGA

Hallo Gerhard,

Du wirst einen Fachmann beauftragen müssen. Der kann dann auch per RDP erstmal aus der Ferne draufschauen.

Für SBS hast per PN bereits Adressen, für NAV/SQL gibt es hier im Forum einige.

Wenn der Server so vermurckst ist wie Du vermutest, dann brauchts Du evtl. erst den einen dann den anderen.


Volker

Daher auch meine Frage nach einem SQL-Spezialisten, der mal drauf schaut.

Gruß
GGA

Jörg Stryk anrufen?

yap;
denke aber gleichzeitig über eine Auslagerung auf einen eigenen Server nach.
Stelle dazu aber eine eigene Anfrage in's Forum, da ich ob der Aufwände und wo ich einen Berater brauche, keine Idee habe.
Danke Euch allen nochmals

[fiddi]

Hallo,

denke aber gleichzeitig über eine Auslagerung auf einen eigenen Server nach.

Wenn deine Maschine nicht aus einem 1 Plattensystem mit einer 640 GB SATA- Platte besteht, dann kann das alles auf einer Maschine laufen. (habe selbst einige in Betrieb).
Diese Maschine sollte allerdings entsprechend ausgestattet sein: 16GB+ Arbeitsspeicher (bei größerer Datenbank mehr), mindestens 2x RAID1 SAS mit mindestens 146GB (eher größer) für OS und Daten und 2x RAID1 SAS mit >=73GB für SQL-DB und SQL-LOG (abhängig von der DB Größe)+ zusätzliche Datenplatten, wenn mehr Daten gespeichert werden müssen. Dazu ein vernünftiges Bandlaufwerk (LTO3 o. LTO4) damit die Datensicherung auch fertig wird (USB2.0 Platten haben eine so unterirdischen Durchsatz, dass eine vernünftige Komplettsicherung jeden Tag nicht möglich ist).

Gruß, Fiddi

EDIT: Dieser Vorschlag ist als Basis für eine SBS-Maschine zu verstehen mit dem Datenvolumen, wie es beschrieben wurde. Natürlich muss man in Jedem Fall möglichst eine genaue Analyse des vorhanden und erwarteten Datenaufkommens machen. Irgendwann kommt der Punkt, an dem dann auch ein physikalischer Server nicht mehr ausreicht. Bei den Maschinen, die ich bisher mit SBS ausgerüstet habe, war diese Basis aber immer ausreichend.

Zuletzt geändert von fiddi am 21. Juli 2011 07:49, insgesamt 1-mal geändert.

Diese Maschine sollte allerdings entsprechend ausgestattet sein: 16GB+ Arbeitsspeicher (bei größerer Datenbank mehr), mindestens 2x RAID1 SAS mit mindestens 146GB (eher größer) für OS und Daten und 2x RAID1 SAS mit >=73GB für SQL-DB und SQL-LOG (abhängig von der DB Größe)+ zusätzliche Datenplatten, wenn mehr Daten gespeichert werden müssen.

Diese Aussage bitte nicht als Grundlage für die Planung eines SQL-Servers verwenden. Das ist einfach viel zu allgemein und Datenbank und Log auf ein Raid zu packen, kann man grundsätzlich nicht empfehlen. Dazu würde ich mich überhaupt nur breitschlagen lassen, wenn die Datenbank kleiner als 2GB ist und ein Wachstum von nicht mehr als 200MB im Jahr hat. Und selbst dann hätte ich Bauchschmerzen dabei.
Edit: hab gerade gesehen, dass dort 2 x RAID 1 steht. Aber trotzdem kann man den Konfigurationsvorschlag nicht als Grundlage für die Planung eines SQL-Servers empfehlen.

Dazu ein vernünftiges Bandlaufwerk (LTO3 o. LTO4) damit die Datensicherung auch fertig wird (USB2.0 Platten haben eine so unterirdischen Durchsatz, dass eine vernünftige Komplettsicherung jeden Tag nicht möglich ist).

USB 3.0 gibt es auch schon auf dem freien Markt.
LTO ist aber trotzdem die bessere Wahl imho.