07.12.2020, aktualisiert um 11:52:21 Uhr

14005

Serverauslastung - zu schwach?

Hallo zusammen,

heute kam ein neuer Kunde auf mich zu und meinte sein Server würde lahmen, obwohl er diesen erst vor 2 Monaten bekommen hat.
Auf den ersten Blick kein schlechter Server:
1x AMD CPU Epyc 7232P@3,1 GHz (8C/16T)
1x RAID 1 mit Micron 5200 SSD's für den Hypervisor
1x RAID 1 mit Micron 5200 SSD's für den Domaincontroller
1x RAID 10 mit Micron 5300 pro für das ERP System
16 Kanal LSI Mega RAID 9460-16i Controller
128 GB RAM

Dem DC sind 4 GB und 4vCPU zugeteilt
dem ERP sind 108 GB und 16vCPU zugeteilt

Im Servermanager

des ERP ist die CPU Auslastung in der 7 Tages Aufzeichnung zw. 12,4 und 90% sowie der freie Speicher zw. 8 und 90 GB

Das Bild vomRessourcenmonitor

habe ich mal mit angehängt
Was mich stört ist dass der "Freie Speicher" teilweise unter 50 MB sinkt und ich zwischendurch auch "Harte Fehler" bekomme.

Am Hypervisor selbst bleibt die CPU Last bei bis zu 90%

Kunde fragt mich jetzt ob er denn tatsächlich eine weitere CPU kaufen soll und den RAM verdoppeln soll.
Was meint Ihr dazu?

Danke für Feedback.

Grüße Takvorian

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 629269

Url: https://administrator.de/forum/serverauslastung-zu-schwach-629269.html

Ausgedruckt am: 10.04.2025 um 14:04 Uhr

72 Kommentare

Neuester Kommentar

Laut dem Servermanager wird der RAM kaum verwendet, dafür aber die CPU ordentlich. Aber dass der Hypervisor so stark belastet ist, da müssten ja 100te von Usern darauf gleichzeitig arbeiten. Wie viel CPU Last zeigen die einzelnen VMs im Hypervisor an? Evtl hängt ein Task in einer VM und belastet deswegen die CPU so stark.

Moin,

sehe ich das richtig, das beim Arbeitsspeicher ganz oben Bpserver.exe steht? ist das Blue Prism in der Standard-Installation mit einer lokalen SQL-Express-Installation? Wenn ja, dann weißt du zumindest wo dein Ram hin geht. Wäre zu prüfen ob der wirklich so viel Ram benötigt und den ggf. zu limitieren.

Gruß
Doskias

Hallo zusammen

@dosiak
BPServer steht für BüroPlus, das ist eine WaWi der Firma Microtech.

Hallo NordicMike
Beim Servermanager die Anzeige des RAM ist die des FREIEN RAM. Die Spitzen sind auf Neustarts zurückzuführen da hier ja weniger RAM benötigt wird.

Auf dem Hypervisor sind exakt 2 VM's, ein DC und eben einmal der WaWi Server. Insgesamt arbeiten bei dieser Firma 10 Mitarbeiter.
Die einzelnen VM's sind stand JETZT beim DC 0% und beim ERP 66% der hypervisor selbst bei 68%
Aktuell wird aber nicht gepackt und somit haben wir wieder weniger Last auf der Maschine.

Gruß Tak

Klingt irgendwie nach Selfbuilt oder von den Nischenplayern, da kommen Erinnerungen hoch. Von denen Vorinstalliert?

Hallo Certified,

das ist ein Supermicro Server

der Firma ExtraCompter. Sieht mir nicht nach Vorinstallation aus der Server, kann aber auch der Kunde mir nicht beantworten.

Ok. Wo genau ist denn jetzt dein Problem?

aus deinen Bildern geht für mich folgendes hervor: CPU-Auslastung zwischen 12 und 90 Prozent. RAM - Auslastung zwischen 8 und 90 GB. Das hast du ja auch selbst geschrieben. Wenn es der Arbeitsspeicher ist, der dich stört, dann prüfe einfach mal ob du den beim WaWi begrenzen kannst. da wird sicher n SQL-Server drankleben

Aber schlimmer:

Dem DC sind 4 GB und 4vCPU zugeteilt
dem ERP sind 108 GB und 16vCPU zugeteilt

und gleichzeitig:

1x AMD CPU Epyc 7232P@3,1 GHz (8C/16T)

Fazit: Du hast eine CPu mit 8 kernen / Threads und hast einer VM 16 vCPUs zugeteilt. Es ist zwar richtig, dass man die CPU überbuchen kann, aber eine virtuelle Maschine kann nur dann arbeiten wenn auch alle vCPUs verfügbar sind. In deinem Fall heißt es, dass der ERP nur arbeiten kann wenn keine andere VM grade vCPUs nutzt. Sprich: der DC nichts braucht. Der ist aber (vermute ich) auch noch File-Server und damit kommst du in die Situation, dass entweder der DC arbeiten kann oder die Wawi. Und damit bremst du vermutlichd as System aus. ich denke du würdest deutlich besser fahren, wenn du der WaWi-VM einfach mal 4 vCPUs wegnimmst.

nachtrag:
Nils hat das hier gut beschrieben: https://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echt ...

OK, das mit dem verfügbaren RAM habe ich falsch herum gesehen.

10 Leute dürften kaum CPU Belastung erzeugen. Vermutlich ist die VM mit RAM auslagern beschäftigt, anders kann ich mir die CPU Belastung nicht erklären.

Hallo.

Habe auch bei einem Kunden einen BüroPlus Server laufen. Dieser hat aber lediglich 4 vCPU und 8 GB RAM spendiert bekommen.

Die Datenbank selbst hat ca. 40 GB und es arbeiten 5 - 6 Leute gleichzeitig darauf (via Remote-Desktop-Server).

Als Host ist ein DELL PowerEdge 340 mit Xeon 2288G 3,7 Ghz (8 Kerne / 16 Threads) CPU, 64 GB RAM und mit Seagate Nytro SSD (960) vorhanden. Darauf läuft ein XenServer als Hypervisor.

Die RAM Auslastung der WaWi VM ist gerade mal bei knappen 40 % und die CPU Auslastung der VM unter 5 %

Auf dem Host laufen insgesamt vier VMs (DC / EX / WaWi / RDS) und dieser langweilt sich ingesamt mit einer CPU Auslastung von unter 15 %.

Irgendetwas ist da seltsam bei deinen Werten. Warum hat denn die WaWi so viel RAM erhalten? Ist die Datenbank so viel größer oder was treiben die Jungs und Mädels deines Kunden noch so auf dem WaWi Server? Oder hat der Microtech Partner das "empfohlen"?

Was kommt denn für ein Hypervisor zum Einsatz?

Gruß
Radiogugu

Hallo Doskias,

