[Gelöst] Navision seit Migration langsamer

Hallo folgendes Probelem:

vor kurzem habe ich den NAV DB-Server auf ein ziemlichen guten Server (Dell PowerEdge T610 Rack-Server)umgezogen:

8GB RAM, Quadcore, 6 redudante SAS-Platten, 1Gbit-Netzwerk, 6GB gr0ße DB , 54% belegt, 32 MB DBMS Cache& Object Cache


Der Server ist also um einiges schneller als sein Vorgänger.
Trotzdem behaupten alle Benutzer es sei langsamer, obwohl schon die Peformanceprobleme schon vorher bestanden.
Ich habe es sogar mir durch einen Spezialisten meines NAV-Partners bestätigen lassen, dass die Probleme zu 100% schon vorher bestanden haben und die Gründe dafür in der Datenbank selbst liegen. Ich habe sogar zusammen mit den Spezialisten den alten Server hochgefahren und siehe da, die Probleme existierten einfach vorher schon.
Trotzdem behaupten 99% meiner Mitarbeiter, dass die Performanceprobleme erst seit der Umstellung da sind, und ja - ich jetzt daran schuld sei- dass alle jetzt nur noch so langsam arbeiten können.

Momentan bin ich dabei, die Probleme zu analysieren und habe folgendes festgestellt:

- durch falsche Indizierungen,Schlüssel usw:
diese Probleme kann man lösen, keine Frage
- die teils gigantische Anzahl von Datensätzen in manchen Tabellen (>500.000)


Bei letzeren weiß ich nicht wie ich das lösen soll und ich kann wohl daran nichts änderen.
Bloß, was soll ich meinen Mitarbeitern sagen, die mich jetzt täglich wg. der Performance nerven.
Mit dem Spezialisten habe ich das bereits diskutiert, er könnte etwas unternehmen, aber die Verbesserungen
halten sich in Grenzen. Ich weiß, dass ist eine Frage die über technischen Dinge in diesem Forum weit hinausgeht, aber:
Wie sage ich es meinen Mitarbeitern( und vor allem meinen Chef), dass es keine umfassende Lösung dazu geben wird?
Vielen Dank für eure Mithilfe, bin echt verzweifelt.

Zuletzt geändert von NAVGATOR am 24. Februar 2010 11:32, insgesamt 1-mal geändert.

Ich kann dir jetzt schon sagen, dass unsere Spezis weitere (genauere) Infos haben wollen :
Betriebssystem, ist die DB SQL oder Native (falls SQL: welche Version, 32 oder 64bit), Anbindung der Platten, Server virtualisiert J/N, wie läuft das restliche Netzwerk usw.

Sollte es ein SQL-Server sein, kannst du mit einem technischen Upgrade auf 5.0 oder höher sicher noch etwas heraus holen, da die SQL-Unterstützung besser ist. Und: da hat der Server hier auch ein paar Wochen gebraucht, bis er richtig geschmeidig lief.

Wenn du aber wirklich nur eine gute Ausrede suchst .... weiß ich leider keine

wenn wir von einer nativen Datenbank reden ist der DBMS Cache auf jeden Fall schonmal sehr klein.
Zum Vergleich: auf unserem Server mit nur 2GB RAM steht der DBMS Cache auf 900.000KB, Commit Cache ist aktiviert.

wenn wir von einer nativen Datenbank reden ist der DBMS Cache auf jeden Fall schonmal sehr klein.
Zum Vergleich: auf unserem Server mit nur 2GB RAM steht der DBMS Cache auf 900.000KB, Commit Cache ist aktiviert.

Sorry wenn ich hier so rein springe, aber 900.000KB bei 2 GB RAm geht aber nur bei einem Datenbankteil,der Wert wird nämlich pro Datenbankteil genutzt.

Also das mit 900 MB pro Datenbankteil wäre mir neu.

ich glaube vielmehr das DBMS-Cache, den er hier angibt, der DBMS Cache aus dem Client ist, und nicht der vom Server

Gruß, Fiddi

Ich hab mal einen Screnshot vom Taskmanger mit den Prozessen bzgl. Navision reingehängt. unserer Server (native Datenbank) hat einen Cache von 150 MB man schön erkennen, das 8 Slave Processe laufen mit jeweils 150 MB, das entspricht genau unseren Datenbankteilen.

