NAV 4.0 mit 8-Prozessorigem 64-Bit SQL 2005 Ent. Server

Guten Morgen

Wir haben seit einigen Tagen einen neuen Server zu Testzwecken in Betrieb.

Features:
64 Bit Server mit 8 Prozzis
64 Bit Windows
SQL-2005 ENT

Scheinbar werden von Navision aber nur 4 Prozessoren genutzt... Gibt es da ev. eine 64-Bit Version von Navision, die sowas unterstützt? Oder müssen wir da ev. etwas umstellen in der DB?

Ist nicht mein Fachgebiet!
Ist es nicht so, das bei einem SQL-Server die Prozessoren entsprechend Lizensiert sein müssen!
Habt ihr eine entsprechende Lizenz?

Letztendlich nutzt der SQL-Server und nicht Navision die Prozessoren?!
(Navision ist auf der Clientseite die Anwendung)
Gruß Mikka

Zusätzlich zur Info von Mikka->

Am SQL-Server kann man einstellen wie viele Prozessoren pro SQL-Server Instanz verwendert werden sollen. Stellst du in den Server Properties im Mgmt. Studio ein.

mfg
Jürgen

Scheinbar werden von Navision aber nur 4 Prozessoren genutzt

Wie kommst Du denn auf diesen Verdacht?

Wenn im "Task Manager" 8 CPU angezeigt werden, dann kennt Windows die 8 Prozessoren. Welche Edition von Windows Server wird denn verwendet? "Standard" Editionen unterliegen i.d.R. einigen Einschränkungen, für 8 CPU sollte es schon eine "Enterprise Edition" sein ...

Und wie Jürgen schon gesagt hat: Am SQL Server selbst kann man die CPU Nutzung/"Affinity Mask" pro Instanz setzten ... per "Default" werden hier aber normalerweise immer alle verfügbaren CPU genutzt ...

Danke mal für die Rückmeldungen...

Wir nützen W2003 Enterprise. Auch auf der Instanz werden alle verfügbaren prozessoren angesprochen.
Wir haben jedoch noch mit keiner Aktivität in Navision mehr als 2 Prozzis zum ansprechen gebracht via Task Manager. Das müsste doch verteilt werden *grübel*

Suche gerade ein Tool, welches einen Stress-Test durchführt, bin aber noch nicht für SQL 2005 fündig geworden...

Nun, i.d.R. ist die CPU Auslastung mit NAV eher gering; abhängig von der Anzahl der aktiven Prozesses (Workerthreads) und des Transaktionsvolumens.

Um 8 CPU auch nur annähernd ins Schwitzen zu bringen braucht es schon einiges an Last!!!

Der Grund dafür ist, daß die Abfragen in NAV so simpel sind, daß SQL Server kaum eine Chance hat diese mit parallelen Threads zu bearbeiten hat.
Der "Max. Degree of Parallelism" sollte in dem Fall auf 4 gesetzt werden (halbe Anzahl der CPU; Threshold bleibt bei 5).

Würde man nun Teile z.B. auf andere Dateigruppen auslagern - z.B. die Indexe - so würde man den Grad der Parallelität erhöhen und die CPU mehr auslasten ...

Was den "Stress Test" angeht: "I/O Meter" (http://www.iometer.org/) ist zwar ein Festplattenbenchmark, man kann damit aber auch die CPU ein wenig "anwärmen".

Gruß,
Jörg

Hallo zusammen.

Habe mal ne EINFACHE frage :

Wir wollen einen neuen Terminalserver bauen. 64 bit Server + OS 2k3 64 bit.
Bekomme ich da mein Nav für die Terminalserveruser ans fliegen?
Hat das schonmal jemand gemacht?
Danke für eure Antworten.

Hallo,

ich hätte eine Frage zur Euren Anforderungen :

Was ist der Grund für die Konfiguration von :

64 Bit Server mit 8 Prozzis ???

Auch ich habe hier mal das Thema angesprochen. Fazit war dann :

a) dass Dynamics (noch) nicht 64Bit tauglich ist
b) das "Nadelöhr" nicht der Prozessor sondern das I/O System ist
c) die Festplatten sehr stark für die Geschwindigkeit (bei SQL)
verwantwortlich sind

Ich habe mich dann für ein Fiber-System entschieden, bei welchem die Platten sowie RAID sehr performant sind (z.B. kleine 76 GB Platten mit 15K) ! Weiter ein Raid-Controller mit sehr hohem Druchsatz. Dann auf Basis von "Blade" bei welchem die Server untereinandr (SQL-Server + Terminalserver) ebenfals mit Fiber 4 GB verbunden sind.

Grüße
Alwin

Hallo Albe

zu deiner Frage:

Wir haben von einem anderen unternehmen gehört, dass Axapta durch einen 64-Bit Server bei der Verarbeitung um einiges schneller wurde

Danach haben wir uns entschieden, einen 64-Bit Server mit Navision zu versuchen.

Wir liessen dann einen relativ grossen Batch laufen, welcher auf dem 64-Bit Server 19 Stunden lief. Auf dem jetztigen 32-Bit Server lief das ganze dann 43 Stunden (Gut, das wird nicht täglich oder wöchentlich/monatlich gemacht, aber man sieht hier schon gut, dass in diesem Fall die Einsparung ca. 50% ausmacht).

Da wir die Lagerregulierung bei jeder Buchung eingeschaltet haben, kann es bei der jetztigen Systemarchitektur lange dauern (bis zu einer Minute), bis jemand anderes buchen kann. Dies wird nun durch den neuen Server um mind. 50% verschnellert...