die WaWi arbeitet nicht mit einem SQL Server. Auf dem Server gibt es unzählige Datenbankdateien im MDB Format. Für die WaWi wurde in deren Serverkoniguration ein Cache von 64 GB eingestellt die sie sich IMMER nimmt auch wenn nichts los ist. Das ist wohl seitens des Herstellers Microtech so gewollt, da es sich um den Enterprise Server von denen handelt.

Der DC ist hier wirklich nur DC, DNS, DHCP und nix anderes. Fileserver macht der ERP mit.
Ich kläre mit dem Kunden wann wir den Server herunterfahren können um die vCPU Zuordnungen zu ändern.
Dann testen wir das nochmal.

Zitat von @radiogugu:

Hallo.

Habe auch bei einem Kunden einen BüroPlus Server laufen. Dieser hat aber lediglich 4 vCPU und 8 GB RAM spendiert bekommen.

Hallo Radiogugu,

danke für Deine Infos.
Hypervisor ist Windows Server 2019.
Hab mal nen Auszug aus dem DB Verzeichnis rangehängt.

Die WaWi wurde von Microtech Partner so eingestellt, lief wohl auf dem letzten Server schon mit den gleichen Einstellungen. Da hatte die Firma aber noch 25 Mitarbeiter. Der Alte Server war wohl ein 2 CPU System mit E5-2690v2 und 256 GB RAM. Hier liefen laut seiner Aussage 4 VM's drauf (DC, Filesever, WaWi, App-Server) Das langsame an der Geschichte ist wohl der Versand beim Packen. Es handelt sich um einen größeren Online Händler welcher auf Ebay, Amazon usw. verkauft.

Gruß Tak

Zitat von @takvorian:
die WaWi arbeitet nicht mit einem SQL Server. Auf dem Server gibt es unzählige Datenbankdateien im MDB Format. Für die WaWi wurde in deren Serverkoniguration ein Cache von 64 GB eingestellt die sie sich IMMER nimmt auch wenn nichts los ist.

Gut, dass sie es begrenzt haben, auch wenn ich für die beschriebene Umgebung es als zu viel erachte. Aber die wissen schon was sie tun ;)

Der DC ist hier wirklich nur DC, DNS, DHCP und nix anderes. Fileserver macht der ERP mit.

Auch schonmal sehr gut. Wobei ein reiner DC mit DNS und DHCP mit 4 vCPUs überdimensioniert sehe. Wir haben deutlich mehr User und nur 2 vCPU.

Ich kläre mit dem Kunden wann wir den Server herunterfahren können um die vCPU Zuordnungen zu ändern.
Dann testen wir das nochmal.

Unbedingt auch den Artikel von Nils lesen. da steht nämlich auch noch drin, dass du auch CPU für den Host reservieren solltest. Das hast du auch nicht berücksichtigt. Oder anders gefragt: Wenn das WaWi alle CPUs zugeordnet bekommt, wobei soll der Hypervisor dann arbeiten?

Also die Dateien sind riesig im Vergleich zu denen meines Kunden.

Eventuell liegt da der Hase im Pfeffer. Aber ich kenne mich mit der Software überhaupt nicht aus, daher weiß ich nicht ob es Optimierungspotentiale durch Komprimierung oder ähnliche Instrumente gibt.

Ich kann nur sagen, dass hier die kleine Kiste, im Vergleich zu dem Ressourcen Monster bei deinem Kunden, performant vor sich hin arbeitet.

Eventuell kann der Microtech Partner dazu ein wenig mehr sagen. Aber die Schiere Größe der MBD Dateien lässt auf extrem viele Daten schließen und dann wird sich das wahrscheinlich schnell erledigt haben mit Optimierung

Gruß
Radiogugu

Wer hat den denn Vorinstalliert? War nicht unter deiner Ägide? Wie bist du zu dem Projekt gekommen (das du nun an uns Auslagerst?) Grundsätzlich wäre mal die Aufnahme des gesamten Systems ratsam. Ist aber nichts fürs Forum, da muss man wohl tiefer graben.

Grüße

Sers,

die CPU überbucht man bei Datenbanken und anderen Leistungsintensiven Anwendungen bitte nur wenn man genau weiß was man tut.
Um genau zu sagen, an was die hohe CPU Last liegt fehlen die Infos über die IOs und speziell die IO-Wartezeiten (Antwortzeiten) innerhalb der ERP-VM. Das erfährst du im Ressourcenmonitor im Reiter Datenträger.

:edit: Wo liegen die Antwortzeiten bei der ERP-VM? 1ms? 10ms? 50ms? 100ms? 200ms? Höher?

Die 5200 und 5300er SSD sind fürs Lesen optimiert. Eine SSD für Mixed Use wäre hier passender gewesen, insbesondere NVMe statt SATA.
Preislich schenken die sich heute kaum mehr was, die Performance und Latenzen sind aber Welten auseinander.

Und der Klassiker, nachdem ich eine BCM5719 sehe: Auf dem Hyper-V VMQ für die NICs abschalten.

Grüße,
Philip

Zitat von @certifiedit.net:

Wer hat den denn Vorinstalliert?

Das weis der Kunde leider nicht, entweder sein Dienstleister oder aber ExtraComputer selbst. Er will nix mehr mit dem DL zu tun haben.

War nicht unter deiner Ägide?

Nein!

Wie bist du zu dem Projekt gekommen

Der Kunde sitzt in der gleichen Stadt wie wir und ist wohl ein bekannter von meinem Chef. Weiterhin kaufen auch wir Hardware bei ExtraComputer ein

(das du nun an uns Auslagerst?)

Ich möchte das nicht auslagern, ich wollte Eure Erfahrungswerte hören.
Wenn ich mehr Infos vom Kunden habe z.b. Seriennummer des Servers dann frag ich auch bei Extra Computer mal an ob der tatsächlich von denen vorinstalliert wurde.

Grundsätzlich wäre mal die Aufnahme des gesamten Systems ratsam. Ist aber nichts fürs Forum, da muss man wohl tiefer graben.

Jupp, da muss ich mal vor Ort schauen und alles aufnehmen was der so hat. Muss auch jede Info rauskitzeln von dem.

Grüße

Zitat von @takvorian:

Zitat von @certifiedit.net:

(das du nun an uns Auslagerst?)

Ich möchte das nicht auslagern, ich wollte Eure Erfahrungswerte hören.

Nimm Certi nicht so ernst, der will nur spielen

Was mich noch interessieren würde, wie sieht deine Read / Write Performance der Platten aus, speziell die Raid 10? Vielleicht in einer Ruhigen Minute mal einen Crystal Disk Mark laufen lassen und schauen was effektiv rum kommt? Grad bei Datenbanken immer ein gern gesehener Flaschenhals, wobei des bei der Konfiguration daran nicht liegen sollte.

Stell auf jeden Fall die CPU Aufteilung um, ERP System auf 12 CPUs (Threads) und den DC auf 2 CPUs (Threads) damit sollten rechnerisch noch 4 für den Hypervisor übrig bleiben und schau mal wie es sich verhält.

Gruß
PJM

Hallo,