nav-server.png

Bzgl. des genannten Caches gehe ich auch eher vom Client aus.

aber im Taskmanger kann man schön erkennen was genommen wird.

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

Dann erklär mir mal folgendes:

PicTasklist.png

PicSystemlist.png

wenn dem so wäre, wie du sagst, dann müsste der Rechner entweder 10 GB Arbeitsspeicher haben, oder nur swappen, das tut er aber nicht, wie du auf der zweiten Seite sehen kannst

Gruß, Fiddi

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

Puh, gute Frage,

ich hab mir das kurz bei userem Server angeschaut und da sieht es ähnlich aus.
Nutzen die Slave Processe keinen eigenen Speicher, sondern "zeigen" nur auf die server.exe ?

Sonnst kann ich mir das nicht erkären, weil wenn man den Speicher der server.exe sowie der slave.exe addiert kommt man auf einen anderen Wert.

Wir hatten vor kurzem die Datenbank komplett (incl. der Dienste) neu aufgesetzt, dabei hatte ein Kolege den Chache Wert erhöht, so das sich nach meiner obigen Berechnung mehr Speicher genutzt wurde als Physikalisch verfügbar war.

Das Ergebnis war, das sobald die User aktiv waren, wir massiv Probleme an den Client's hatten z.B. stürtzten die Clients beim Aufruf des Testbericht (Buchhaltung) ab.

Wir haben dasnn den chache Wert entsprechend verringert und siehe da keine Probleme mehr.

Nach Deinem Einwand bin ich jetzt etwas verunsichert, kann irgendewer was zu der Problematik sagen ?

So ich hab jetzt nochmal google befragt.

Dabei findet man unter anderem das hier http://www.mibuso.com/forum/viewtopic.php?p=7547#p7547
Demnach nutzen alle Slave Processe den selben Speicher, der Taskmanger zeigt das aber nicht richtig an.

Kann das jemand bestätigen ?

Der Slave Prozess wird aktiv, wenn der Commit Cache verwendet wird ( x Anzahl der Datenbankteile , zuätzlich ein slave.exe als "Mutter", der die anderen zuammenbindet). Der tatsächliche genutzte Speicher ist abhängig von den Transaktionen, die auf die Platten geschrieben werden müssen und lässt sich aus dem Taskmanager nicht entnehmen.

wenn wir von einer nativen Datenbank reden ist der DBMS Cache auf jeden Fall schonmal sehr klein.
Zum Vergleich: auf unserem Server mit nur 2GB RAM steht der DBMS Cache auf 900.000KB, Commit Cache ist aktiviert.

Das war auch das Problem. Schade eigentlich...da ich die Installation von meinem NAV-Partner durchgeführen ließ.
Trotz Nachfrage wurde die Notwendigkeit eines größeren DBMS-Cache verneint.

..da ich die Installation von meinem NAV-Partner durchgeführen ließ.
Trotz Nachfrage wurde die Notwendigkeit eines größeren DBMS-Cache verneint.

Dafür gibts ja das Forum. (Oder andere NAV Partner, welche sich besser auskennen)

[Timo Lässer]

Man muss immer wieder davor warnen aus Tests die man mit der Cronus-DB mit kleinen Datenbanken durchgeführt hat, Rückschlüsse auf die Performance eines Systems zu schließen. Ein in der Cronus durchgeführter Filter ohne passenden Schlüssel hat in der Regel keine Auswirkung auf dessen Funktion, filtert man z.B. die Artikelposten auf eine Artikelnr. und hat nach Lfd.-Nr. sortiert, kann das bei 1Mio. Datensätzen schon mal ein viertel Stündchen dauern. Genauso ist es mit dem Cache, bei der Cronus hat der eigentlich keine Auswirkungen, bei einer Datenbank mit großen Posten- Tabellen hat er allerdings, wie jetzt wieder festgestellt, sehr große Auswirkungen.

Gruß, Fiddi

Zuletzt geändert von Timo Lässer am 24. Februar 2010 22:08, insgesamt 1-mal geändert.