Denksportaufgabe Performance

Hallo alle,

bin neu hier bzw. war bis jetzt nur Leser...
Und habe jetzt gleich einige schwere Denksportaufgaben:


wir arbeiten mit folgenden System

Navision 4.0 SP1 - native DB
Basis ist ein 2.6-System (bzw. 2.0x); es wurden nur techn. Upgrades durchgeführt
Größe 80 GB, beleget ca. 46 GB
max. 120 User, davon ca. 90-100 parallel
geschätzte Individual-Programmierung: >95%
640 MB Commit Cache
Betriebssystem: Win2000-Server

Hardware:
2x Xeon 3,2 GHz
4 GB RAM
1x RAID1 80 GB S-ATA für das Betriebssystem
2x RAID1 80 GB S-ATA für sonstiges

2x 2-Kanal-SCSI-Controller
16x RAID1 36 GB SCSI



Und nun die Denksportaufgaben:

1)
Im April 2006 sind wir von Nav 2.6 auf unser heutiges System umgestiegen. Seitdem haben wir Performance-Probleme, die nur z.T. reproduzierbar sind.

Beispiel:
Ein Job, der normalerweise ca. 15-20 Minuten benötigt, braucht ohne erkennbaren Grund plötzlich mehrere Stunden. Wird der Job vorher abgebrochen und neu gestartet, ist er i.d.R. in ca. 5 Minuten fertig (vermutlich weil alle Daten noch im Cache sind). Die zu berechnenden Datenmengen sind die gleichen wie sonst. Die Dauer ist nicht abhängig von anderen angemeldeten Usern (das Phänomen tritt sowohl tagsüber bei 100 Usern, als auch nachts bei ein oder zwei Usern auf). Auf einem separaten Testserver habe ich den Job mal über mehrere Tage jede Stunde laufen lassen. Auch hier laufen die Jobs mal in 20 Minuten, mal über mehrere Stunden...


2)
Auf einem alten Reserve-Server habe ich kürzlich per Hotcopy eine Kopie der Datenbank eingespielt. Dabei habe ich die 16 DB-Dateien auf 16 Partitionen von nur 8 Festplatten kopiert (ist ja nur für einen Test). Anschließend habe ich einen Job laufen lassen, der auf dem Hauptserver ca. 24 Stunden benötigt hat. Auf dem viel schlechteren Server ist der gleiche Job mit der gleichen Datenbasis in nur 15 Stunden gelaufen. Ich habe den Tipp bekommen, daß das an fragmentierten DB-Dateien des Hauptservers liegen soll. Kann das sein?

3)
Wie man oben sieht, haben wir bei der Hardware schon mehr oder weniger das Ende der Fahnenstange erreicht. Trotzdem wird unser System nicht nur bei den o.g. Jobs zunehmend langsamer, sondern nach und nach merken die User auch immer mehr davon. Da aus firmenpolitischen Gründen ein Umstieg auf SQL nicht in Frage kommt, stehe ich vor der Frage, wie das System in Zukunft zu optimieren ist.
Bisherige Ideen:
- 16x RAID10 (je 8 HDDs)
- umfassende Optimierungen in der Programmierung des System, z.B. beim Erfassen von Bestellungen und VK-Aufträgen, da hier viele Trigger 50-fach durchlaufen werden


...und jetzt bin ich für alles offen


offene Grüße,
JürgenT

wer für alles offen ist, kann nicht ganz dicht sein

Hallo!

Willkommen bei "MSDynamics.de"!

OK, here we go ...

Wenn der Server über 4 GB RAM verfügt, dann sollte dem NAV Server auch das Maximum von 1 GB DBMS Cache zugestanden werden (Commit-Cache = TRUE).

Kann man folgende "Bottlenecks" ausschließen:
Netzwerkproblem? DB Server nicht dediziert; andere Dienste - "Ressourcenkiller" - gestartet?