ich hab bis jetzt 1x mit einem ERP zu tun gehabt das die Dateien auch ähnlich in Dateien abgelegt hat und kein Richtiger DB Server dahinter war.
Perfomant ist das aber nie gelaufen.
Vielleich hat die Software grundsätzlich mit der Datenmenge zu kämpfen was du dann irgenwann mit Performanter Hardware nicht mehr so richtig kompensieren kannst.

Warum gönnt man sich einen solchen Controller, und dann mehrere SATA SSD als RAID1 Paare zu fahren? Wie ist denn überhaupt die glGesamtconfig des Controllers und warum diese Einteilung in mehrere kleine Raids?

Warum hat der DC 4 VCPUs?

Warum hat das ERP 16 VCPUs, wenn die CPU in Summe nur 16 Threads kann.

RAM ist grundsätzlich dafür da dass man ihn benutzt.
Die Datenbankanwendung ist weshalb so "groß". Ist die Datenbank auf dem storage riesig oder hat sich die Datenbank versucht z.b. durch Indizes zu optimieren?

Zitat von @takvorian:

Das langsame an der Geschichte ist wohl der Versand beim Packen. Es handelt sich um einen größeren Online Händler welcher auf Ebay, Amazon usw. verkauft.

Hier wäre mal interessant, was beim Packen passiert. Gibt es eine eigene Versandsoftware, oder passiert das innerhalb der ERP-Software? Holt sich die (ERP-)Software jedes Mal online ein Etikett ab, oder wird das offline generiert und dann abends gesammelt an DHL/UPS/etc. übergeben (so wie man es normalerweise machen sollte)?

Wenn jedes Etikett einzeln abgeholt wird, kann das schon lange dauern, je nach Internetverbindung und Serverauslastung auf der anderen Seite.

Und vCPUs würde ich der ERP-VM nur vier geben und dann weiter beobachten.

cu,
ipzipzap

Zitat von @142583:

Warum gönnt man sich einen solchen Controller, und dann mehrere SATA SSD als RAID1 Paare zu fahren? Wie ist denn überhaupt die glGesamtconfig des Controllers und warum diese Einteilung in mehrere kleine Raids?

Hallo IT-Prof
wie gesagt die Serverkonfig ist nicht von mir, gebe aber zu dass auch ich meine Server meist mit einem kleinen R1 ausstatte für den Host und dann je nach Anwendung ein weiteres R1 oder R10 für die Server dazu packe. Je nachdem was laufen soll. Klar auf nem RAID 10 hab ich dann auch schonmal mehr Server laufen als nur einen. Aber das belastet den Controller nun auch nicht so viel mehr wenn der 3 Arrays anstelle von 1 zu verwalten hat. Am Host und am DC läuft ja eh nix großartig.

Warum hat der DC 4 VCPUs?

Warum hat das ERP 16 VCPUs, wenn die CPU in Summe nur 16 Threads kann.

PJM schrieb ja schon dass das Geändert werden soll. wurde vorhin auch entsprechend angepasst. Wir beobachten das jetzt mal bis Donnerstag.

RAM ist grundsätzlich dafür da dass man ihn benutzt.

Klar freier RAM ist rausgeschmissenes Geld.

Die Datenbankanwendung ist weshalb so "groß". Ist die Datenbank auf dem storage riesig oder hat sich die Datenbank versucht z.b. durch Indizes zu optimieren?

Das sollte mal den Entwickler, welche für die Software bei dem Kunden scheinbar verantwortlich ist, gefragt werden. Die einzelnen DB Dateien sind ja schon riesig. Hier muss entweder ich oder dessen Entwickler mal mit Microtech telefonieren...

Schönen Abend noch.

Nein, certi meint das tatsächlich ernst - wieso wirst du dazu gezogen, wenn am Ende die Frage hier landet? Wie lang probierst du da schon, seit wann tritt das Problem auf etc. Immerhin gehört das - wenn es die Firma wirklich stört - ordentlich überwacht, oder nicht?

Ansonsten hast du Recht, Wer hat das warum so gebaut, welchen Hintergrund hat das? Vielleicht ist es auch schlicht die falsche Konstellation.

Grüße

Mag ja sein, dass Du deine Raids so anlegst und andere auch, aber dann ist der Controller rausgeworfenes Geld. Fast alle seine Features und der mögliche Mehrwert liegen brach.
Jedes Softraid oder Single Drive ist über den Cache hinaus, genau das selbe.

Was das Verhalten des SQL Servers angeht, würde ich gucken ob die DB-Engine den RAM in dem Umfang nutzt, weil die Datenbank davon profitiert. Zum Beispiel kann das indizieren sehr langer Tabellen im laufenden Betrieb dafür sorgen, dass der RAM mehr in Nutzung ist, als die Dateien im Storage. Das ist grundsätzlich gut, wenn es Sinn macht. Außerdem gibt es auch z. B. In-Memory Features, die sehr viel Sinn machen können.

Wir haben z.B. eine MS-SQL basierende Einzelteilrückverfolgung (Tracebility). Da können 500 Millionen numerische Datenbankwerte und deren Korrelation 5 GB groß sein im Storage und der Server macht von sich durch seine Optimierung, damit 2TB RAM voll.
Das kann maßgeblich vom Programmierer beeinflusst werden. Bei uns hat z. B. nach dem Wechsel vom nHibernate Framework zum Entity Framework das Verhalten der SQL Server stark verändert.

Du solltest also dringend die Programmierer und Datenbankkonfig Überblicken und verstehen lernen.

Hallo

ja mei es gibt auch andere Prozessoren in erschwinglichen Rahmen

z.B.

Intel Xeon Silver 4214 2.2G, 12C/24T, 9.6GT/s, 16.5M Cache

damit schaut es dann ganz anders aus.

So long

Yumper

Die Xeon CPU passt nicht ins Board.

Außerdem kann ich mir schwer vorstellen, das es an roher CPU-Power mangelt.

Zitat von @142583:

Die Xeon CPU passt nicht ins Board.

Außerdem kann ich mir schwer vorstellen, das es an roher CPU-Power mangelt.

Hallo

schon klar - der Server passt eben ins Soho Segment, aber niemals in eine Firma.
Virtualisierung mit AMD Prozessoren ist immer so eine Geschichte.

Die Problem sind aber wirklich die MDB Datenbanken.
Kenne das auch von Sage KHK - schnell ist da echt etwas anders.

Ich bin auch kein Freund von irgend welchen Raid Geschichten. Mit Veeam ordentlich gesichert ersetzt da so manche kunstvolle Konfiguration.
USB Stick rein und innerhalb 15 Minuten läuft Drive C: wieder. Virtuelle Maschinen sind schon während dem Restorevorgang wieder Online.

So long

Yumper

Zitat von @yumper:

USB Stick rein und innerhalb 15 Minuten läuft Drive C: wieder. Virtuelle Maschinen sind schon während dem Restorevorgang wieder Online.

So 15min Restore, bzw der Datenverlust seit der letzten Sicherung und in der einen oder Anderen Firma schon mal schnell einige Tausend Euro kosten.

