Geschwindigkeitsbremse Identifizieren
Servus,
wir nutzen Sage 100 (Office Line 7.2) bei uns im Betrieb. Die Mitarbeiter beschweren sich seit Jahren darüber wie langsam das bearbeiten von einem Beleg etc. ist (ca. 30 Sekunden dauert es um einen beleg zu speichern). Das Problem ist genauso vorhanden um 23:00 wenn nur 1 Person arbeitet als um 16:00 wenn 20 dran arbeiten. Sage sowie unser Sage Partner sagen das dies sehr seltsam sei und behaupten es könnte an 3 dingen liegen:
1) PCs zu langsam (alles Windows 10 64bit PCs mit 256GB SSD, 16GB ram i7 - es wird nur Sage [läuft auf Access 32 bit] und Outlook verwendet ).
2) Netzwerk zu langsam (NetIO meldet 900mbit/Sekunde Durchsatz zwischen Client und Datenbank server), DHCP via SBS 2011.
3) Datenbank Server zu langsam (HP ProLiant DL385 G6, Windows 2008 R2, 32GB ram, 6x200GB Enterprise SSDs, Six-Core AMD Opteron 2431 - 2.4 Ghz)
Problem?
1) Denke die PCs sollte das schaffen...
2) Mehr als Gigabit geht nicht wirklich
3) Unser Sage Partner meint das der Server wohl zu langsam wäre um die Datenbank zu hosten. Der Server tuckert bei 10% CPU Auslastung daher und 60% Arbeitsspeicher Auslastung. Klar, ich kann jetzt einen zweiten CPU rein bauen (bzw. beide Ersetzen) oder gar einen neuen Server kaufen, aber ich verstehe nicht warum hier der Server es nicht schaffen sollte.
Gibt es ein Tool mit dem ich herausfinden kann was das Problem ist? Sage weiß nicht weiter und schiebt es auf unsere Infrastruktur.
Gerne gebe ich mehr Details zu PCs und Server - sagt einfach bescheid was dabei helfen kann.
Danke für eure Hilfe.
wir nutzen Sage 100 (Office Line 7.2) bei uns im Betrieb. Die Mitarbeiter beschweren sich seit Jahren darüber wie langsam das bearbeiten von einem Beleg etc. ist (ca. 30 Sekunden dauert es um einen beleg zu speichern). Das Problem ist genauso vorhanden um 23:00 wenn nur 1 Person arbeitet als um 16:00 wenn 20 dran arbeiten. Sage sowie unser Sage Partner sagen das dies sehr seltsam sei und behaupten es könnte an 3 dingen liegen:
1) PCs zu langsam (alles Windows 10 64bit PCs mit 256GB SSD, 16GB ram i7 - es wird nur Sage [läuft auf Access 32 bit] und Outlook verwendet ).
2) Netzwerk zu langsam (NetIO meldet 900mbit/Sekunde Durchsatz zwischen Client und Datenbank server), DHCP via SBS 2011.
3) Datenbank Server zu langsam (HP ProLiant DL385 G6, Windows 2008 R2, 32GB ram, 6x200GB Enterprise SSDs, Six-Core AMD Opteron 2431 - 2.4 Ghz)
Problem?
1) Denke die PCs sollte das schaffen...
2) Mehr als Gigabit geht nicht wirklich
3) Unser Sage Partner meint das der Server wohl zu langsam wäre um die Datenbank zu hosten. Der Server tuckert bei 10% CPU Auslastung daher und 60% Arbeitsspeicher Auslastung. Klar, ich kann jetzt einen zweiten CPU rein bauen (bzw. beide Ersetzen) oder gar einen neuen Server kaufen, aber ich verstehe nicht warum hier der Server es nicht schaffen sollte.
Gibt es ein Tool mit dem ich herausfinden kann was das Problem ist? Sage weiß nicht weiter und schiebt es auf unsere Infrastruktur.
Gerne gebe ich mehr Details zu PCs und Server - sagt einfach bescheid was dabei helfen kann.
Danke für eure Hilfe.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 334771
Url: https://administrator.de/forum/geschwindigkeitsbremse-identifizieren-334771.html
Ausgedruckt am: 26.12.2024 um 21:12 Uhr
18 Kommentare
Neuester Kommentar
tach auch...
wir nutzen Sage 100 (Office Line 7.2) bei uns im Betrieb. Die Mitarbeiter beschweren sich seit Jahren darüber wie langsam das bearbeiten von einem Beleg etc. ist (ca. 30 Sekunden dauert es um einen beleg zu speichern). Das Problem ist genauso vorhanden um 23:00 wenn nur 1 Person arbeitet als um 16:00 wenn 20 dran arbeiten. Sage sowie unser Sage Partner sagen das dies sehr seltsam sei und behaupten es könnte an 3 dingen liegen:
ihr habr ernsthaft die Access version, nicht die SQL ?... das ist gruselig
1) PCs zu langsam (alles Windows 10 64bit PCs mit 256GB SSD, 16GB ram i7 - es wird nur Sage [läuft auf Access 32 bit] und Outlook verwendet ).
das ist ok...
Problem?
1) Denke die PCs sollte das schaffen...
ja
habt ihr schon mal auf eine umstellung auf SQL gedacht ?
Neuer DB Server ?
Gibt es ein Tool mit dem ich herausfinden kann was das Problem ist? Sage weiß nicht weiter und schiebt es auf unsere Infrastruktur.
da werden die recht haben!
Gerne gebe ich mehr Details zu PCs und Server - sagt einfach bescheid was dabei helfen kann.
Danke für eure Hilfe.
gern
Frank
wir nutzen Sage 100 (Office Line 7.2) bei uns im Betrieb. Die Mitarbeiter beschweren sich seit Jahren darüber wie langsam das bearbeiten von einem Beleg etc. ist (ca. 30 Sekunden dauert es um einen beleg zu speichern). Das Problem ist genauso vorhanden um 23:00 wenn nur 1 Person arbeitet als um 16:00 wenn 20 dran arbeiten. Sage sowie unser Sage Partner sagen das dies sehr seltsam sei und behaupten es könnte an 3 dingen liegen:
1) PCs zu langsam (alles Windows 10 64bit PCs mit 256GB SSD, 16GB ram i7 - es wird nur Sage [läuft auf Access 32 bit] und Outlook verwendet ).
2) Netzwerk zu langsam (NetIO meldet 900mbit/Sekunde Durchsatz zwischen Client und Datenbank server), DHCP via SBS 2011.
hm...3) Datenbank Server zu langsam (HP ProLiant DL385 G6, Windows 2008 R2, 32GB ram, 6x200GB Enterprise SSDs, Six-Core AMD Opteron 2431 - 2.4 Ghz)
das ist nicht zufällig der SBS2011 ?????Problem?
1) Denke die PCs sollte das schaffen...
2) Mehr als Gigabit geht nicht wirklich
doch 3) Unser Sage Partner meint das der Server wohl zu langsam wäre um die Datenbank zu hosten. Der Server tuckert bei 10% CPU Auslastung daher und 60% Arbeitsspeicher Auslastung. Klar, ich kann jetzt einen zweiten CPU rein bauen (bzw. beide Ersetzen) oder gar einen neuen Server kaufen, aber ich verstehe nicht warum hier der Server es nicht schaffen sollte.
als erstes mochte ich dir sagen, wenn dein DB Server der SBS2011 ist, ist er kaum noch als SQL bzw. DB für eine Access DB geeignet!habt ihr schon mal auf eine umstellung auf SQL gedacht ?
Neuer DB Server ?
Gibt es ein Tool mit dem ich herausfinden kann was das Problem ist? Sage weiß nicht weiter und schiebt es auf unsere Infrastruktur.
Gerne gebe ich mehr Details zu PCs und Server - sagt einfach bescheid was dabei helfen kann.
Danke für eure Hilfe.
Frank
Ich tippe auf eine unvorteilhafte DB Konfiguration. Wurde die DB durch das Programm eingerichtet und konfiguriert oder wurde da selbst an den Tabellen rum gewerkelt? Läßt sich der Speichervorgang im Programm debuggen oder die Aktion nur im SQL Management Studio imitieren?
Das Netzwerk könnte noch Probleme im Berreich DNS haben aber du sprichst von Performance Problemen nur beim Speichern von Belegen (liegen die in der Datenbank?).
PS: Sry habe das mit Access überlesen. Access ist vermutlich überfordert.
Das Netzwerk könnte noch Probleme im Berreich DNS haben aber du sprichst von Performance Problemen nur beim Speichern von Belegen (liegen die in der Datenbank?).
PS: Sry habe das mit Access überlesen. Access ist vermutlich überfordert.
Zitat von @cymode:
Hi,
Das Frontend läuft über MS Access Runtime. Auf dem Datenbankserver läuft SQL 2008 R2 für die Sage Datenbank.
und der SQL Server hat wieviel Ram zugewiesen bekommen ?Hi,
Das Frontend läuft über MS Access Runtime. Auf dem Datenbankserver läuft SQL 2008 R2 für die Sage Datenbank.
da sollten bei etwa 20 leuten etwa 16- 28 GB drin sein....
Service Pack ?
CPU ?
was sagt das SQL Monitoring ?
CPU, RAM, HDD Schreibrate ???
wobei
Über den SBS 2011 läuft nur E-Mail, Benutzerverwalung und die Netzwerk Config - es ist ein anderer physischer Server.
ok..Merci.
Zitat von @cymode:
Hi,
Die DB wurde von Sage bei der Installation bzw. Migration konfiguriert. Vor der Migration auf das neue System war es bereits langsam. Es wird uns seit Jahren gesagt das wir noch mal €10t ins neue Sage investieren sollen und dann wäre es wahrscheinlich schneller. Aus 'wahrscheinlich' wird dann '0 Verbesserung'.
das kann gut sein... in der Regel ist der Server etwas überfordert (HP ProLiant DL385 G6) ist eben keine Rakete... und deine 6x200GB Enterprise SSDs bringen warscheinlich die Daten nicht mal über den Bus...Hi,
Die DB wurde von Sage bei der Installation bzw. Migration konfiguriert. Vor der Migration auf das neue System war es bereits langsam. Es wird uns seit Jahren gesagt das wir noch mal €10t ins neue Sage investieren sollen und dann wäre es wahrscheinlich schneller. Aus 'wahrscheinlich' wird dann '0 Verbesserung'.
welches Raidlevel ?
welcher Controller ?
In Sage selbst lässt sich nichts Debuggen. Den Speicherablauf müsste man im SQL Management Studio Imitieren können.
Performance Probleme gibt es bei Sage reichlich. Sage braucht 5 Sekunden beim aufbauen vom Bildschirm wenn man im Hauptmenü z.B. 'Artikel' oder 'Adressen' auswählt. Das ist zwar ätzend, aber bei langem nicht so nervend wie 30 Sekunden darauf zu warten das Belege bearbeitet werden. Eventuell bedeutet dies aber das es Probleme bei der DB Konfiguration allgemein gibt? Ich weiß leider nicht wie schnell es normalerweise reagieren sollte.
aus dem bauch sage ich mal... es könnte an der SQL config liegen.. magst die mal die running Config posten ?
nur mal so...
2 flotte Intel 6 Core CPU´s 32-64 GB Ram... PCI-e v3 und eine Intel NVE 3600
das Systen ordentlich eingerichtet... und die Belege fliegen über den TFT
Frank
Hallo,
ich würde mal testweise bei einem PC die MTU Size auf 1468 Bytes stellen.
Gruß,
Jörg
ich würde mal testweise bei einem PC die MTU Size auf 1468 Bytes stellen.
Gruß,
Jörg
moin
Raid 1
HP Smart Array P410/1GB FBWC 6Gb/s RAID Controller
nun... der schnellste ist das nicht...
Frank
Raid 1
HP Smart Array P410/1GB FBWC 6Gb/s RAID Controller
Wie kann ich die Config auslesen? Konnte darüber online nichts finden - nur Beiträge zwecks Migration.
ich dachte eigentlich mehr an sowas...Grundeinstellungen SQL-ServerFrank
Hi,
welche SQL-Version wird denn genau eingesetzt?
Bei der Express werden nur maximal 1GB Ram genutzt. Die Standard nutzt schon maximal 64 GB.
https://msdn.microsoft.com/de-de/library/ms143685(v=sql.105).aspx
Gruß
welche SQL-Version wird denn genau eingesetzt?
Bei der Express werden nur maximal 1GB Ram genutzt. Die Standard nutzt schon maximal 64 GB.
https://msdn.microsoft.com/de-de/library/ms143685(v=sql.105).aspx
Gruß
Die Ursachen können recht vielfältig sein.
Was hilft, ist zunächst einmal auszuschließen, dass die bereitgestellte Systemperformance unzureichend für alle Aufgaben ist bzw. der Server an sich in ein Bottleneck rennt.
Hier was aktuelles, um mit dem SQL Server samt Perfmon warm zu werden:
Using PerfMon and PAL to Diagnose SQL Issues
Dann empfiehlt sich mal ein Blick in das Log des SQL Servers und natürlich auch im OS.
Weitere Fragen:
Wann wurde der Server zuletzt neugestartet? Passiert das täglich? Wäre schade für den Query Optimizer, der täglich neu anlernt.
Was ist mit den Indizes? Werden diese regelmäßig reorganisiert / neu erstellt?
Gibt es komplexe Views, die relational eingebunden sind?
Von welchen Datenmengen reden wir denn? 10000, 1 Mio.?
Wie groß sind die Datenbanken? Wie ist das Wachstum eingestellt? Wie groß ist das Logfile? Welches Wiederherstellungsmodell ist aktiv? Wie erfolgen die Backups? (Täglich, stündlich) Werden Transaktionsprotokolle abgeschnitten?
Gibt es Wartungspläne?
Gibt es die Möglichkeit, auf dem Server über das SQL Server Management Studio Abfragen laufen zu lassen? Falls ja, wie lange dauert es denn beispielsweise alle Belege zu selektieren (simples Select * from <Tabelle>)
In der Regel haben wir bei unseren Kunden keine Performanceprobleme bei Vollversionen von SQL Server samt ausreichend Ram und SSD.
Von Auftragsimport über manuelle Kommisionierung bis Lieferschein- und Rechnungserstellung samt Ausdruck vergehen ca. 25 Sekunden. Der Druck aller Versandpapiere samt Etiketten nimmt dabei 12 Sekunden in Anspruch.
Es gab mal ein Windows 2008R2 zu SSL/TLS, was derbe Performanceprobleme beim SQL Server verursachte (deinstallieren und neustarten):
Sicherheitsupdate für Microsoft Windows: KB2992611
Gruß
Grinskeks
Was hilft, ist zunächst einmal auszuschließen, dass die bereitgestellte Systemperformance unzureichend für alle Aufgaben ist bzw. der Server an sich in ein Bottleneck rennt.
Hier was aktuelles, um mit dem SQL Server samt Perfmon warm zu werden:
Using PerfMon and PAL to Diagnose SQL Issues
Dann empfiehlt sich mal ein Blick in das Log des SQL Servers und natürlich auch im OS.
Weitere Fragen:
Wann wurde der Server zuletzt neugestartet? Passiert das täglich? Wäre schade für den Query Optimizer, der täglich neu anlernt.
Was ist mit den Indizes? Werden diese regelmäßig reorganisiert / neu erstellt?
Gibt es komplexe Views, die relational eingebunden sind?
Von welchen Datenmengen reden wir denn? 10000, 1 Mio.?
Wie groß sind die Datenbanken? Wie ist das Wachstum eingestellt? Wie groß ist das Logfile? Welches Wiederherstellungsmodell ist aktiv? Wie erfolgen die Backups? (Täglich, stündlich) Werden Transaktionsprotokolle abgeschnitten?
Gibt es Wartungspläne?
Gibt es die Möglichkeit, auf dem Server über das SQL Server Management Studio Abfragen laufen zu lassen? Falls ja, wie lange dauert es denn beispielsweise alle Belege zu selektieren (simples Select * from <Tabelle>)
In der Regel haben wir bei unseren Kunden keine Performanceprobleme bei Vollversionen von SQL Server samt ausreichend Ram und SSD.
Von Auftragsimport über manuelle Kommisionierung bis Lieferschein- und Rechnungserstellung samt Ausdruck vergehen ca. 25 Sekunden. Der Druck aller Versandpapiere samt Etiketten nimmt dabei 12 Sekunden in Anspruch.
Es gab mal ein Windows 2008R2 zu SSL/TLS, was derbe Performanceprobleme beim SQL Server verursachte (deinstallieren und neustarten):
Sicherheitsupdate für Microsoft Windows: KB2992611
Gruß
Grinskeks