Zum Disk-Subsystem:
16 x RAID1 36GB heißt also 32 Spindels, je zwei zu einem physikalischen Laufwerk RAID1 konfiguriert; je Laufwerk 1 DB Datei!?
Eigentlich OK so, aber wenn die Performance nicht ausreicht, dann wird ein Wechsel von RAID1 auf RAID10 den meisten Erfolg bringen; je mehr Spindels im Stripe desto besser. Eine Aussage von MS lautet dazu: "... with doubling the number of disks one could increase the performance for about 100% ..." (natürlich unter Vorbehalt).

Mit "native" war's das dann auch schon mit Plattform-bezogener Optimierung, alles weitere kann nur im C/AL Code und den Geschäftsprozessen 'rausgeholt werden ...

Was den "Optimierungsgrad" der DB angeht: Nun, meine Erfahrungen mit dem "Table Optimizer" (nur native DB!!!) waren bisher gut; hier im Forum wurde aber schon geposted, daß eine Optimierung eher kontra-produktiv wäre ... "der Server braucht das Chaos" stand hier im Raum, bin also nicht sicher, ob's auch eurer DB gut täte ...

Gruß,
Jörg

hier noch einige weitere Fragen/Tips:
- ihr habt doch bestimmt bei den Laufzeit-Updates ein Backup und Restore der kompletten DB durchgeführt oder?
- beim Erweitern der DB entweder alle DB-Teile gleichmäßig erweitert oder ebenfalls Backup und Restore durchgeführt.
- laufen auf dem DB-Server noch andere Programme/Server?
- Hardwarefehler bereits ausgeschlossen (manchmal werden Fehler durch Software auf höherer Ebene abgefangen, aber mit Performanceverlust)
- wurde das Netzwerk bereits durchgemessen?
- wie laufen die zeitaufwendigen Jobs im Standalone-Betrieb?
- wie alt sind Controller und Festplatten? (am besten alle 4-5 Jahre erneuern)

Ich sehe gerade, daß ihr 4.0 SP1 einsetzt. Warum nicht 4.0 SP3?

erstmal danke für die schnellen Antworten...

Jörg:
- auf dem Server läuft nur der Navision Server Dienst; es sind weitere Nav-Dienste mit leeren Datenbankeninstalliert , die aber erst aktiviert werden, wenn die Datenbank "crasht"
- für den Cache habe ich mal Empfehlungen von 2 bis 4 MB pro User gelesen (also 250 bis 500 MB), werde ihn aber demnächst mal auf 1 GB hochsetzen
- Ressourcenkiller-Dienste: werde ich mit dem Kollegen mal checken
- Netzwerkproblem: der Server ist seit Januar mit 2 GBit direkt an unseren Hauptswitch angeschlossen, der Server, auf dem der Nav-Client für die o.g. Jobs läuft ebenfalls; die Umstellung von 1 GBit auf 2 GBit hatte keine Auswirkung (hatte unser Cisco-Guru auch so prophezeit )
- Disk-Subsystem: ja, 32 HDDs. Wir haben den Server ohne unser NSC beschafft; ein Restore dauert ca, 1,5 Stunden (unser NSC glaubt mir das nicht )
- Table Optimizer: Nach einem Restore sind die Tabellen (glaube ich) auch optimiert; das System braucht dann immer einige Tage, bis es wieder so schnell ist wie vorher. Die beiden größten Tabelle sind Sachposten und Artikelposten (16 Mio bzw. 4,4 Mio Einträge). Auf beide Tabellen wird eher nicht sequentiell zugegriffen, sodaß eine "nicht optimierte" Verteilung auf alle DB-Dateien in der Praxis schneller ist.

jim:
- Hardwarefehler: da auf dem gleichen Server auch schon das 2.6 lief und die Performance erst mit 4.0 runterging, schließe ich einen Hardwarefehler mal aus.
- alle DB-Dateien sind gleich groß
- keine anderen Programme (pcAnywhere ist zwar installiert, wird aber nur im Notfall aktiviert)
- Netzwerk: siehe oben
- da die Jobs größtenteils am Wochenende laufen, laufen sie im "Quasi-Standalone-Betrieb"; i.d.R. sind am Wochenende nur noch drei weitere Clients aktiv (Schnittstelle zum Logistiker, EASY-Archiv, Datensicherung per ExpandIT, das Beenden dieser Clients hatte keine Auswirkungen)
- Controller und Platten sind seit März 2005 in Betrieb
- SP1 weil:
- bei der Umstellung war SP2 erst ein paar Tage alt
- die Umstellung der Clients (ca. 350 Workstations) ist reine Handarbeit (ich will das die Performance unter SP3 auf einem geeigneten Testserver prüfen, bevor ich umstelle)