Raid hat schon seine Berechtigung.

Zitat von @wiesi200:
[...]
Raid hat schon seine Berechtigung.

Jup alleine auch aus Performance Gründen. Und praktisch ists halt auch, wenn mal ne Platte kaputt geht, springt die Hotspare rein und der (faule) Admin kann gemütlich nach dem Frühstück die HDD tauschen.

Hallo zusammen,

ich stehe inzwischen mit Microtech in Kontakt und wir müssen bei den DB Dateien ansetzen. Laut Microtech sind die viel zu groß und wir prüfen jetzt inwiefern das optimiert werden kann. Ein Ansatz ist eine vollständige DB Reorganisation und weiterhin Datensätze welche älter als 10 Jahre sind rauszuschmeissen.
Ich hab mir den Datendurchsatz des Arrays mal angesehen wenn nix los ist bei Kunden. Sieht mMn ganz passabel aus.

Die ERP VM besteht aus 3 einzelnen VHDx "platten" 1x Windows, 1x Entwickler-Programme, 1x ERP

Da irgendwer wissen wollte wie die Raid Konfiguration an sich aussieht auch hier noch ein Auszug

Im Server ist noch zusätzlich eine einzelne SAS-HDD verbaut auf welche der Kunde kurzfristig immer eine Sicherung von Microtech ablegt wenn hier ein Update ansteht...

Ich warte jetzt mal die Rückmeldung von Microtech ab und beobachte das ganz die kommenden Tage.
Über den heutigen Tag sehen wir auch wie sich die Änderung der vCPU's auswirkt.

Gruß Tak

Tut mir Leid, @takvorian, aber die Messungen sind fast wertlos, da der Controller selbst ja schon 4 GB RAM mitbringt. Ein Großteil der Benchmarks kommt also aus diesem Cache, und nicht aus den Arrays.

Mich würden immernoch die Datenträger Antwortzeiten aus dem Ressourcenmonitor während der normalen Last interessieren.
Und ob du VMQ auf den Broadcom Netzwerkkarten vom Hyper-V deaktiviert hast.

Zitat von @takvorian:

Hallo zusammen,

ich stehe inzwischen mit Microtech in Kontakt und wir müssen bei den DB Dateien ansetzen. Laut Microtech sind die viel zu groß und wir prüfen jetzt inwiefern das optimiert werden kann. Ein Ansatz ist eine vollständige DB Reorganisation und weiterhin Datensätze welche älter als 10 Jahre sind rauszuschmeissen.

Hab ich mir fast gedacht. Ist ja kein richtiges DB System. Ein SQL Server würd sich damit eher spielen.

Zitat von @psannz:

Tut mir Leid, @takvorian, aber die Messungen sind fast wertlos, da der Controller selbst ja schon 4 GB RAM mitbringt. Ein Großteil der Benchmarks kommt also aus diesem Cache, und nicht aus den Arrays.

Mich würden immernoch die Datenträger Antwortzeiten aus dem Ressourcenmonitor während der normalen Last interessieren.

Ich schau mir das beim nächsten mal mit an, aktuell ist grad alles so gut wie im Leerlauf

Und ob du VMQ auf den Broadcom Netzwerkkarten vom Hyper-V deaktiviert hast.

Hmm, ich sehe gerade dass die, im Datenblatt angegebene, Netzwerkkarte gar nicht verbaut ist. Server hat nur die 2 onBoard intel i350 Netzwerkkarten drin. Dort ist VMQ aktiviert.
Gilt das bei den neuen Broadcom immer noch dass man die Warteschlange für die VM's dekativieren soll?

Ich habe inzwischen auch Kontakt zum Hersteller. Dieser schickt dem Kunden jetzt auch anderen Arbeitsspeicher. Verbaut wurde ja 2666er. Kunde bekommt jetzt 3200er. Der Server ist gerade mal 8 Wochen alt. Möchte echt mal wissen was da schief ging.

Gruß tak

Zitat von @takvorian:

Mich würden immernoch die Datenträger Antwortzeiten aus dem Ressourcenmonitor während der normalen Last interessieren.

Ich schau mir das beim nächsten mal mit an, aktuell ist grad alles so gut wie im Leerlauf

könntest du bitte nach der Antwortzeit sortieren? Die Schreib und Leseraten sind tatsächlich nicht weiter interessant. Wie lange ein Prozess darauf warten muss, dass ein Schreib- oder Lesevorgang fertig wird schon, da das Warten auf die IOs auch gut Last auf der CPU verursachen kann. Sprich, wenn du hier Zeiten von >15ms in der VM siehst, dann hast du aus meiner Sicht ein Problem.

Und ob du VMQ auf den Broadcom Netzwerkkarten vom Hyper-V deaktiviert hast.

Hmm, ich sehe gerade dass die, im Datenblatt angegebene, Netzwerkkarte gar nicht verbaut ist. Server hat nur die 2 onBoard intel i350 Netzwerkkarten drin. Dort ist VMQ aktiviert.

Das ist ok so. Bei Intel sind mir keine VMQ Probleme nicht bekannt.

Gilt das bei den neuen Broadcom immer noch dass man die Warteschlange für die VM's dekativieren soll?

Für 1 Gbit Karten von Broadcom ja. Der Schrott fing bei den Treibern für WS2012 an und verursacht bis heute Probleme bei Hyper-V und VM Netzwerken.

Ich habe inzwischen auch Kontakt zum Hersteller. Dieser schickt dem Kunden jetzt auch anderen Arbeitsspeicher. Verbaut wurde ja 2666er. Kunde bekommt jetzt 3200er. Der Server ist gerade mal 8 Wochen alt. Möchte echt mal wissen was da schief ging.

Wird was bringen, aber nicht enorm viel. Würde mit 5% mehr Performance rechnen.

Mal eine Anekdote zwischendurch, ich habe mir mal den ganzen Thread aus Interesse durchgelesen:

@Doskias Schreibt von Überbuchen der CPU und das dies zu Problemen führen kann, verweist noch weiter unten auf einen Lese-Artikel zu diesem Thema. Wenn ich den Artikel richtig interpretiert habe, dürfte das Überbuchen (Over-Provisioning) überhaupt kein Problem sein. Ich zitiere mal:

"Update Juni 2012: Die maximalen Supportgrenzen von 8:1 bzw. 12:1 gelten für Hyper-V-Hosts unter Windows Server 2008 R2. Mit Windows Server 2012 werden diese Grenzen entfallen, d.h. eine stärkere Überbuchung der CPU wird dann kein pauschales Support-Hindernis mehr sein."

Das es langsamer läuft sobald die Ressourcen dann erschöpft sind, ist klar. Irgendwo gibt es ja auch eine physikalische Grenze. Aber ich sehe jetzt in dieser Konfiguration erstmal kein Problem bei der Verteilung der vCPUs. Da es irgendwann nur noch auf zugeteilter Rechenzeit hinausläuft. Wenn also der überdimensionierte DC nichts zu tun hat, dann sollte es ansich in puncto CPU-Leistung keine Probleme geben.

