Antwortverhalten Navision

Guten Morgen,

ich wende mich mit einem Problem an Euch, welches sich sicher nicht pauschal beantworten lässt. Zu viele Faktoren können hier eine Rolle spielen.

Nun zu meinem Problem, unsere Kunde kritisiert immer wieder das Antwortverhalten von Navision. Im konkreten Fall werden z.B. Depitorposten im Quittungsvorschlag modifiziert oder Quittungen registriert. Navision zeigt "manchmal" mehrere Sekunden die Eieruhr.

Nach der Aussage des Kunden war vor der Umstellung auf NAV 5.0 alles viel schneller – klar, früher war alles besser…

Das Antwortverhalten ist allerdings nicht reproduzierbar und „gefühlt“ langsam. Die Verarbeitung des gleichen Arbeitsschrittes wird mal „schnell“ (sofort) mal „langsam“ (mehrere Sekunden) vom System ausgeführt. Eine Analyse ist da fast unmöglich.

Ich denke nicht, dass sich hier der Aufwand lohnt der Sache auf den Grund zu gehen. Habt ihr eine gute und nachvollziehbare Antwort für einen Kunden?

Danke und Gruß
Roland

Habt ihr eine gute und nachvollziehbare Antwort für einen Kunden?

Du meinst eine gute Ausrede? ;)

Man müsste schon etwas mehr über die Architektur wissen (Wieviel User, Native/SQL, Was für Clients laufen (RAM-Ausstattung, allg. Leistungsfähigkeit), ist das Netz komplett auf Gbit, fehlen vllt. Schlüssel ... hat hier bei mir alles eine Rolle gespielt).

Genau! Eine gute Ausrede

Wir haben unser System vor einem halben umgestellt und können unserem Kunden nicht erzählen, dass die verwendete Hardware etc. nicht ausreichend ist.
Wie gesagt, das Problem kommt "mal" vor und ist nicht reproduzierbar und manchmal werden die Sekunden zu gefühlten "Stunden".

Das sah hier tatsächlich ähnlich aus. Das Nachrüsten von RAM in den Clients, Ersetzen alter PCs, Umstellen des ganzen Netzwerks auf Gbit, Überarbeiten einiger Schlüssel/einigen Codes hat´s aber gelöst (zumindest läuft das Ganze nun seit einigen Wochen wirklich gut).

Also das Umstellen des gesamten Netzes auf Gbit halte ich für überzogen. 100 Mbit reichten zumindest bei allen meinen bisherigen Arbeitgebern aus um flott in Navision arbeiten zu können. Anders würde es aussehen wenn das netz generell sehr stark belastet ist und ganz schlecht v erfügbar wäre.

Ein Faktor allerdings der nicht zu unterschätzen ist ist die lokale Hardware. Wenn man da mit 386ern den Navision client ausführt wird der Client auch schön langsam arbeiten, da kann der SQL Server noch so ein bolide sein.

Beide Probleme könnte man recht elegant mit Terminalserver regeln, das erspart einem den Austausch lokaler Hardware und das Netz wird deutlich entlastet (Citrix).

Was ich mir aber an Deiner konkreten Schilderung auch vorstellen könnte ist das die Programmierung nicht so toll ist. Hier könnte ein Workshop eines Profi wunder bewirken. Z.B. Stryk hier aus dem Forum! Man könnte ja bei dem langsamen Vorgang analysieren was passiert (SQL Profiler) und kommt i.d.Regel recht schnell zu einer Lösung bzw. dem Problem viel näher.

Viele Grüße
Tesa.

Also das Umstellen des gesamten Netzes auf Gbit halte ich für überzogen. 100 Mbit reichten zumindest bei allen meinen bisherigen Arbeitgebern aus um flott in Navision arbeiten zu können. Anders würde es aussehen wenn das netz generell sehr stark belastet ist und ganz schlecht v erfügbar wäre.

Stimmt, bei dem Datendurchsatz hätten eigentlich auch 10Mbit reichen müssen ;) Aber der Tausch eines 100er gegen einen Gb-Switch hat in einem Fall wahre Wunder bewirkt. Da wurde aus einer fürchterlichen Schnecke wieder ein PC mit einer Nav-Arbeitsgeschwindigkeit wie alle anderen.

Wenn wirklich das Netzwerk der Engpass ist und 100 Mbit nicht reichen, solltest Du dringend rausfinden welche Vorgänge oder Dienste das Netz derart belegen.Es dürfte dann nämlich auch nicht lange dauern bis 1Gbit nicht mehr reicht oder knapp wird. Über Nagios oder andere Traffic Netzwerktools siehst Du das sofort.

Ein RPoblem was ich mal erlebt hatte das ein Etagenswitch sich als Hub rausstellte und trotz guter Switches im RZ der Hub einen Durchsatz pro client lieferte der ISDN geschwindigkeit entsprach. Ggf. gibt es hier auch so eine tolle hub konstruktion bei der sich recht v iele Anwender über einen MEdia Markt Switch connecten und dann über einen Uplink in das RZ gehen.