was meinst Du mit Laufzeit-Updates?

ist wieder viel Text - ist aber auch eine große Datenbank

Gruß
JürgenT

Hi!

Tja, da bleiben ja leider nicht viele Ansatzpunkte übrig ...

Meines Erachtens bleibt nur
A) Plattform-seitig: Disk-Subsystem erweitern auf RAID10
B) C/AL Code Re-Design

... oder

P.S.: Mit "Laufzeit-Updates" ist die Aktualisierung der Client/Server Programme (exe, dll, etc.) gemeint, OHNE Update der Applikations-Objekte.

Jörg,

ich hatte schon so etwas befürchtet und hätte dann noch eine Zusatzfrage bezüglich der Hardware-Aufrüstung:

Da bei einer Erweiturung des Plattensystem zwangsläufig auch der Server selbst ersetzt würde, habe ich schon mal über die Prozessoren nachgedacht. Der Navision Server-Dienst nutzt bekanntlich nur einen Prozessor. Zwei Prozessoren sind dennoch nützlich, da dann einer den Nav-Dienst bedient und der andere den Rest (Betriebssystem, Netzwerk etc.) bedienen kann.

Daher würde ich folgern, daß eine Zwei-Prozessor-Maschine mit zweimal 3.2 GHz schneller ist als eine Dual-Core-Maschine mit 2.6GHz. Im Hardware Guide wird allerdings eine Dual-Core-Maschine empfohlen. Kann ich dem Hardware Guide vertrauen?

Und davon unabhängig: stimmt es, daß für einen Nav-Server die AMD-Opteron die bessere Wahl sind?


hardware-Grüße
JürgenT

Hi!

Nun, leider habe ich keine Erfahrungen mit "nativen" Servern und DualCore CPUs; lediglich mit SQL Servern ... hier aber durchwegs positive Erfahrungen (allerdings unterstützt SQL Server "multi-threaded-processing")!
Ich glaube schon, daß DualCore CPUs auch mit einem nativen Server gut funktionieren ... aber wie gesagt: ich habe selbst keine Praxiserfahrung damit.

Was Opteron vs Xeon angeht: Ich kann nur soviel sagen, daß beides gut funktioniert, bin also bei keinem der Prozessor-Typen auf Schwierigkeiten gestossen. Hier wäre ein "Vergleichs-Benchmark" interessant ...

Hi,

Du hast beschrieben, dass Du viele Batchjobs laufen lässt. Nun gehe ich mal davon aus, dass die auch richtig was in der Datenbenk rausreisen. Hast Du schonmal daran gedacht, dass es den Commitcach so voll haut das die Maschine Swapt? Das kann natürlich schon 1 Client schaffen, die Hardware soll ja ausgenutzt werden.
Ich hab gute Erfahrungen damit gemach alle 1000 Updates oder Inserts ein Comit einzufügen und im Extremfall sogar ein Sleep angefügt.
Was nun passiert ist klar, die Maschine bekommt die Gelegenheit Transaktionen in die DB zu schreiben bevor der Cach voll ist.

Ansonsten halt Dich an 1 GB Cach und soviel Platten wie Dein Distributor liefern kann. Versuch die dann möglichst noch an viele Controller zu hängen, die natürlich auch Cachen sollten (Battary Backup nicht vergessen).

@Stryk

Wie kann ich den Füllstand eines bestimmten Keys abfragen bzw. ändern?

der MOD

@Stryk
Wie kann ich den Füllstand eines bestimmten Keys abfragen bzw. ändern

Ähm ... reden wir über den aktuellen Thread? Mit einer "nativen" Datenbank gibt es so etwas wie "Füllfaktoren" nicht ...

Mit SQL Server, z.B. via

Code:

SELECT * FROM sysindexes

Hier steht der FF in der Spalte "OrigFillFactor". Ändern kann man den FF auf verschiedene Art:

Code:

CREATE INDEX ... WITH DROP_EXISTING, FILLFACTOR =
ALTER INDEX ... FILLFACTOR =
DBCC DBREINDEX

oder "zu Fuss" via Enterprise Manager / Management Studio.

Aber: der Fill-Faktor ist nur ein logischer Richtwert der lediglich bei "Page Splitts" oder "Re-Indizierung" erreicht werden kann und sagt nix über den tatsächlichen "Füllstand" der Seiten aus. Diese tatsächliche Belegung kann man via DBCC SHOWCONTIG ermitteln.

Gruß,
Jörg

Mal eine evtl. etwas naive Frage: habt ihr die native Datenbank einfach innerhalb vom 4.01 client konvertiert?
War es denn nicht möglich einfach eine Datenübernahme von der alten DB in eine neue DB, erstellt unter 4.01, zu machen? Oder war das euch zu teuer?

Nun, "technische Upgrades" sind 1) immer empfehlenswert um von C/SIDE Neuerungen zu profitieren und 2) kostengünstig, da die Standard-Releases im Wartungsvertrag enthalten sind. Das Verfahren ist hierbei tatsächlich einfach nur auf die DB mit dem neuen Client zuzugreifen um sie zu konvertieren (etwas umständlicher ist die Option "Backup alt, Restore neu").

Dem gegenüber steht ein vollständiger Release-Upgrade, also auch ein Upgrade der Applikationsobjekte. Dies ist mit wesentlich mehr Aufwand verbunden: nicht die Datenübernahme ist das Problem, sondern die Integration der kundenspezifischen Anpassungen!

Eine Option, die auch öfter genutzt wird ist folgende: Regelmäßige technische Upgrades; kein Upgrade der Applikation sondern alle 3 bis 5 Jahre eine Re-Implementation: Ein System wird von Grund auf neu erstellt; es werden nur Anpassungen übertragen die notwendig sind (neue Standard-Funktionalität nutzen!); die Daten werden neu übernommen (Datenmüll entsorgen).
Dies ist zwar die aufwendigste Methode eines Upgrades, hat aber den Vorteil das das System schlank bleibt, nah am Standard ist und ständig besser wird (man lernt ja aus vergangenen Fehlern).

Äh, ich bin 'n bischen vom eigentlichen Thema abgekommen, sorry

Nur für diejenigen, die ein rein technisches Upgrade planen:

Das Verfahren ist hierbei tatsächlich einfach nur auf die DB mit dem neuen Client zuzugreifen um sie zu konvertieren (etwas umständlicher ist die Option "Backup alt, Restore neu").

Vorsichtig, bei Version Nr. 1 werden dabei die Systemtabellen nicht mit konvertiert und du profitierst dadurch nicht von evtl. Fehlerkorrekturen in diesem Bereich.

@mod

Der Commitcache sollte nicht das Problem sein, weil:
1. bei den längsten Jobs erfolgt nach jeder Berechnung ein COMMIT
2. die Auslagerungsdatei habe ich quasi deaktiviert
3. der Commitcache war mal eine Weile versehentlich auf 64 MB eingestellt (64000 KB; die Kollegen hatte einfach eine Null vergessen), und die Jobs liefen trotzdem nicht länger als sonst

1 GB Cache ist inzwischen eingestellt - ohne erkennbares Ergebnis

Für die 16x RAID10 schwebten mit eigentlich 8 Platten pro RAID10 vor. Leider hat unser Server-Lieferant standardmäßig keine Server im Angebot, in die ich 8 (oder gar 16) Controller einbauen könnte. Ich forsche aber weiter in die Richtung...

Controller-Cache? Für die NAV-DB soll der Controller-Cache doch immer deaktiviert werden. Oder hat sich das irgendwann geändert?

@Lord_British
Nee, nee, wir haben nicht per Client konvertiert, sondern Datensicherung in 2.6, danach Datenrücksicherung in 4.01 (wieso sollte das zu teuer sein?)


Gruß
JürgenT