Ich vermute hier einfach die schlechte Performance liegt an der unoptimierten Software und der Verwendung einer Pseudo-Datenbank. Vermutlich gibt es einen vermurksten Indize und bei der Abfrage der Datenbank muss diese komplett durchsucht werden. Vor allem ein Hinweis ist, das es scheinbar nur beim "Packen" passiert. Würde mal prüfen was dort für "Tabellen" verwendet werden und mich darauf fokussieren.

Mal abgesehen davon das die Hardware nicht gerade optimal gewählt wurde, sehe ich sie aber nicht als Problem.

Zitat von @Fenris14:

Mal eine Anekdote zwischendurch, ich habe mir mal den ganzen Thread aus Interesse durchgelesen:

@Doskias Schreibt von Überbuchen der CPU und das dies zu Problemen führen kann, verweist noch weiter unten auf einen Lese-Artikel zu diesem Thema. Wenn ich den Artikel richtig interpretiert habe, dürfte das Überbuchen (Over-Provisioning) überhaupt kein Problem sein.

Das Problem, ist, dass hier bei einer CPU mit 16 Hardware Threads einer VM 16 vCPUs zugewiesen wurde. Bei 100% CPU Last in der VM konkurrieren dann Hypervisor und VM um dieselben Ressourcen. Der Hypervisor könnte dann beispielsweise nur noch verzögert IO Zugriffe oder Netzwerktraffic abarbeiten, was wiederum zu noch schlechterer Performance in der VM führen kann.
Schlimmstenfalls arbeiten dann noch die IO Worker von Hypervisor und VM auf demselben Kern. Dann hast du den Salat.

Wenn du mich schon zitierst, oder aus dem Artikel, dann bitte auch komplett und vollständig:

Mehrfach-CPUs in virtuellen Servern haben aber auch einen weiteren Nachteil: Eine VM mit vier vCPUs kann vom Hypervisor immer nur dann Rechenzeit erhalten, wenn gleichzeitig vier “echte” CPU-Cores frei sind (denn nur die echten CPUs können ja die Rechenarbeit erledigen). Hat der Admin zu großzügig verteilt und viele Server mit einer, zwei und vier vCPUs auf seinem Host gemischt, kann es bei hoher Auslastung durchaus sein, dass der Hypervisor nur selten vier CPU-Kerne gleichzeitig an eine VM zuteilen kann. Im Effekt wäre eine solche VM also “langsamer” als erwartet, weil ihre vier virtuellen CPUs ständig auf Rechenzeit warten, aber nur selten welche bekommen.

wir haben 16 vCPUs und eine VM braucht 16, eine braucht 4. Daraus folgt:

Wenn die 16 vCPU der Wwi zugewiesen sind, dann sind keine für den DC mehr frei.
Wenn die 4 vCPU dem DC zugeordent sind, dann sind 12 ungenutzt (weil die Wawi nur mit 16 arbeiten kann).

Also haben wir hier sehr wohl ein Überbuchungspoblem. Hätten wir hier hingegen 12 VMs mit jeweils 2 vCPU, dann hätte wir zwar mit 24 noch mehr vCPUs zugeteilt, aber da jede nur 2 braucht können sie einfacher wechseln und es entsteht kein "Leerlauf" wie in dem Fall oben beschrieben. 4 VMs (8 vCPUs) haben zwar keine aktive CPU zeit, aber sie können einfach swappen und müssen nicht warten bis die Anzahl von 16 frei wird.

Nils schreibt weiterhin:

Viele Admins übersehen aber, dass auch der Host selbst für seine Arbeit Reserven braucht, und zwar sowohl Arbeitsspeicher als auch CPU-Leistung. Eine Faustformel besagt, dass man “einen halben Core” an CPU-Leistung und zwei bis vier Gigabytes an RAM für den Host reservieren sollte.

Auch das wurde hier nicht berücksichtigt. Wenn ich 16 von 16 Prozessoren einer VM zuweise, dann hab ich für den Host nichts übrig.

Also zu deiner Aussage:

Zitat von @Fenris14:
Wenn ich den Artikel richtig interpretiert habe, dürfte das Überbuchen (Over-Provisioning) überhaupt kein Problem sein.

hast du leider falsch interpretiert.

Zitat von @psannz:

Das Problem, ist, dass hier bei einer CPU mit 16 Hardware Threads einer VM 16 vCPUs zugewiesen wurde. Bei 100% CPU Last in der VM konkurrieren dann Hypervisor und VM um dieselben Ressourcen. Der Hypervisor könnte dann beispielsweise nur noch verzögert IO Zugriffe oder Netzwerktraffic abarbeiten, was wiederum zu noch schlechterer Performance in der VM führen kann.
Schlimmstenfalls arbeiten dann noch die IO Worker von Hypervisor und VM auf demselben Kern. Dann hast du den Salat.

Das ist ja genau das was ich sage: Es ist kein Problem. Microsoft unterstützt das sogar mittlerweile unbegrenzt. Früher hat Microsoft nur bis 4:1 oder 8:1 unterstützt.

Also nehmen wir mal die Faust-Formel von 4:1 die mir auch bei KVM ein Begriff und geläufig ist: Wenn er 16 Hardware-Threads hat und wir mal die logischen Threads durch Hyperthreading außen vor lassen, dann kommen wir bei 4:1 auf reintheoretische 64 vCPUs die vergeben werden könnten.

Also ist er voll im Rahmen und die CPU oder die HyperV-Config ist nicht das Problem. Erstmal egal ob in der VM 100% Auslastung ist, entscheidend ist erstmal wer verursacht diese Auslastung. Der Hypervisor selbst, so wurde es eingangs beschrieben, bleibt bei 90%. Also liegt dort das Problem nicht.

Zitat von @Doskias:

wir haben 16 vCPUs und eine VM braucht 16, eine braucht 4. Daraus folgt:

Wenn die 16 vCPU der Wwi zugewiesen sind, dann sind keine für den DC mehr frei.
Wenn die 4 vCPU dem DC zugeordent sind, dann sind 12 ungenutzt (weil die Wawi nur mit 16 arbeiten kann).

Also haben wir hier sehr wohl ein Überbuchungspoblem. Hätten wir hier hingegen 12 VMs mit jeweils 2 vCPU, dann hätte wir zwar mit 24 noch mehr vCPUs zugeteilt, aber da jede nur 2 braucht können sie einfacher wechseln und es entsteht kein "Leerlauf" wie in dem Fall oben beschrieben. 4 VMs (8 vCPUs) haben zwar keine aktive CPU zeit, aber sie können einfach swappen und müssen nicht warten bis die Anzahl von 16 frei wird.

Ok, das klärt es auf. Danke.

Zitat von @Fenris14:
Microsoft unterstützt das sogar mittlerweile unbegrenzt. Früher hat Microsoft nur bis 4:1 oder 8:1 unterstützt.

Ok. Wir machen es mal einfach:
Ja es stimmt. MS hat früher 4:1 oder 8:1 unterstützt. Bei dem Server bedeutet das dann:

Du hast 16 logische CPUs. Also kannst du problemlos 128 vCPUs verteilen, denn das ist 8 *16 (ich lasse hier bewusst die CPUs für den Hypervisior mal weg). Du kannst also problemlos 128 VMs erstellen mit je 1 vCPU oder 64 mit jeweils 2 vCPU, etc... Das nennt man Überbuchung.

Aber: du kannst keine 8 VMs mit 16 vCPUs erstellen. Ok, doch könntest du, aber 7 von denen würden permanent nicht arbeiten können. wenn du 4 Vms mit 32 vCPUs erstellst, dann wird davon keine arbeiten können. Das nennt man dann Probleme mit der Überbuchung.

Nachtrag: Schon geschrieben als du wohl auch grade am schreiben warst

Zitat von @Doskias:

Moin,

sehe ich das richtig, das beim Arbeitsspeicher ganz oben Bpserver.exe steht? ist das Blue Prism in der Standard-Installation mit einer lokalen SQL-Express-Installation? Wenn ja, dann weißt du zumindest wo dein Ram hin geht. Wäre zu prüfen ob der wirklich so viel Ram benötigt und den ggf. zu limitieren.

Gruß
Doskias

SQL Express belegt maximal 1,4 GB an Cache, dazu kommt noch mal ca. 500 MB für die SQL engine selbst. Das kanns nicht sein

Bei 10 Leuten kanns nicht an der CPU oder deren Core Verteilung liegen. Das System dürfte dabei nicht einmal aus dem IDLE Mode raus kommen.

Was macht denn ein ERP, ausser ein paar Wareneingänge, Ausgänge, Angebote, höchstens noch ein paar OCR für ankommende Rechnungen. Das System dürfte 95% seiner Zeit auf eine neue User-Aktion warten. Ab und zu mal einen 100-Seitigen Vertrag einscannen dürfte nicht so eine Dauerbelastung zeigen, sondern kurzzeitige schmale Peaks.

Ich würde mich auf die Speichernutzung und Speicherverteilung konzentrieren.

Ich gehe davon aus, dass am Hypervisor einfach etwas zu großzügig mit Reservierung von Ressourcen für die VM des ERP umgegangen wurde.

Es macht ja auch einen Unterschied, ob die CPU oder der RAM statisch oder dynamisch zugewiesen werden.

Das würde ich in jedem Fall mal hier als Maßnahme empfehlen.

Generell sollte man die Anzahl der CPU drastisch reduzieren. Mehr als 4 vCPU werden keinesfalls für das ERP benötigt.

Gruß
Radiogugu

Zitat von @GrueneSosseMitSpeck:

SQL Express belegt maximal 1,4 GB an Cache, dazu kommt noch mal ca. 500 MB für die SQL engine selbst. Das kanns nicht sein

Hallo

Es handelt sich ja um eine Access ERP Anwendung mit MBD Datenbanken.
Richtig performant wird das niemals. Man muss sich nur Sage KHK ansehen das sehr weit verbreitet ist. Das lahmt auch ohne Ende.

so long

Yumper

Zitat von @yumper:
Es handelt sich ja um eine Access ERP Anwendung mit MBD Datenbanken.
Richtig performant wird das niemals. Man muss sich nur Sage KHK ansehen das sehr weit verbreitet ist. Das lahmt auch ohne Ende.

Ist leider die traurige Wahrheit. Aber dieses ERP (BüroPlus) erfreut sich einiger Beliebtheit tatsächlich. Wahrscheinlich sind einfach größere Umgebungen oder rasant anwachsende Datenbestände der limitierende Faktor für das Benutzer-Erlebnis

@takvorian gibt es denn schon Neuigkeiten seitens eures ERP-Partners, bezüglich der Optimierung / Komprimierung der Datenbanken?

Wurden denn die VM-Hardware Anpassungen wie mehrfach vorgeschlagen umgesetzt?

Gruß
Radiogugu

Hallo radiogugu

Zitat von @radiogugu:

Die v-CPU wurden gestern Abend auf 4 reduziert. Den neuen RAM habe ich leider noch nicht erhalten. Warte noch immer auf Rückmeldung vom Kunden ob sich etwas getan hat.
Seitens Microtech gab es auf meine Anfrage hin nur den folgenden Vorschlag
Damit kämen zumindest alte Datensätze aus der DB raus. Weiterhin möchte ich noch gerne eine komplette DB Reorganisation aller Datenbanken machen.
Auf diese beiden Vorschläge hin kam die Antwort vom Kunden "Danke, teste ich mal im Januar"

?? Ich frag mich gerade ob er das Problem tatsächlich beheben möchte?

Um die Antwortzeiten der Datenträger sehen zu können müsste er mich nur mal zur passenden zeit per Teamviewer drauf lassen... Kunde möchte derzeit keinen vor-Ort Termin haben!?? Aber wenn ich den RAM habe soll ich mich schnellstens bei ihm melden !? Versteh ich irgendwie nicht.. aber egal.

Gruß Tak

Zitat von @takvorian:
Damit kämen zumindest alte Datensätze aus der DB raus. Weiterhin möchte ich noch gerne eine komplette DB Reorganisation aller Datenbanken machen.

Klingt gut.

Auf diese beiden Vorschläge hin kam die Antwort vom Kunden "Danke, teste ich mal im Januar"

?? Ich frag mich gerade ob er das Problem tatsächlich beheben möchte?

Dann isses ja nicht so dringend oder die Prioritäten liegen gerade woanders.

Um die Antwortzeiten der Datenträger sehen zu können müsste er mich nur mal zur passenden zeit per Teamviewer drauf lassen... Kunde möchte derzeit keinen vor-Ort Termin haben!?? Aber wenn ich den RAM habe soll ich mich schnellstens bei ihm melden !? Versteh ich irgendwie nicht.. aber egal.

Hast du denn keinen anderen Zugang mit dem Kunden vereinbart? Beispielsweise ein VPN und intern dann weiter mit VNC oder Ähnlichem?

Gruß
Radiogugu

Zitat von @radiogugu:

Hast du denn keinen anderen Zugang mit dem Kunden vereinbart? Beispielsweise ein VPN und intern dann weiter mit VNC oder Ähnlichem?

Klar hab ich das angefragt. Kann ich mir einrichten wenn ich wieder vor-Ort bin. Glaub der hat ne Digibox Premium von Bintec-Elmeg

Gruß
Radiogugu

Man muss schon sagen das grad die Tage vor Weihnachten immer die Hölle los sein kann bei manchen Firmen. Zumindest bei uns so.
Da kann man schon mal prios anders setzen müssen.

Hallöchen,

gerade nen Screenshot bekommen auf der wohl ersichtlich ist dass die 4 vCPU Kerne nicht ausreichen. CPU in der VM dauerhaft bei 100%

Schaun wir mal ob er mir heut noch nen Zugang ermöglicht, wenn nicht muss das halt warten.

Gruß Tak