Vielleicht war der Switch auch einfach kaputt, ich kann´s wirklich nicht sagen. Zum Glück muss ich mich da auch gar nicht drum kümmern, mit dem Strippenziehen hab ich es nämlich sowieso nicht

Der Server sollte heute mindestens eine Gbit- Verbindung zu(m) Switch(es) haben. Die Clients können auch weiterhin mit 100Mbit betrieben werden.
Deine temporären Performance-Probleme könnte auch ein zu kleiner Server Cache sein, oder schlecht gewählte Schlüssel oder vergessene Filter. Dann können aus 10tel Sekunden schon mal ein paar Minuten werden, wie ich aus eigener Erfahrung bestätigen kann.

Deshalb, wenn du uns was zur Umgebung sagen kannst, dann kann man da evtl. helfen.

Gruß, Fiddi

Ich werde unsere Umgebung später mal etwas näher beschreiben. Sie ist "etwas" komplexer und für die Beschreibung benötige ich etwas Zeit. Aber vorweg, wir arbeiten mit Navision 5.0 (SQL-DB), das ganze in einer VM-Ware Umgebung. Unsere Benutzer (ca.50) haben Zugriff über Citrix. Einzelheiten folgen...

Ein paar Eckdaten zur Infrastruktur:

Physisch: 2 Server mit jeweils 4 AMD QuadCore Opteron 2,3 Ghz und jeweils 64GB RAM (Plattform für VM-Ware ESX)
Virtuell: NAV-DB (MS-SQL 2005/ 64bit), 4 CPUs und 16 GB RAM, Win2k3/ 64bit
Weitere Angaben zur NAV-DB: 55GB Datenbankgröße, 32.000KB Cache
Netzwerk intern, alles Gigabit-Ethernet
Kunden-Zugriff auf Navision über Navision-Client via Citrix (Hardware und Netzwerk beim Kunden unbekannt), garantierte Bandbreite unsererseits 6MBit

Angeber

Genau! ... nein, aber es kann wohl eher nicht an der Hardware liegen ...

Hmm .. als ich mal gefragt habe, wo und wie ich anfangen soll, nach Performancebremsen unseres Systems zu suchen, bekam ich von wirtnix folgende Antwort:

so ins blaue hinein:
ihr habt euren SQL-Server doch hoffentlich nicht in einer VM laufen?

Ich habe allerdings keine Ahnung, wie er das gemeint hat

doch schon, wenn der VM-Ware- Server, der die SQL-DB behandelt, mit einer GBit Leitung per iSCSI auf eine Storage zugreift. Oder der Server mit anderen Aufgaben (Plattenzugriffen,..) beschäftigt ist, und dadurch den Rest ausbremst.

Ich gehe mal davon aus, das die Server auf eine Storage zugreifen. Wie viele Platten hat die, macht die evtl. unter der Fahrt Snapshots, wie sind die Server an die Storage angebunden, und welche VMs laufen auf welcher Maschine.

Gruß, Fiddi

Uns war das "Problem" der Virtualisierung von Anfang an bekannt, daher auch diese hoch-dimensionierte Hardware. In der Umgebung steckt viel Schweiß!
Bis heute läuft alles ziemlich gut und "rund", bis auf diese kleinen Hänger, die sich nicht reproduzieren lassen...

@Fiddi: Da brauche ich jetzt etwas Hilfe von unserem Admin

Also wenn ihr einen Datenbankserver in einer VMware Umgebung fahrt sind die Anforderungen an das Storage natürlich nicht unerheblich. Es sollte in jedem Fall mit FC angebunden sein.

Auf jeden Fall empfehlenswert ist die die beiden VMWare (ihr habt hoffentlich 3.5.0 ESX Version) Server mit genügend Ethernet schnittstellen auszurüsten, üblich ist eine Quad Port Karte zu haben, in unserer Umgebung mit 3 x ESX Servern haben wir jeweils zu den beiden vorhandenen Ethernet Schnittstellen pro Server noch eine Quad Port dazugepackt, so dass wir in Summe 6 x 1Gbit pro ESX Knoten haben, was dann theoretisch 6Gbit entspricht. Das hat dann eben den Vorteil das Client Zugriffe "Load-balanced" verteilt werden und Du schonmal keinen Engpass bekommst im Bezug auf alle Dienste oder Server die auf Deine VM Umgebung zugreifen, wenn Du da nur ein Käbelchen mit 1x Gbit hast merkt man sehr schnell das Netzwerkmäßig was nicht stimmt, da sich alle VM-Maschinen die Bandbreiten teilen! Und das SAN sollte immer mit FC angebunden sein an die beiden ESX Knoten. Mit lokalen Festplatten zu arbeiten kann man natürlich vergessen, keine Redundanz und kein Speed.

Von der Dimensionierung her ist der SQL Server schon okay, wenn das Problem wirklich das Netz ist solltest Du wie gesagt einfach mal auf dem SQL Server den Performance Monitor anwerfen. Dort siehst Du doch wie hoch der Netztraffic ist und Du siehst auch ob bei Einfügeoperationen der Server auf die Platten vom SAN wartet. Bzw. Du kannst auch in der VM Konsole sehen wie die Netzauslastung ist!