Nein, nein ich hab die native Datenbank immer mit Controllercach laufen lassen. Ohne ist es ja gähnend langsam.
Also mein Rat, sorg für eine hochwertigen Controller mit viel Cach (512 MB ist aktuell) und sorg weiterhin für eine ausreichende USV.
Der Controller muss über Batary Backup verfügen. Selbst wenn die Maschine abbricht hält der Controller die Daten.
Mei Tipp: HP Smart Array 6400 2 Kanal mit möglichst externer MSA 30 (externe SCSI Dose für 12 Platten) auch denkbar eine MSA 30 pro Controler Kanal.
Ich hatte mit 40 aktiven Usern auf einer 30 GB Datenbank unterteilt in 4 Kanäle/Slices sehr gute Erfahrungen.

Ob man Controller Cach muss jeder für sich entscheiden, aber ich kenne keinen der ihn nicht verwendet.

Controller-Cache? Für die NAV-DB soll der Controller-Cache doch immer deaktiviert werden.

Der Meinung bin ich auch. Zumindest ist das das mir letztbekannte Statement von Microsoft.

Ob man Controller Cach muss jeder für sich entscheiden, aber ich kenne keinen der ihn nicht verwendet.

Also die meisten die ich kenne, haben den Controler-Cache nicht eingeschaltet, aus dem Grund, weil es Microsoft nicht empfiehlt.

Gruß, Marc

Hallo,

also schauen wir nochmal in die heilige Doku (Installation & System Management:Microsoft® Business Solutions–Navision® Database Server) und was steht da auf Seite 132 - Ich zitiere:

Warning
Do not use the write-back or lazy-write caching systems that are built into your hard
disk controller unless the disk controller has a battery backup.

Da das hier ein deutschsprachiges Board ist übersetze ich auch gleich:
Benutze kein Cach, wenn Dein Controller kein eigenes Battarie Pack hat.

In dem Stil sind alle Navision Dokus geschrieben. Wenn die schreiben "wenn Du kein Battary Backup hast darfst Du nicht" heißt besorg Dir ein Battary Backup und Cach!

Die Daten die sich im Cach eines vernüpftigen Controllers befinden, sind genauso sicher wie auf Platte!

Ansonsten wäre ein Commit Cach ja auch gefährlich - Was er auch ist! Aber was solls, den benutzt auch jeder. Ein Risko muss kalkulierbar sein, dann kann man es auch eingehen.

@mod
die Hardware ist knapp 2,5 Jahre alt, wir haben zwei 2-Kanal-Controller mit jeweils 1 GB Cache und Batterie

Normalerweise habe ich den Write Cache nur aktiviert, wenn ich neue, leere DB-Dateien erzeuge. Das geht dann deutlich schneller (der NAV-Server-Dienst ist dann deaktiviert).

Ich habe auch schon einige Male unfreiwillig den aktivierten Write Cache getestet. Bei den langen Jobs habe ich dabei noch keinen Performance-Gewinn feststellen können. Wie sich das im täglichen Betriebs verhält, habe ich noch nicht getestet.

Grüße,
JürgenT

@Jürgen

las Dich nicht verunsichern in der Doku steht ganz klar das der Controller Cach eingeschaltet sein darf. Ich hab diese Konfiguration 7 Jahre mit verschiedenen Version laufen gehabt. Frag mal Dein Solution Center.

Mit den Cach Einstellungen kann noch spielen. Standard ist meistens 50 % Cach für lesen und 50 % Cach für schreiben. Und das was der Controller da verarbeitet sind Blöcke, ob das eine Datenbank ist, oder Word Dokumente ist völlig egal. Diese Einstellungen kann man im Online Betrieb vornehmen.
Danach muss der Job schnell gehen, oder die läuft der Commit Cach voll. Dann siehe oben.

Wenn das mit dem Controller Cach nicht hilft, soll mich der Blitz beim scheißen treffen.

Damit wir uns nich falsch verstehen liste ich nochmal die Grundparameter auf:

Navi Dienst: cache=1000000 (ist maximum 1 GB), commitcache=yes
Controller: Schreib/Lesecach alles was geht (prüfen ob Battarien vorhanden oder wenigstens noch in Ordnung)
Aufteilen der Datenbank in möglichst viele Spindeln (Raiddevices) an möglichst vielen Controllerkanälen

Wem diese Einstellungen zu gefährlich sind sollte daran denken, dass wir Datenbankadministratoren sind, keine Kindergärtner. Also umreise ich noch schnell unseren Berufsstand:
Wir frühstücken Krampen nicht Müsli unzwar mit Tabasco anstatt Milch! Pitbulls beisen wir zurück.
Wir zeigen mit dem Finger auf Warmduscher während wir Wurst ohne Brot essen.
Wenn man als DBA was werden willst, musste Junk unter den Tisch saufen und Möllemann im freien Fall überholen.

;) Spass muss sein

mod

@ JürgenT

Hallo, ich habe da ähnliche Probleme. Unsere DB ist 40GB groß und zu 70% gefüllt. Nun haben wir uns einen

neuen Server zugelegt und der ist wesenlich langsamer im ZUgriff und Restore.

Navision 4.0 SP1 - native DB
Basis ist ein 3,70-System, es wurde nur das techn. Upgrade durchgeführt
22 User, davon ca. 90-100 parallel
1000 MB Cache
Betriebssystem: Win2003-Server 4GB RAM

Hardware:
XeonDualCore 3,2 GHz Fujitsu Siemens RX300
4 GB RAM
1x RAID1 146GB@15000 ScSi für das Betriebssystem
1x 1-Kanal-SCSI-Controller
3x RAID10 a 73GB SCSI@15000 im Fujitsu Siemens FX40 FiberCat
DB in 3 Teilen, 1 Teil je Raid10 = 12 Spindels

Nun ist die Frage, warum dauert es bei so einem guten Server länger die DB aufzubauen
und das Backup einzulesen als auf mehrern getesteten XP-Desktop Rechnern?

_____________________Server______XP
Erstellung der DB_______ 35min______9min
Einlesen der DB_________34min ______6min
Aufbau der Schlüssel____154min ____119min
Gesamt Unterschied_____223min____134min

Umbennen von Artikeln____32min_____25min


Der Unterschied bei den Rechnern besteht ja im Betriebssystem und CPU.
Ist Xeon nicht geignet? Die Speichersysteme sind ja im Server eindeutig besser.
Im Windows Test komme ich da auf Datendurchsatz von ca 380MB/S gegenüber dem Desktop
von 89MB/s. Das müsste eigentlich einfach nur so "flutschen"?

Oder gibt es Serverseitig Einstellungen hinsichtlich Navision Native Systemen?
Ich weiß nicht mehr weiter. Bin für jeden Tip dankbar.

PS: Möchte auch ein schnelleres Restore. 1,5h sind ja ein Traum.

Grüße
Andi

Hallo Andi,

verstehe ich das richtig? Ihr habt jetzt einen Server in der o.g. Konfiguration mit Server-Betriebssystem im Einsatz; und vorher hattet Ihr als Betriebssystem WinXP (pro?) ?

Welche Hardware hatte der alte Rechner?


ansonsten:

- CommitCache ist aktiviert?
- Spielst Du die Datensicherung mit oder ohne Nav-Serverdienst ein?
- Wo läuft der Nav-Client, der die Datensicherung wieder einspielt (auf dem Server oder auf einem anderen Rechner) ?


Die großen Unterschiede beim Erstellen der DB und beim Einlesen der Datensicherung lassen darauf schließen, daß der write cache beim RAID-Controller und/oder den Platten aktiviert ist. Darüber wurde ja weiter oben schon mal diskutiert.

Wenn Du noch die Möglichkeit zum Testen hast, dann probiere auch mal die Variante mit 6x RAID1 statt 3x RAID10. Ich vermute, daß 6x RAID1 schneller ist, wenn auch wahrscheinlich nicht gravierend. Ich werde dazu allerdings demnächst selbst mal ein paar Performance-Tests machen (neuer Server mit 32 Platten für die DB wird gerade beschafft *grins* )

performante Grüße
JürgenT