Mongo Db ist doch schon mal ein neuer Ansatzpunkt.

Schau dir doch mal das an.
https://medium.com/mongodb-cowboys/troubleshooting-mongodb-100-cpu-load- ...

Also läuft da noch eine andere Datenbank auf dem Server, denn die MongoDB hat imho nix mit BüroPlus zu tun.

Zur Info: Bei meinem Kunden läuft da zumindest nichts Weiteres.

Gruß
Radiogugu

Zitat von @radiogugu:

Also läuft da noch eine andere Datenbank auf dem Server, denn die MongoDB hat imho nix mit BüroPlus zu tun.

Zur Info: Bei meinem Kunden läuft da zumindest nichts Weiteres.

Gruß
Radiogugu

Die Info finde ich jetzt Interessant. Da hat man dann schon genug um das Problem zu finden.

Zitat von @wiesi200:
Die Info finde ich jetzt Interessant. Da hat man dann schon genug um das Problem zu finden.

Ich gehe schwer davon aus, dass hier der Hase im Pfeffer liegt und die hohe Ressourcen-Auslastung begründet ist.

Es muss nun festgestellt werden, was die eine Datenbank denn hier für einen Zweck hat. Falls niemand dazu etwas sagen kann, dann Chef fragen und dann den Prozess mal beenden und schauen wer schreit

Gruß
Radiogugu

Neben dem Zweck, wäre auch interessant zu wissen, was die MongoDB treibt um so viel CPU zu fressen.
Vielleicht ist die DB wichtig für das arbeiten und eine minimale Änderung/Optimierung löst die Probleme.

4 Epyc Kerne zu nennenswerten Anteilen fressen, das macht die MongoDB-Engine, wenn sie keinen Fehler hat nur, wenn riesige Workloads laufen. Verwunderlich ist aber, warum die Workloads nicht in Sekunde vorbei sind.

Hier wird etwas stark schief laufen.

Habe eine Dolibarr ERP Installation auf Basis der MongoDB laufen.

Diese hat zwar nicht Ausmaße der ERP DB des TO, aber trotzdem läuft die in einer VM mit 2 vCPU und 8 GB RAM. Diese Ressourcen werden nur mal ab und an zu 50 % ausgenutzt, wenn 20 Benutzer gleichzeitig eine Wareneingangsbuchung durchführen oder Lieferscheine mit Warenabgängen erstellen. Ansonsten langweilt sich der Ubuntu Server herzlich.

Gruß
Radiogugu

Hallo zusammen,

da ich selbst weder mit dem nevelopNext2Shop noch mit Mongo DB jemals Berührungspunkte hatte, hat der Kunde dies jetzt an seinen Entwickler weitergegeben.
Zumindest hab ich jetzt die Info was sich hinter dieser Mongo DB verbirgt.
Scheint mir so als hätte das was mit dem Abgleich der Onlineshops und dem lokalen ERP zu tun hat. Die Packkontrolle wird hier wohl auch mit reinfunken.

Des weiteren hat er auf dem Server auch noch die ganzen Bilder liegen welches in seinem ERP und vermutlich auch gegenüber dem OnlineShop abgeglichen werden. Bei über 90 GB und fast 500.000 Bilder wird hier das ERP wohl auch bissi was zu tun haben.

Ich tausche ihm, wenn geliefert, den RAM aus. Dann muss er sich überlegen ob ich bei ihm vor-Ort wirklich mal alles aufnehmen soll oder ob er weiter so rumwurschtelt.

Ich fürchte da wird sich kaum etwas optimieren lassen, solange das bisherige Konstrukt beibehalten werden soll.

Die Kombination aus BüroPlus und der anderen Datenbank scheint sich arg zu beißen und die VM und damit den Host in die Knie zu zwingen.

Würde behaupten, wenn du die MongoDB in eine eigene VM auslagerst, wird diese VM dann diejenige sein, die den Host (über)fordert.

ist die Frage ob es da eine richtige API der beiden Software-Produkte gibt, oder ob da gebastelt wurde. Eher Letzteres würde ich vermuten.

Gruß
Radiogugu

Eine Datenbank wird nicht langsamer, vorausgesetzt sie wird entsprechend genutzt, wenn sie "mehr" oder "viele" Inhalte hat. Eigentlich ist eher das Gegenteil der Fall.
Ist das Design der Datenbank fehlerhaft oder Abfragen sind nicht optimal, dann wird es spannend.

Man kann MongoDB aber im Detail bei der Arbeit zusehen und so recht schnell rausfinden, was da schief läuft.

Ich würde da auch mal den Webschop und das ERP auf 2 Virtuelle Maschinen Aufteilen. Dann kann das eine System das andere nicht ausbremsen.

Vom Arbeitsspeicher würd ich mir jetzt nicht zu viel versprechen.

Ich würde mir auch mal die Bilder selbst ansehen. Wenn die mit den heute gängigen Kamera Auflösungen im Webschop hinterlegt werden hat man da auch ein schönes Optimierungspotential. Hat aber nichts mit deinem Aktuellen Problem zu tun.

Hallo Leute,

@wieso200:
ich red mal mit dem Kunden ob dieser Bereit ist eine weitere Server Lizenz zu erwerben. Dann wirds aber auch mit den 64 GB des Servers knapp.
Vielleicht hat er ja so 1500€ über

dann hätten wir 128 GB RAM und Luft für 2 weitere VM's

@radiogogu: ob das ne API ist oder ob gebastelt wurde wird dem Kunden wohl eher der Entwickler sagen können als ich

Tak

Das muss man auch erst mal mit den Herstellern der Software abklären. Ob du deswegen mehr Arbeitsspeicher brauchst ist wieder ne andere Frage.

Aber oben Schreibst du von 104 GB fürs ERP und jetzt 64GB?

Aber das Problem und dessen Ursache ergründen ist nicht wichtig?

Ich würde so nicht arbeiten können und große Probleme bekommen.

Wenn ich weiß, dass eine Datenbank auffällig ist, dann fällt mir kein Grund ein ihr den Hubraum zu vergrößern um ggf Probleme zu katalysieren.

Zitat von @wiesi200:

Das muss man auch erst mal mit den Herstellern der Software abklären. Ob du deswegen mehr Arbeitsspeicher brauchst ist wieder ne andere Frage.

Aber oben Schreibst du von 104 GB fürs ERP und jetzt 64GB?

Sorry war ein Denkfehler... Server hat natürlich 128 GB! Verdoppelung wären 256!

Zitat von @142583:

Aber das Problem und dessen Ursache ergründen ist nicht wichtig?

Selbstverständlich ist das wichtig. Hier bin aber ich der falsche Ansprechpartner weswegen sich hier der Entwickler der die MongoDB betreibt kümmern muss.
Die Bereinigung und Reorganisation der ERP DB wird gemacht wenn der Kunde Zeit hat. Laut seiner Aussage dauert eine Reorg ca 10 Stunden. Das muss er nachts oder am WE machen sonst droht ein "Überverkauf" weil das System ja nicht läuft.