Unabhängig von der Hardwaresituation ist natürlich bei einer Navision SQL Datenbank pflicht laufende Jobs zu haben (am besten täglich abends) wie rebuildindex und createstats, da die DB mit der Zeit immmer langsamer wird wenn man diese SQL Wartungsjobs nicht hat.

Was für ein SAN habt ihr eigentlich? Und wie ist es angebunden? MIt Fibrechannel? Wieviele VMS laufen denn auf der Maschine auf der auch der SQL Server läuft?

Und hier ist jetzt auch der Admin mit weiteren Infos zum Storage:

Die beiden ESX-Server sind über Fibre Channel an ein Storage angebunden. Die Storagebox hat 8 HDDs im RAID 6 Verbund nur für die VMs. Dann gibt es noch 2 RAID 0 mit jeweils 4 HDDs. Jedes dieser RAID 0 ist in zwei virtuelle Festplatten aufgeteilt:

Erstes RAID 0: Enthält auf einer Festplatte die DB-Datei des SQL 2005 (für Navision) und auf der anderen Festplatte das TLog des SQL 2000 (ist eine kleine schlanke DB).
Zweites RAID 0: Enthält auf der einen Festplatte das TLog der SQL 2005 DB und auf der anderen Festplatte die DB-Datei des SQL 2000.

Wartungsjobs sind eingerichtet und laufen jede Nacht.

Interessant ist hierbei noch, daß sich das TLog der SQL 2005 DB (Navision) sporadisch auf bis zu 40 GB aufbläht. Und das innerhalb von 30 Minuten. Das TLog wird alle 15 Minuten gesichert. Und mitunter ist die Sicherungsdatei 20 MB groß, die nächste dann z. B. 2 GB und die nächste danach wiederum z. B. 29 GB. Ich frage mich was die Ursache hierfür sein könnte. Normal erscheint mir das auch nicht.

Ohje also das sich das Transaction log mittendrin auf 40 GB ausbreitet ist nicht normal! schon gar nicht bei der Datenbankgröße und auch nicht im Bezug auf die paar Benutzer.

Wenn sich das TLog auf diese größe ausbreitet ist es kein Wunder das die Datenbank in diesem Moment der Vergrößerung verlangsamt oder still steht, die Anwender merken das!

Kurzfristig kannst Du folgendes tun: Das Tlog auf meinetwegen auf 100 GB vergrößern, so muss nicht physikalisch von ein paar GB auf 40 GB vergrößert werden zur Laufzeit (mach das wenn niemand drin arbeitet) das ist nur ne maßnahme um den zustand ein wenig zu verbessern. Als nächsten Schritt muss man unbedingt herausfinden welcher Prozess diese Datenmasse im Tlog erzeugt! Gibt es laufende SQL Aufträge die in dieser Zeit laufen (Zeitplan) Oder ein bestimmter Batchlauf der ganz viel macht etc.?

Also normal ist das auf keinen Fall!

Eine Möglichkeit wäre auch noch, dass die Vergrößerung des Logs in Prozent angegeben wurde - das kann natürlich zu recht heftigen Schritten führen, ein fester Vergrößerungswert ist hier im allgemeinen vorzuziehen.

Das TLog ist derzeit 45 GB groß und zu 0,5% belegt. Die automatische Vergrößerung steht bereits auf 100 MB.

Parallel zu den alle 15 Minuten laufenden Sicherungen des TLog lasse ich noch seit kurzem noch 4 selbstgebastelte Scripte laufen, die die jeweils aktuellen Connections, Requests, Sessions und die Auslastung des TLog abfragen und protokollieren. Auf diese Weise erhoffe ich mir Licht in das Dunkel des TLog-Wachstums zu bekommen. Aber zur Zeit gibt es keine Auffälligkeiten. Die Sicherungsdatei des TLogs schwankt seit gestern zwischen 3,6 MB und 500 MB. Das TLog selbst ist wie gesagt 45 GB groß, wird also derzeit nicht vollständig gefüllt.

Habt Ihr evtl. noch eine Idee, was man ggfs. noch abfragen sollte? Wie würden "normale Werte" für die Größe des TLogs aussehen? Es können sich bei uns max. 60 Benutzer gleichzeitig anmelden und auf die DB losrennen. Das ist ja eigentlich auch nicht so wirklich viel.

Die MDF-Datei ist 5,1 GB groß, die NDF-Datei 71,7 GB und die LDF-Datei 44,9 GB. Macht es hier ggfs. Sinn die NDF-Datei in mehrere aufzuteilen? Diese müßten dann aber auf der gleichen virtuellen HDD liegen. Welche Dateigröße wäre dabei empfehlenswert? Habt Ihr dazu evtl. Erfahrungswerte oder Best Practice Tips? Aber ich fürchte auch, daß das sporadische Anwachsen des TLogs damit nicht behoben wäre. Was meint Ihr dazu?

Habe eben gelesen, daß man eine NDF-Datei nicht in kleinere zerteilen kann. Man kann lediglich mehrere pro Datenbank anlegen, damit die Datenbank beim Erreichen der maximalen Dateigröße weiter wachsen kann. Hmm, sehr mysteriös das alles...