HP ProLiant DL380p Gen8 sinnvoll aufrüsten?
Mahlzeit,
macht es Sinn einen DL380p Gen8 noch aufzurüsten?
Welche Max. CPU macht Sinn bei 8 Kernen?
Beispielsweise der RAM: von den 24 RAM Sockeln sind lediglich 8 Stück mit je 16 GB Ram bestückt.
Für eine Datenbanksoftware möchte ich hier gerne aufstocken. Welche Sockelbelegung muss ich beachten.
Aktuell sind alle weissen Sockel belegt und nur die schwarzen noch frei. Ist es da egal, welche ich bestücke?
Vielleicht ist ja hier jemand dabei, der diese guten Stücke schonmal aufgerüstet hat.
Vielen Dank für etwas Unterstützung.
macht es Sinn einen DL380p Gen8 noch aufzurüsten?
Welche Max. CPU macht Sinn bei 8 Kernen?
Beispielsweise der RAM: von den 24 RAM Sockeln sind lediglich 8 Stück mit je 16 GB Ram bestückt.
Für eine Datenbanksoftware möchte ich hier gerne aufstocken. Welche Sockelbelegung muss ich beachten.
Aktuell sind alle weissen Sockel belegt und nur die schwarzen noch frei. Ist es da egal, welche ich bestücke?
Vielleicht ist ja hier jemand dabei, der diese guten Stücke schonmal aufgerüstet hat.
Vielen Dank für etwas Unterstützung.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2239349619
Url: https://administrator.de/forum/hp-proliant-dl380p-gen8-sinnvoll-aufruesten-2239349619.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
40 Kommentare
Neuester Kommentar
Ja, du kannst dich einfach nach der Anleitung richten, zwecks Belegung nicht aus der in der Anleitung abweichen. Es gibt afür eine spezielle für dieses Modell veröffentlichte Speicher Kompatibilitätsliste.
Es gibt auch eine CPU Kompatibilitätsliste. Such dir die größte CPU aus oder wähle nach Anforderung, Verfügbarkeit oder Preis.
Es gibt auch eine CPU Kompatibilitätsliste. Such dir die größte CPU aus oder wähle nach Anforderung, Verfügbarkeit oder Preis.
Moin,
wie @NordicMike schon schrieb: Halte dich ans Manual.
Hier ist das gut beschrieben: https://support.hpe.com/hpesc/public/docDisplay?docId=mmr_kc-0109346
wie @NordicMike schon schrieb: Halte dich ans Manual.
Hier ist das gut beschrieben: https://support.hpe.com/hpesc/public/docDisplay?docId=mmr_kc-0109346
In den QuickSpecs findest du i.d.R. alle von HPE freigegebenen Hardware-Komponenten (also zumindest die Basics CPU, RAM, HDDs) zu der Baureihe:
https://www.hpe.com/psnow/doc/c04123238?jumpid=in_lit-psnow-red
Du solltest nur von HPE gelabelte Teile verwenden.
Die Wirtschaftlichkeit deines Unterfangens hängt schwer davon ab was du für das Aufrüsten bezahlst... Eine G8p nutze ich aber auch noch. Nur würde ich dafür nicht mehr tief in die Tasche greifen.
PS: Der E5-2697 hat 2 Kerne mehr und etwas mehr L2 Cache bei etwas geringerem Takt, dürfte aber auch gebraucht deutlich teurer zu kriegen sein.
https://www.hpe.com/psnow/doc/c04123238?jumpid=in_lit-psnow-red
Du solltest nur von HPE gelabelte Teile verwenden.
Die Wirtschaftlichkeit deines Unterfangens hängt schwer davon ab was du für das Aufrüsten bezahlst... Eine G8p nutze ich aber auch noch. Nur würde ich dafür nicht mehr tief in die Tasche greifen.
PS: Der E5-2697 hat 2 Kerne mehr und etwas mehr L2 Cache bei etwas geringerem Takt, dürfte aber auch gebraucht deutlich teurer zu kriegen sein.
Zitat von @WildStar:
In erster Linie läuft dort ein Warenwirtschaftssystem mit großer Datenbank drauf.
Es soll hier nun ein Upgrade auf WinServer 2022 erfolgen. Und ich habe mich so
Hallo,In erster Linie läuft dort ein Warenwirtschaftssystem mit großer Datenbank drauf.
Es soll hier nun ein Upgrade auf WinServer 2022 erfolgen. Und ich habe mich so
gen8 ist nur bis 2016 supported. Von 2019 und 2022 würde ich die Finger lassen.
Grüße
lcer
Als Gast unter Proxmox kannst du auch 2022 installieren, nur direkt auf dem Blech nicht. Wobei auch das grundsätzlich gehen dürfte nur eben nicht supportet ist.
Welche Auslastung erzeugt die DB denn derzeit? Eine DB braucht selten wirklich viel CPU aber Aussagen dazu sind natürlich reine Spekulation weil wir deine DB nicht kennen.
Welche Auslastung erzeugt die DB denn derzeit? Eine DB braucht selten wirklich viel CPU aber Aussagen dazu sind natürlich reine Spekulation weil wir deine DB nicht kennen.
Moin...
2019 läuft mit ach und krach, Server 2022 lass mal besser sein, das wird nix!
auch wenn du es höhren willst, aber denke über was neues nach...
minimum HP G9... oder G10, alleine durch die einsparungen am Strom rechnet sich das schon!
Ich denke mit der CPU sollte es tatsächlich reichen.
hm..
eine flotte CPU mach im Winter warme Füße..
Bzgl. RAM helft mir bitte nochmal weiter; Bei mir sind jeweils A,B,C und D bestückt.
Kann ich jetzt einfach immer weiter einen Riegel bestücken oder immer paarweise?
Wenn A-D nun je 16 GB haben, dürfte ich denn E-H auch mit 8 GB Modulen ausrüsten oder
muss ich bei 16er bleiben?
bleib bei 16er... hast du nicht oben die Anleitungen gelesen?
Frank
Zitat von @WildStar:
In erster Linie läuft dort ein Warenwirtschaftssystem mit großer Datenbank drauf.
Es soll hier nun ein Upgrade auf WinServer 2022 erfolgen. Und ich habe mich so
an die Mühle gewöhnt.
na ja.. dann gewöhne dich mal an etwas neuem!In erster Linie läuft dort ein Warenwirtschaftssystem mit großer Datenbank drauf.
Es soll hier nun ein Upgrade auf WinServer 2022 erfolgen. Und ich habe mich so
an die Mühle gewöhnt.
2019 läuft mit ach und krach, Server 2022 lass mal besser sein, das wird nix!
auch wenn du es höhren willst, aber denke über was neues nach...
minimum HP G9... oder G10, alleine durch die einsparungen am Strom rechnet sich das schon!
Ich denke mit der CPU sollte es tatsächlich reichen.
eine flotte CPU mach im Winter warme Füße..
Bzgl. RAM helft mir bitte nochmal weiter; Bei mir sind jeweils A,B,C und D bestückt.
Kann ich jetzt einfach immer weiter einen Riegel bestücken oder immer paarweise?
Wenn A-D nun je 16 GB haben, dürfte ich denn E-H auch mit 8 GB Modulen ausrüsten oder
muss ich bei 16er bleiben?
Frank
Zitat von @WildStar:
In erster Linie läuft dort ein Warenwirtschaftssystem mit großer Datenbank drauf.
Es soll hier nun ein Upgrade auf WinServer 2022 erfolgen.
Es soll hier nun ein Upgrade auf WinServer 2022 erfolgen.
Und dem unbekannten Datenbanksystem wird das zusätzliche RAM auch helfen können?
Natürlich wirst du da nicht viel Feedback bekommen, da die Kombination Gen8 mit 2022 einzigartig ist, wenn sie überhaupt läuft. Ich persönlich würde mich nicht trauen Software oder Hardware einzusetzen, die nicht freigegeben ist. Für zu Hause zum experimentieren, ja, aber für einen Betrieb?
Ich würde für einen neuen Servereinsatz auch kein DDR3 mehr einsetzen. Als DSL Router vielleicht :c)
wollte mich nur vergewissern, ob ich es richtig verstanden habe, dass der RAM nicht unbedingt paarweise eingesetzt werden muss.
Wenn es so in der Anleitung steht, kannst du es machen. Falls du es nicht verstehst, sind sicherlich auch Bilder dabei.Ich würde für einen neuen Servereinsatz auch kein DDR3 mehr einsetzen. Als DSL Router vielleicht :c)
Zitat von @WildStar:
Moin mbehrens,
laut Hersteller soll ich 96 GB RAM für die neue Version des Warenwirtschaftssystem explizit zur Verfügung stellen.
was ist das für eine WAWI ? was für ein SQL System, und wie groß ist die DB? anzahl der Mitarbeiter ?Und dem unbekannten Datenbanksystem wird das zusätzliche RAM auch helfen können?
Moin mbehrens,
laut Hersteller soll ich 96 GB RAM für die neue Version des Warenwirtschaftssystem explizit zur Verfügung stellen.
Dann laufen noch ein DC und ein Exchange auf dem Blech.
hm.... ist was viel für die Kiste, findest du nicht? der G8 ist eh nicht der schnellste, und verbraucht mehr strom als er leistung hat!und ja.. wenn die Kiste im Ram Vollausbau ist, braucht es mehr strom.... soviel zu in deiner frage!
in den G8 würde ich keinen euro mehr reinstecken... lohnt sich nicht!
Was limitiert denn einen reibungslosen Ablauf? Laut Specs benötigt man ein Minimum an Hardware für den Server2022. Hast Du hier Erfahrungen?
es mag ja sein, das MS ein Minimum an Hardware sich vorstellt, aber HP mit dem G8 ist da sicher nicht gemeint!
lass es sein....
für deine zwecke brauchst du entweder einen G9 mit Server 2019... (2022 geht auch) oder ein G10 mit Server 2022!
Frank
Also deinem Anliegen fehlen ein paar Informationen. Grundsätzlich kann ich dir folgendes sagen:
- Server 2022 läuft auch auf alter Hardware. Bei mir läuft eine G8p mit 2x E5-2630 v2 unter ESXi 7 U2 auch mit ein paar VMs, unsupported seitens VMware aber läuft. Ist das schnell genug für dich? - keine Ahnung. Zuverlässig sind die Kisten aber hast du einen Plan was du bei einem Ausfall der Hardware machst?
- Die Energieeffizienz ist sicher nicht die Beste aber dadurch rechnet sich nicht immer gleich ein Ersatzserver. Ich nutze die Kiste im Moment fast nur für neue Maschinen und ein paar unwesentliche Hintergrunddienste. Du solltest dir langfristig überlegen wann du wie aufrüstest. Geld für Hardware würde ich in den alten Server nicht mehr investieren, höchstens ein paar Euro für gebrauchten RAM oder so. Deine Fragen sind aber so pauschal das sich daraus kein Plan für die Zukunft erkennen lässt. Sind schon irgendwelche Veränderungen für die Zukunft geplant?
- Eine Datenbank kann sehr viel Performance benötigen und / oder sehr schlechte Performance liefern, z.B. durch fehlerhafte Konfiguration. 96 GB RAM sind viel für eine WaWi DB aber wir wissen auch hier nichts: Nicht welches DBMS, wie viele User, welche WaWi, welche Hardware bisher zum Einsatz kommt, welche Auslastung diese Hardware bisher hat, welches Storrage kommt hinter dem RAM, gibt es bisher Performance Probleme, gibt es Querys die besonders anspruchsvoll sind, gibt es Phasen starker Auslastung, etc., etc. Bei einer so großen Anforderung seitens des Herstellers würde ich diese Details nicht im Forum oder per Google ermitteln sondern mit dem Hersteller diskutieren. Ein so dickes System ist kein Hobby sondern i.d.R. geschäftskritisch, und somit mit Support des Herstellers und unter den Bedingungen des Herstellers zu hosten. Dann ist der gegenüber der Geschäftsleitung in der Pflicht wenn das Ding lahmt und einen Notfallplan brauchst du auch.
Moin...
ihr Arbeitet mit SAP und nicht mit wenig Usern- und dann ein HP G8?
ok, wenn es Finanziell knapp ist, besorge dir wenigstens einen G10... oder zur Not einen G9!
sorry, aber so gehst du über kurz oder lang Baden!
na ja.. mit SAP verstehe ich die 96 GB für den DB Server
Frank
Zitat von @WildStar:
Okay - super, vielen lieben Dank für eure ausführlicheren Antworten. Das sind jetzt mal paar Ansätze.
Hintergrund ist folgender:
ca. 20 MA greifen auf SAP B1 Ver.9.4 (auf 4 Datenbanken)
MSQL läuft als Datenbanksoftware im Hintergrund.
ca. 40 greifen auf den Exchange zu
der DomainController verwaltet ca. 50 Accounts
Aktuell liegt alles verteilt auf 3 Nodes. (wobei der 3 Node eher mit Test-Linux GMs belegt ist.
Ausstattung der Codes je 2x E5-2670 und 96 GB RAM
Alles läuft in der Proxmox Umgebung im Cluster
Das neue SAP B1 Version 10 setzt WinServer2019 voraus und möglichst 96 GB RAM (Empfehlung)
Meine Überlegung war nun einen Node aufzurüsten und diesen dann dediziert dem SAP zur verfügung zu stellen.
UND das Budget ist wie zu vermuten sehr klein. RAM & CPU kosten aktuell gebraucht fast nichts. Darum diese Idee.
wenn ich das so Lese.... kann ich nur mit dem Kopf Schütteln!Okay - super, vielen lieben Dank für eure ausführlicheren Antworten. Das sind jetzt mal paar Ansätze.
Hintergrund ist folgender:
ca. 20 MA greifen auf SAP B1 Ver.9.4 (auf 4 Datenbanken)
MSQL läuft als Datenbanksoftware im Hintergrund.
ca. 40 greifen auf den Exchange zu
der DomainController verwaltet ca. 50 Accounts
Aktuell liegt alles verteilt auf 3 Nodes. (wobei der 3 Node eher mit Test-Linux GMs belegt ist.
Ausstattung der Codes je 2x E5-2670 und 96 GB RAM
Alles läuft in der Proxmox Umgebung im Cluster
Das neue SAP B1 Version 10 setzt WinServer2019 voraus und möglichst 96 GB RAM (Empfehlung)
Meine Überlegung war nun einen Node aufzurüsten und diesen dann dediziert dem SAP zur verfügung zu stellen.
UND das Budget ist wie zu vermuten sehr klein. RAM & CPU kosten aktuell gebraucht fast nichts. Darum diese Idee.
ihr Arbeitet mit SAP und nicht mit wenig Usern- und dann ein HP G8?
ok, wenn es Finanziell knapp ist, besorge dir wenigstens einen G10... oder zur Not einen G9!
sorry, aber so gehst du über kurz oder lang Baden!
na ja.. mit SAP verstehe ich die 96 GB für den DB Server
Frank
Moin,
ich würde auch mal überlegen, ob man den NODE nicht ersetzt.
wenn euch 2TB auf der SSD ausreichen sollten:
https://mcl.de/shop/p/hpe-dl325-gen10-7302p-16c-128gb-2x1.92tb-ssd/dl325 ...
Es ist zwar "nur" ein Single-CPU-Socket-System mit 'ner AMD-CPU
Sollte aber ausreichen. Sprich mal den den Jungs von MCL (oder auch anderen HPE-Partner).
Die erforderlichen Windows 2022-Lizenzen sind da beinahe gleichauf (nebst den erforderlichen CALs)...
Gruß
em-pie
ich würde auch mal überlegen, ob man den NODE nicht ersetzt.
wenn euch 2TB auf der SSD ausreichen sollten:
https://mcl.de/shop/p/hpe-dl325-gen10-7302p-16c-128gb-2x1.92tb-ssd/dl325 ...
Es ist zwar "nur" ein Single-CPU-Socket-System mit 'ner AMD-CPU
Sollte aber ausreichen. Sprich mal den den Jungs von MCL (oder auch anderen HPE-Partner).
Die erforderlichen Windows 2022-Lizenzen sind da beinahe gleichauf (nebst den erforderlichen CALs)...
Gruß
em-pie
Unter welchem OS (und welcher DB) läuft SAP 9.4 derzeit? Also ich hab 2012 R2 seit Jahren und jetzt ein paar 2022 aufgesetzt. Gefühlt bootet der 2022 etwas behäbiger aber im laufenden Betrieb würde ich sagen verbraucht der jetzt kaum mehr Ressourcen, da macht Windows Server irgendwie keine großen Sprünge beim Bedarf.
MSSQL wird eher flotter in einer neuen Version, neue Features werden ja von Software selten direkt genutzt.
Blackbox wäre für mich SAP, da wird vermutlich mit einer neuen Version auch mehr Performance gebraucht.
Aber auch wenn du jetzt einen (besser alle) Nodes aufrüstest musst du zwei Dinge beachten:
1) kann dir der Node ja durch Defekt weg brechen, du musst dir überlegen ob du mit den anderen dann noch genug Power hast oder was du machst. Stillstand kann sehr teuer werden, das sollte auch der GL klar sein.
2) Läuft das dann eventuell noch etwas weiter aber irgendwann muss einfach auch mal neue Hardware her. Wenn das Geld knapp ist sollte man dem Chef damit nicht erst kommen wenn alles aus dem letzten Loch pfeift.
MSSQL wird eher flotter in einer neuen Version, neue Features werden ja von Software selten direkt genutzt.
Blackbox wäre für mich SAP, da wird vermutlich mit einer neuen Version auch mehr Performance gebraucht.
Aber auch wenn du jetzt einen (besser alle) Nodes aufrüstest musst du zwei Dinge beachten:
1) kann dir der Node ja durch Defekt weg brechen, du musst dir überlegen ob du mit den anderen dann noch genug Power hast oder was du machst. Stillstand kann sehr teuer werden, das sollte auch der GL klar sein.
2) Läuft das dann eventuell noch etwas weiter aber irgendwann muss einfach auch mal neue Hardware her. Wenn das Geld knapp ist sollte man dem Chef damit nicht erst kommen wenn alles aus dem letzten Loch pfeift.
Moin...
ich habe dir ja geschrieben, was du mindestenst brauchst!
Frank
Zitat von @WildStar:
Danke Frank, das ist eine Aussage.
Ich habe mit dem HP Gen8 in den letzten Jahren sehr gute Erfahrungen gemacht. Lauft alles sehr stabil.
Dachte hiermit komme ich noch 5 Jahre aus.
Puh ... dann werde ich mal ein neues Thema aufmachen und einen neuen Server zusammenstellen.
Wäre super, wenn ich hier ebenfalls eure Unterstützung bekomme.
denkt erstmal über euer Budget nach... was sollen wir vorschlagen, wenn in deinen antworten zu teuer zu lesen ist!Danke Frank, das ist eine Aussage.
Ich habe mit dem HP Gen8 in den letzten Jahren sehr gute Erfahrungen gemacht. Lauft alles sehr stabil.
Dachte hiermit komme ich noch 5 Jahre aus.
Puh ... dann werde ich mal ein neues Thema aufmachen und einen neuen Server zusammenstellen.
Wäre super, wenn ich hier ebenfalls eure Unterstützung bekomme.
ich habe dir ja geschrieben, was du mindestenst brauchst!
Frank
Zitat von @NordicMike:
SAP kostet mehr als die Hardware. Warum ist der Hardware Budget so klein und der Software Budget so groß?
SAP kostet mehr als die Hardware. Warum ist der Hardware Budget so klein und der Software Budget so groß?
na weil die Software ja schon sooo Teuer ist!
Frank
Zitat von @NordicMike:
na weil die Software ja schon sooo Teuer ist!
Dann fällt doch die Hardware nicht mehr ins Gewicht :c)kommt auf das portemonnaie an... wenn Leer, dann Leer
das erlebe ich öfter bei Kunden!
Frank
Entscheidend wäre für mich nicht warum etwas neues gekauft oder nicht gekauft wird sondern wer das entscheidet. Wenn du auf eigene Faust sagst wir sparen etwas Geld ist das ja nett. Wenn morgen der Laden steht und der Chef fragt warum man auf alte Hardware ohne Support gesetzt hat und keine Leistungsreserve mehr vorhanden ist dann möchte ich ihm sagen können so und so habe ich das dargelegt, so und so wurde das entschieden und von der GL mit getragen.
Ich kann mit meiner G8p und 2x G7 Kaltreserve + Runterfahren unkritischer Systeme den Ausfall einer G10 verkraften, das kann ich vertreten. Wenn du einen DL hast hat der vielleicht auch was auf Lager was er kurzfristig hin stellen kann aber darauf muss man sich auch verlassen können. Gar kein Plan kann sehr teuer werden.
Ich kann mit meiner G8p und 2x G7 Kaltreserve + Runterfahren unkritischer Systeme den Ausfall einer G10 verkraften, das kann ich vertreten. Wenn du einen DL hast hat der vielleicht auch was auf Lager was er kurzfristig hin stellen kann aber darauf muss man sich auch verlassen können. Gar kein Plan kann sehr teuer werden.
Ich habe zwei Bleche eingeplant. Auf jeden Blech jeweils eine VM mit einem DC, auf jedem Blech einen RDS. Wenn ein Blech ausfällt, ist das andere Blech noch da. Server mit DDR3 misten wir aus. Ich würde auf keinen fall nochmal so einen alten Schinken wieder in Betrieb nehmen. DDR4 ist minimum für ordentliche Performance.
Hallo ,
Dein Ram Ausbau sollte sich IMMER nach der Anzahl Channels deiner CPU richten.
Hat die CPU zum Beispiel 4 Channels, wie in deinem Fall, dann im Minimum 4 Ram Riegel / CPU.
und dann auch wirklich nur mit diesen Faktor erweitern.
Wenn 4 pro CPU nicht reichen, dann 8 verwenden, oder 12.
Aber Achtung; ggf nimmt die Ram Speed ab, wenn du 3 DIMM's pro Channel betreibst.
Wirkt sich dann auch eher negativ auf die Gesamtleistung aus.
Dein Server sollte eigentlich auch die v2 CPU's vertragen.
Damit gäbe es noch die CPU E5-2697 v2 mit 12 Core's (2.7 GHz) und nochmals mehr Cache (30MB)
Oder den E5-2690v2 mit 10 Cores (3.0 GHz), aber "nur" 25MB Cache.
Datenbanken können in der Regel sehr gut mit mehreren Core's umgehen.
Habe aber leider auch schon anderes gesehen bei uns. Ist Applikations-abhänig, nicht nur SQL Abhängig.
Ganz wichtig bei der Virtualisierung auch die CPU Ready Time im Auge behalten.
VMware hat da ein ganz gute Ansicht. Keine Ahnung, ob Proxmox dies auch anzeigt.
Was ich damit sagen möchte.
NICHT unnötig viel vCPU's zuweisen, wenn sie NICHT wirklich gebraucht werden. GANZ WICHTIG
Dies kann die Leistung aller Server negativ beinträchtigen.
Wir hatten auch mal die ein oder anderen Performance Schwankungen, bis wir uns der Thematik angenommen haben.
Wir haben über all unsere virtuellen Server sicherlich 50vCPU's reduziert (bei ca. 200 VM's) und danach eine deutlich stabilere Performance erzielt, weil die CPU Ready Time wieder im "grünen" Bereich lag.
Wenn du die Anzeige im Proxmox nicht hast, einfach das System mal beobachten, was die CPU Auslastung anbelangt. Wenn die Kiste praktisch "nie" über 50% kommt, dann würde ich ganz klar die vCPU-Ressourcen reduzieren. Also hat die Kiste z.B. 6 vCPU's, würde ich in diesem Fall auf 4 vCPU zurück gehen.
Und JA ich weiss, es ist ein ewiger Kampf mit dem Software Lieferanten, weil sie Anforderungen stellen, die selten wirklich gebraucht werden. Und gerne auch mal auf dieses bestehen.
Aber wenn ich auf jeden hören würde, müssten wir unsere ESX Umgebung vermutlich verdoppeln; und dies ohne nennenswerten Mehrleistung für die Applikation. Ich konnte mich da oft sehr gut durchsetzen.
Aber ist natürlich auch immer eine Frage, wie sehr dein Chef da hinter dir steht, wenn der Anbieter ihm im Ohr liegt, dass du nicht genügen CPU's zuweisen möchtest, wie er es gerne hätte.
Viel Glück
Dein Ram Ausbau sollte sich IMMER nach der Anzahl Channels deiner CPU richten.
Hat die CPU zum Beispiel 4 Channels, wie in deinem Fall, dann im Minimum 4 Ram Riegel / CPU.
und dann auch wirklich nur mit diesen Faktor erweitern.
Wenn 4 pro CPU nicht reichen, dann 8 verwenden, oder 12.
Aber Achtung; ggf nimmt die Ram Speed ab, wenn du 3 DIMM's pro Channel betreibst.
Wirkt sich dann auch eher negativ auf die Gesamtleistung aus.
Dein Server sollte eigentlich auch die v2 CPU's vertragen.
Damit gäbe es noch die CPU E5-2697 v2 mit 12 Core's (2.7 GHz) und nochmals mehr Cache (30MB)
Oder den E5-2690v2 mit 10 Cores (3.0 GHz), aber "nur" 25MB Cache.
Datenbanken können in der Regel sehr gut mit mehreren Core's umgehen.
Habe aber leider auch schon anderes gesehen bei uns. Ist Applikations-abhänig, nicht nur SQL Abhängig.
Ganz wichtig bei der Virtualisierung auch die CPU Ready Time im Auge behalten.
VMware hat da ein ganz gute Ansicht. Keine Ahnung, ob Proxmox dies auch anzeigt.
Was ich damit sagen möchte.
NICHT unnötig viel vCPU's zuweisen, wenn sie NICHT wirklich gebraucht werden. GANZ WICHTIG
Dies kann die Leistung aller Server negativ beinträchtigen.
Wir hatten auch mal die ein oder anderen Performance Schwankungen, bis wir uns der Thematik angenommen haben.
Wir haben über all unsere virtuellen Server sicherlich 50vCPU's reduziert (bei ca. 200 VM's) und danach eine deutlich stabilere Performance erzielt, weil die CPU Ready Time wieder im "grünen" Bereich lag.
Wenn du die Anzeige im Proxmox nicht hast, einfach das System mal beobachten, was die CPU Auslastung anbelangt. Wenn die Kiste praktisch "nie" über 50% kommt, dann würde ich ganz klar die vCPU-Ressourcen reduzieren. Also hat die Kiste z.B. 6 vCPU's, würde ich in diesem Fall auf 4 vCPU zurück gehen.
Und JA ich weiss, es ist ein ewiger Kampf mit dem Software Lieferanten, weil sie Anforderungen stellen, die selten wirklich gebraucht werden. Und gerne auch mal auf dieses bestehen.
Aber wenn ich auf jeden hören würde, müssten wir unsere ESX Umgebung vermutlich verdoppeln; und dies ohne nennenswerten Mehrleistung für die Applikation. Ich konnte mich da oft sehr gut durchsetzen.
Aber ist natürlich auch immer eine Frage, wie sehr dein Chef da hinter dir steht, wenn der Anbieter ihm im Ohr liegt, dass du nicht genügen CPU's zuweisen möchtest, wie er es gerne hätte.
Viel Glück
Wenn ich richtig verstanden habe, nutzt ihr SQL darunter.
Wird dies von jemanden betreut? Der was davon versteht?
Hier kann man sicherlich auch sehr viele Ressourcen "verbrennen", wenn die Installation nicht auch mal ab und an Reviewed wird. 2 Hauptprobleme sicherlich Defragmentierung und Indexe
Als ich vor 13 Jahren bei uns angefangen habe, hiess es auch, dass das Labor System alle 1-2 Jahre einen neuen SQL Server benötigt, wegen der Perfomance. (damals war dies jedes Mal eine neues Blech)
Also bei SQL ist mehr und neuere CPU's nicht immer die Lösung der Probleme.
Problem war, dass keiner die DB im Griff hatte und somit immer mehr Ressourcen benötigte.
Stand heute läuft die Datenbank mit zig anderen Applikationen auf einer Instance und es gibt keinerlei Performance Probleme. Und auf dem SQL Cluster gibt es noch mehrere Instanzen daneben.
Ist alles eine Frage der Wartung der DB's bzw. Instanzen von Spezialisten.
Bei uns ein externer Dienstleister der sich ausschliesslich dem Thema Datenbanken gewidmet hat.
Aber klar, da ist auch schnell mal ein Tag Dienstleistung für die Analyse "verbrannt"; und da ist noch nix gefixt.
Aber wenn ihr mehrere Datenbanken habt und sich da keiner nie darum kümmert, wäre es der Aufwand sicherlich wert. Je älter und grösser die Datenbank um so mehr wird da vermutlich raus kommen.
Und wichtig; bei den Datenbank-Servern nie an RAM sparen. Wäre definitiv der falsche Ort zum Sparen.
Und wenn immer möglich die TXLog- und TmpDB- Files der DB auf sehr schnelle Disk's legen. Im Idealfall NVMe.
Wird dies von jemanden betreut? Der was davon versteht?
Hier kann man sicherlich auch sehr viele Ressourcen "verbrennen", wenn die Installation nicht auch mal ab und an Reviewed wird. 2 Hauptprobleme sicherlich Defragmentierung und Indexe
Als ich vor 13 Jahren bei uns angefangen habe, hiess es auch, dass das Labor System alle 1-2 Jahre einen neuen SQL Server benötigt, wegen der Perfomance. (damals war dies jedes Mal eine neues Blech)
Also bei SQL ist mehr und neuere CPU's nicht immer die Lösung der Probleme.
Problem war, dass keiner die DB im Griff hatte und somit immer mehr Ressourcen benötigte.
Stand heute läuft die Datenbank mit zig anderen Applikationen auf einer Instance und es gibt keinerlei Performance Probleme. Und auf dem SQL Cluster gibt es noch mehrere Instanzen daneben.
Ist alles eine Frage der Wartung der DB's bzw. Instanzen von Spezialisten.
Bei uns ein externer Dienstleister der sich ausschliesslich dem Thema Datenbanken gewidmet hat.
Aber klar, da ist auch schnell mal ein Tag Dienstleistung für die Analyse "verbrannt"; und da ist noch nix gefixt.
Aber wenn ihr mehrere Datenbanken habt und sich da keiner nie darum kümmert, wäre es der Aufwand sicherlich wert. Je älter und grösser die Datenbank um so mehr wird da vermutlich raus kommen.
Und wichtig; bei den Datenbank-Servern nie an RAM sparen. Wäre definitiv der falsche Ort zum Sparen.
Und wenn immer möglich die TXLog- und TmpDB- Files der DB auf sehr schnelle Disk's legen. Im Idealfall NVMe.
Du solltest auf jeden Fall die Vorgaben von SAP mit beachten. Wenn die Hardware nicht passt, könnte es im Supportfall teuer (SAP lässt sich den Support bezahlen) oder kompliziert (Du musst mal eben auf eine freigegebene Hardware umziehen) werden.
Ich kenne mich allerdings nur mit dem großen SAP aus, B1 durfte ich noch nicht live erleben.
CU
Ich kenne mich allerdings nur mit dem großen SAP aus, B1 durfte ich noch nicht live erleben.
CU
Also im SOHO Segment werden Datenbanken ja von der Anwendung supportet und dementsprechend auch mit der Anwendung optimiert / gewartet. Das trifft sicher auch auf SAP Instanzen zu, da sollte kein ernannter DB Admin Hand anlegen und irgendwas "optimieren", das wird am ehesten teuer.
Wenn man Individualsoftware betreibt ist Rolands Einwand sicherlich berechtigt aber sonst würde ich mal sagen mit Hersteller und Lieferant die Performanceprobleme besprechen oder deren Empfehlungen umsetzen, ansonsten Finger weg.
Das MSSQL Studio startet abhängig von der Client Performance schnell oder langsam, das hat nichts mit der DB zu tun. Es sei denn natürlich das Studio läuft auf der selben Maschine.
Wenn man Individualsoftware betreibt ist Rolands Einwand sicherlich berechtigt aber sonst würde ich mal sagen mit Hersteller und Lieferant die Performanceprobleme besprechen oder deren Empfehlungen umsetzen, ansonsten Finger weg.
Das MSSQL Studio startet abhängig von der Client Performance schnell oder langsam, das hat nichts mit der DB zu tun. Es sei denn natürlich das Studio läuft auf der selben Maschine.
Ich hoffe mal sehr, dass dies bei SAP so ist. Wir haben kein SAP und kann es nicht beurteilen.
Wir haben in der Vergangenheit leider schon etliche Softwarelieferanten gesehen, welche ihre Datenbanken leider NICHT im Griff haben.
Gefühlt hat da oft der Entwickler nicht mal das nötige KnowHow um die Applikation so zu programmieren, dass dieser auf dem SQL auch wirklich performant läuft.
Habe da leider leider schon alles erleben müssen.
Aber im Medizinalumfeld kann man leider nicht mal schnell von einer Lösung auf die andere springen.
Und im schlimmsten Fall kommst du vom Regen in die Traufe.
Und ja, das SQL MGMT Studio wir gefühlt auch immer langsamer beim Aufstarten. Tut nichts zur Performance.
Schwierig wird es, wenn dann das Verbinden auf die DB so lange dauert.
Wir haben in der Vergangenheit leider schon etliche Softwarelieferanten gesehen, welche ihre Datenbanken leider NICHT im Griff haben.
Gefühlt hat da oft der Entwickler nicht mal das nötige KnowHow um die Applikation so zu programmieren, dass dieser auf dem SQL auch wirklich performant läuft.
Habe da leider leider schon alles erleben müssen.
Aber im Medizinalumfeld kann man leider nicht mal schnell von einer Lösung auf die andere springen.
Und im schlimmsten Fall kommst du vom Regen in die Traufe.
Und ja, das SQL MGMT Studio wir gefühlt auch immer langsamer beim Aufstarten. Tut nichts zur Performance.
Schwierig wird es, wenn dann das Verbinden auf die DB so lange dauert.
Ist schon richtig das viele Hersteller und vor allem Anwendungsentwickler irgendwie gar keine Ahnung zu haben scheinen. Jedenfalls sind die meisten Datenbanken eher gruselig allein schon was Struktur, Benennung oder so langweilige Dinge wie referentielle Integrität angeht. Dennoch kann man da als Admin nur selten was dran ändern und sollte das nie ohne Support des Herstellers tun. (Ja mache ich trotzdem bei ein paar Kleinigkeiten aber auch das hat mir selbst schon Probleme bereitet.)