Ich würde so nicht arbeiten können und große Probleme bekommen.

Seh ich genauso. Lieber jetzt gleich handeln als das Problem noch 4 Wochen hinausschieben.

Wenn ich weiß, dass eine Datenbank auffällig ist, dann fällt mir kein Grund ein ihr den Hubraum zu vergrößern um ggf Probleme zu katalysieren.

DB Reorg ist der erste Ansatz. Mongo DB der nächste. Mit ersterem komm ich noch zurecht. Microtech ist da recht zugänglich. Bei der Mongo DB muss wie gesagt der Entwickler ran der ihm das installiert hat.

Laut Aussage vom Kunden hat wohl der Entwickler die Last tatsächlich unterschätzt ihm jedoch geraten von ursprünglich 4 VMs am alten Server auf jetzt 2 VM's umzusteigen.
Vorher war wohl
VM1=DC
VM2: Fileserver
VM3.:ERP Server
VM4: APP Server für Entwicklerprogramme

Wäre aber nicht notwendig den RAM hier aufzubohren.

Denn die Maschine wird den RAM vollhauen, egal wie viel du da einbaust.

Besser Ursachenforschung betreiben und dann entsprechend handeln.

Für die BüroPlus VM kannst du den RAM auf 8 oder 16 GB reduzieren, da wird nichts mit passieren. Solange die MongoDB auf derselben VM läuft gibt es aber wohl keine Chance das Teil performant laufen zu lassen.

Je nachdem, was das Programm dahinter ist (Kompatibilität), kann die MongoDB auch auf einem Linux laufen (bezüglich Lizenz-Nachkauf).

Gruß
Radiogugu

Zitat von @takvorian:

Laut Aussage vom Kunden hat wohl der Entwickler die Last tatsächlich unterschätzt ihm jedoch geraten von ursprünglich 4 VMs am alten Server auf jetzt 2 VM's umzusteigen.
Vorher war wohl
VM1=DC
VM2: Fileserver
VM3.:ERP Server
VM4: APP Server für Entwicklerprogramme

Gut Man hat weniger Overhad bei den Server OS aber a sich klinngt der Rat komisch. Eigentlich geht man bei hoher Last eher den anderen Weg.

Aber unsauber Programmierung kann das verursachen. Ist aber ne Vermutung nicht mehr.

Den Weg den du gehen kannst hast du ja gefunden und hört sich auch vernünftig an.

Datenbank Reorganisation hört sich nach 15 jährigen IT-Praktilanten macht vermutlich wenig Sinn.

Zitat von @142583:

Datenbank Reorganisation hört sich nach 15 jährigen IT-Praktilanten macht vermutlich wenig Sinn.

Auch der MS Sql braucht je nachdem gewisse "Wartungstasks" um vernünftig zu arbeiten.
Die Ergebnisse können da sehr unterschiedlich ausfallen. Aber es kann viel bringen.

Ach ja, nun bin ich gespannt wie ein Flitzebogen.

Hallo zusammen,

aktueller Stand der Dinge wollte ich euch nicht vorenthalten.

1. Der Hersteller hat die CPU AMD Epyc 7232P ausgetauscht gegen eine 7262P
--> Warum. Die 7232 ist nur eine Singel Sockel CPU, warum diese je verbaut wurde, keine Ahnung. Zu der jetzigen kann bei Bedarf noch eine 2te hinzugefügt werden.

2. der PC2666 Speicher wurde gegen 3200 getauscht und die Speichermenge verdoppelt auf jetzt 256 GB RAM (8x32 GB)
3. dem ERP Enterprise Server wurden jetzt 96 GB Cache zugewiesen der virtuelle Server bekommt jetzt 150 GB RAM
4. Dem virtuellen DC wurde weiterhin 2vCores und jetzt 8 GB gegönnt.

Laut Aussage des Kunden merkt dieser die Umstellung beim Wareneingang, beim Packen und beim Versand und laut dessen Aussage sogar spürbar um bis zu 20%.
Der Programmierter der Next2Shop also der MongoDB ist der Meinung dass seine DB sauber arbeitet.
Microtech Support kann zur tatsächlichen Auslastung des reservierten Cashes keine Angaben machen. Das könne man angeblich nicht auslesen was im Cache tatsächlich ausgelagert wurde.
Die Microtech Software wurde jezt mit Hilfe des Bereinigungsassistenten verschlankt. Eine Reorganisation der Datenbanken hat noch nicht stattgefunden.
Das Material kostet den Kunden jetzt etwas 1k€ netto.

Ich denke mal dass der gesamte Hypervisor mit 128 GB Ram und den zuweisungen zu den VM's einfach viel zu wenig Ressourcen (RAM) für sich selbst hat nutzen können. Der ERP war ja auch immer am Limit vom RAM gewesen. Jetzt ist Luft nach oben und übertrieben haben wirs mit dem RAM auch nicht.

Besten Dank euch allen für Eure Ratschläge, Einwände etc.
tak

Zitat von @takvorian:
3. dem ERP Enterprise Server wurden jetzt 96 GB Cache zugewiesen der virtuelle Server bekommt jetzt 150 GB RAM

Ist eine Menge Holz.

Der Programmierter der Next2Shop also der MongoDB ist der Meinung dass seine DB sauber arbeitet.

Mag sein, die haben ja keine Probleme.

Ich denke mal dass der gesamte Hypervisor mit 128 GB Ram und den zuweisungen zu den VM's einfach viel zu wenig Ressourcen (RAM) für sich selbst hat nutzen können. Der ERP war ja auch immer am Limit vom RAM gewesen. Jetzt ist Luft nach oben und übertrieben haben wirs mit dem RAM auch nicht.

Natürlich liegt es an der Ressourcen-Zuweisung. Nur die ERP / MongoDB VM ist der Störer des ganzen Konstrukts.

Wurde denn schon geprüft, ob die MongoDB auf eine eigene VM ausgelagert werden kann, oder ist diese zwingend auf der BüroPlus VM zu belassen?

Die insgesamte Verbesserung ist wahrscheinlich nur von kurzer Dauer, je nachdem, wie die Datenbanken mit dem neu gewonnenen Arbeitsspeicher umgehen. Sollte bei der MongoDB eine Speicherbegrenzung konfiguriert worden sein, dann müsste diese ja nun vollends ausgenutzt werden. Damit wird die VM irgendwann wieder stottern.

Wie sind denn jetzt die Auslastungs-Daten? CPU und RAM immer noch kurz vor dem Anschlag?

Gruß
Radiogugu

Natürlich bringt ein 20% schnellerer Server 20% mehr Leistung. Trotzdem arbeitet er an der Belastungsgrenze. Beim nächsten Update kann er wieder 10% verlieren, oder bereits bei leicht steigender Mitarbeiterzahl (2 Mitarbeiter wären schon 20%). Ein Server dieser Art sollte 50 Mitarbeiter locker versorgen können. Die Ursache ist also noch nicht behoben, warum er so beansprucht wird.