Performance

[Tom7320]

Hallo allerseits!

Ich setze PVE in einer Arztpraxis ein. Die wesentliche Anwendung ist die Praxissoftware, die auf einer Windows Server 2016 VM läuft und Firebird als Datenbank verwendet. Damit ist die Performance gefühlt ganz ok, aber es fehlt noch ein Quäntchen an Geschwindigkeit und "Schwupdizität".

Darüber habe ich mich lange mit dem Dienstleister für die Praxissoftware unterhalten. Er meint, es läge an der Virtualisierung. Meiner Meinung nach liegt es eher an den SAS HDDs, die im Server verbaut sind (Specs siehe unten).

Bevor ich aber entweder Windows Server 2016 nativ auf dem Server installiere oder teure Server SSDs anschaffe, wollte ich Euch fragen, wie denn Eure Meinung dazu ist? Was bringt den größeren Performancegewinn bei besagter Datenbankanwendung (Firebird) unter Windows Server 2016? Auf die Virtualisierung verzichten oder auf SSDs umsteigen? Oder etwas ganz anderes? Über Eure Erfahrungen aus der Praxis wäre ich sehr dankbar!

Hier die Specs des Servers:

• HPE ProLiant DL360 Gen9 E5-2620v4
• HPE 16 GB RAM
• 3x HPE HPE 300 GB SAS 10K SFF SC DS HDD im RAID 1 mit Spare
• 3x HPE HPE 600 GB SAS 10K SFF SC DS HDD im RAIS 1 mit Spare

Die Windows Server 2016 VM:


Vielen Dank!

Beste Grüße

Thorsten

 

[mac.linux.free]

Hallo Thorsten,

wir haben auch mehrere Zahnarztkunden die nur auf Proxmox setzen (dank uns).
Weil wir aber von Anfang an auf mindesten Raid10 oder ZFS setzen gibt es sehr selten Performanceprobleme.
Eine SSD oder eine NVME ist dann natürlich die Königsdiziplin. Wir verbauen meistens 2x NVME und machen dann ein ZFS Raid1 drauf.
Das spart einen Raid-Controller. Dafür sollte der Host allerdings mind. 64GB Ram haben.

Grüße
Marco

 

[sb-jw]

Der Host hat 16GB RAM und die VM auch, das sollte man definitiv unterlassen - das kann nachher zu einem Ausfall führen, entweder weil der Node ausfällt oder weil der KVM Prozess gekillt wird. Eventuell Swapped die Kiste auch bereits, was sich ebenfalls negativ auf die Performance auswirken kann.

Generell ist ein RAID1 auch nicht das schnellste, entweder es gibt hier noch die Möglichkeit den Cache auf dem Controller zu aktivieren oder ich würde dir auch zu einem RAID10 raten. Eventuell upgradest du einfach die 3x 300GB auf 3x 600GB und machst ein RAID 10 aus 6 Disks.
Ein Upgrade auf SSDs bringt sicherlich in jeglicher Konstellation etwas, dafür solltest du aber ein HBA haben und ZFS oder ähnliches einsetzen damit TRIM weiterhin supported ist.
NVMe sind hier glaube wirklich nur ein nice to have, ich sehe dafür eigentlich keine Erforderlichkeit bei diesem Anwendungsfall. Wenn der Arzt nachher aber dafür bezahlen möchte, meinetwegen

 

[Tom7320]

Hallo!

Danke für Eure sehr hilfreichen Antworten! Die Zahnarztpraxis-Luxusvariante können sich Zahnärzte sicher leisten. In meinem Fall handelt es sich um eine kleinere Landarztpraxis. Der "Server" vorher war im Prinzip ein einfacher PC, an dem niemand gearbeitet hat. Insofern war die Investition in den genannten Server schon wirklich eine Hausnummer! Ursprünglich sollte da Windows 2016 drauf ohne Virtualisierung; daher die seltsamen HDD-Größen....

Der Host hat 16GB RAM und die VM auch, das sollte man definitiv unterlassen - das kann nachher zu einem Ausfall führen, entweder weil der Node ausfällt oder weil der KVM Prozess gekillt wird. Eventuell Swapped die Kiste auch bereits, was sich ebenfalls negativ auf die Performance auswirken kann.

Alles klar. Danke! Habe ich geändert. Aber Speicher überprovisionieren sollte schon gehen, oder? Also z.B. drei VMs mit je 8 GB Speicher bei physisch vorhandenen 16 GB? So "schlau" ist der Hypervisor, oder?

Generell ist ein RAID1 auch nicht das schnellste, entweder es gibt hier noch die Möglichkeit den Cache auf dem Controller zu aktivieren oder ich würde dir auch zu einem RAID10 raten. Eventuell upgradest du einfach die 3x 300GB auf 3x 600GB und machst ein RAID 10 aus 6 Disks.

OK. Aber bevor ich noch drei SAS HDDs kaufe, kaufe ich lieber drei kleine SSDs. Oder würdest Du das anders machen? Cache schaue ich mir an!

Ein Upgrade auf SSDs bringt sicherlich in jeglicher Konstellation etwas, dafür solltest du aber ein HBA haben und ZFS oder ähnliches einsetzen damit TRIM weiterhin supported ist.

Hm. Wir haben in der Kiste den HPE Smart Array P440ar Controller. Der sollte doch TRIM supporten, oder?

NVMe sind hier glaube wirklich nur ein nice to have, ich sehe dafür eigentlich keine Erforderlichkeit bei diesem Anwendungsfall. Wenn der Arzt nachher aber dafür bezahlen möchte, meinetwegen

Der Arzt ist meine Frau und ich mache das so nebenher. Wenn ich Geld ausgebe für SSDs und es hinterher nicht schneller läuft, bekomme ich ordentlich Ärger zu Hause....

Um zur Ausgangsfrage zurückzukommen: angenommen ihr wärt in meiner Lage mit einem sehr beschränkten Budget. Was würdet ihr zuerst tun: mehr RAM, auf SSDs umrüsten oder tatsächlich auf PVE verzichten und Win 2016 direkt installieren?

Beste Grüße und noch einen schönen Sonntag!

Thorsten

 

[sb-jw]

Aber Speicher überprovisionieren sollte schon gehen, oder? Also z.B. drei VMs mit je 8 GB Speicher bei physisch vorhandenen 16 GB? So "schlau" ist der Hypervisor, oder?

Naja bei deinem "kleinen" Setup wird das vermutlich in die Hose gehen. Du hast 24GB RAM die du zuweist, hast aber physikalisch nur 16GB zur Verfügung. Ich möchte hier mal behaupten, dass KSM bei dir keine 8GB RAM wegnehmen kann, denn ein Windows selbst verbraucht nicht soviel, wenn du dann drei verschiedene Services auf den VMs betreibst und damit die Wahrscheinlichkeit der Überschneidungen bei einer Pages nicht mehr wirklich gegeben ist, wird dir KSM hier vielleicht 2 - 4GB RAM entlasten können.
KSM wirkt auch nicht instant sondern erst ab 80% RAM Auslastung, in diesem Moment geht auch etwas CPU Leistung drauf, da die Pages erst mal gesucht und gefunden werden müssen. Dann hast du ggf. das Problem, sollte eine Applikation mal unsauber sein und sich allen RAM nehmen wollen, dass KSM gar nicht so schnell ist oder hier auch schlicht gar nicht funktioniert - dann bist du wieder in der Situation wo irgendwas für freien RAM dran glauben muss und der OOM Killer zuschlägt.

Hast du hingegen einen großen HV mit z.B. 24 Kernen und 144GB RAM und lässt dort z.B. 100 VMs mit Debian laufen, ist die Wahrscheinlichkeit doch schon sehr hoch, dass KSM dir sehr viel Last nimmt und du den Node wunderbar, bis zu einem bestimmten Punkt, überbuchen kannst.

Aber bevor ich noch drei SAS HDDs kaufe, kaufe ich lieber drei kleine SSDs. Oder würdest Du das anders machen?

Das hängt davon ab, wie die finanziellen Mittel sind.
Grundsätzlich brauchst du bei SSDs schon wieder einen HBA, der auch entsprechend TRIM vom OS durchlässt, sonst sind deine SSDs ggf. schneller kaputt oder langsamer als du gucken kannst.
Weiterhin ist auch die Frage des nötigen Speicherplatzes. Ich würde dir auch keine Consumer SSDs empfehlen sondern z.B. die Samsung PM883, hier solltest du wirklich nicht am falschen Ende sparen.

Ich bin aber auch der Meinung, dass viele tatsächlich die Performance einer SSD gar nicht benötigen. Meine Synology DS1618+ hat 6x 2TB im RAID5, ich kann ohne Probleme größere Files mit einem Stream von 1GbE drauf schreiben. Es sind nur WD Red mit 5400RPM, die masse an Spindeln hilft hier aber deutlich.

Wir haben in der Kiste den HPE Smart Array P440ar Controller. Der sollte doch TRIM supporten, oder?

Lt. Specs tut er das aber nicht, auch weil es ein RAID Controller und kein HBA ist. Der TRIM befehlt kommt ja vom FS oder Applikation je nach Implementierung. Der Controller empfängt den Befehl und weiß nicht was das FS etc. will und verwirft es in der Regel. Im Zweifel musst du dich mal an den HP Support wenden und dort nachfragen.

Wenn ich Geld ausgebe für SSDs und es hinterher nicht schneller läuft, bekomme ich ordentlich Ärger zu Hause....

Dann kann ich dir sagen, deine Frau hat immer Recht
Es kann schneller laufen, es muss aber nicht - das kann man nie so genau sagen, da es eben manchmal auch vom Anwendungsfall abhängt. Grundsätzlich sind SSDs deutlich besser als SATA HDDs oder auch teils SAS Disks.

angenommen ihr wärt in meiner Lage mit einem sehr beschränkten Budget. Was würdet ihr zuerst tun: mehr RAM, auf SSDs umrüsten oder tatsächlich auf PVE verzichten und Win 2016 direkt installieren?

Den RAM solltest du definitiv aufrüsten, auch der Node sollte noch etwa vom RAM haben, daher immer etwas mehr RAM haben als zugewiesen. RAM kann man grundsätzlich NIE genug haben.
SSDs wie gesagt nur bedingt nötig, ein RAID10 mit mehr Disks wird hier sicherlich mehr Performance bringen und von den Kosten vermutlich auch günstiger sein. Das hängt aber davon ab, ob du die Teile original bei HP bestellst oder dir andere Händler suchst. Bei alternativen Händerln kannst du nämlich deutlich Geld einsparen und damit den Server günstiger aufrüsten.

Auf PVE würde ich nicht mehr verzichten, du nimmst dir damit meiner Meinung nach mehr Vorteile weg als du Nachteile hast.

 

[Ingo S]

Ich hab jetzt nicht 100% alles gelesen, aber, wenn ich Praxissoftware höre, Firebird DB und Performance/Schwubdizitäts Probleme, dann fällt mir sofort eine Anwendung ein: Theorg. Kann das sein?

Wir haben das hier im Einsatz und mit der Performance eine Jahrelange Odyssee hinter uns, letztendlich das Problem aber gefunden und in den Griff bekommen.
Die Ursache war bei uns, das mehr als ein Arbeitsplatz (hier 2) via SMB auf eine Installation zugegriffen haben. Der Server hatte richtig viel RAM, der Speicher bestand aus SSDs aber trotzdem war es super langsam, gerade was Kalender und längere Listen anging.
Bei uns ließ sich das lösen, in dem die Arbeitsplätze nicht mehr per SMB auf das Programm zugreifen, sondern die Anwendung wird jetzt per RDP als Fenster auf den Arbeitsplatz geholt. Somit läuft jeglicher IO lokal auf dem Server. Seither sind die Probleme wie weggezaubert.
Die Firebird DB mag es anscheinend absolut nicht, via SMB angesprochen zu werden.

 

[Tom7320]

Ich hab jetzt nicht 100% alles gelesen, aber, wenn ich Praxissoftware höre, Firebird DB und Performance/Schwubdizitäts Probleme, dann fällt mir sofort eine Anwendung ein: Theorg. Kann das sein?

Wir haben das hier im Einsatz und mit der Performance eine Jahrelange Odyssee hinter uns, letztendlich das Problem aber gefunden und in den Griff bekommen.
Die Ursache war bei uns, das mehr als ein Arbeitsplatz (hier 2) via SMB auf eine Installation zugegriffen haben. Der Server hatte richtig viel RAM, der Speicher bestand aus SSDs aber trotzdem war es super langsam, gerade was Kalender und längere Listen anging.
Bei uns ließ sich das lösen, in dem die Arbeitsplätze nicht mehr per SMB auf das Programm zugreifen, sondern die Anwendung wird jetzt per RDP als Fenster auf den Arbeitsplatz geholt. Somit läuft jeglicher IO lokal auf dem Server. Seither sind die Probleme wie weggezaubert.
Die Firebird DB mag es anscheinend absolut nicht, via SMB angesprochen zu werden.

Nein die Software heißt Medical Office von Indamed. Diese nutzt allerdings auch Firebird als DB. Für Medical Office gibt es eine Clientsoftware, die die DB "ganz normal" per TCP/3050 anspricht. DB File per SMB angesprochen? Klingt gruselig in meinen Ohren!

 

[Tom7320]

Hast du hingegen einen großen HV mit z.B. 24 Kernen und 144GB RAM und lässt dort z.B. 100 VMs mit Debian laufen, ist die Wahrscheinlichkeit doch schon sehr hoch, dass KSM dir sehr viel Last nimmt und du den Node wunderbar, bis zu einem bestimmten Punkt, überbuchen kannst.

Bin ich weit davon entfernt! Aber klingt cool! Würde ich ja soooo gerne mal im Betrieb sehen so ein Setup!

Das hängt davon ab, wie die finanziellen Mittel sind.
Grundsätzlich brauchst du bei SSDs schon wieder einen HBA, der auch entsprechend TRIM vom OS durchlässt, sonst sind deine SSDs ggf. schneller kaputt oder langsamer als du gucken kannst.
Weiterhin ist auch die Frage des nötigen Speicherplatzes. Ich würde dir auch keine Consumer SSDs empfehlen sondern z.B. die Samsung PM883, hier solltest du wirklich nicht am falschen Ende sparen.

Die finanziellen Mittel sind.... naja.... beschränkt würde ich sagen. Warum brauche ich einen HBA? Ich brauchen entweder einen HBA für ZFS oder einen Hardware-RAID-Controller, der SSD unterstützt (z.B. TRIM), für Hardware RAID. Korrekt?

Drei dieser SSDs für RAID 1 plus Spare würden mir reichen (Investition so um die 1000 EUR).

Lt. Specs tut er das aber nicht, auch weil es ein RAID Controller und kein HBA ist. Der TRIM befehlt kommt ja vom FS oder Applikation je nach Implementierung. Der Controller empfängt den Befehl und weiß nicht was das FS etc. will und verwirft es in der Regel. Im Zweifel musst du dich mal an den HP Support wenden und dort nachfragen.

Das ist tatsächlich blöd! D.h. - wie oben schon geschrieben - bräuchte ich, wenn ich SSDs einsetzen wollte, entweder mehr RAM für HBA und ZFS oder einen RAID Controller, der SSDs unterstützt.

Dann kann ich dir sagen, deine Frau hat immer Recht

Es kann schneller laufen, es muss aber nicht - das kann man nie so genau sagen, da es eben manchmal auch vom Anwendungsfall abhängt. Grundsätzlich sind SSDs deutlich besser als SATA HDDs oder auch teils SAS Disks.

Ich denke, ich stecke in die Kiste einfach mal eine SSD und probiere es aus. Geht ja dank VM/Proxmox sehr einfach!
SSDs sind - meinem Epfinden nach - halt besonders effektiv bei datenbanklastigen Applikationen. Und genau das habe ich ja!

SSDs wie gesagt nur bedingt nötig, ein RAID10 mit mehr Disks wird hier sicherlich mehr Performance bringen und von den Kosten vermutlich auch günstiger sein. Das hängt aber davon ab, ob du die Teile original bei HP bestellst oder dir andere Händler suchst. Bei alternativen Händerln kannst du nämlich deutlich Geld einsparen und damit den Server günstiger aufrüsten.

Hast du zufällig eine Empfehlung für einen alternativen, seriösen Händler? Ich mag nicht direkt bei HP kaufen.

Auf PVE würde ich nicht mehr verzichten, du nimmst dir damit meiner Meinung nach mehr Vorteile weg als du Nachteile hast.

ACK! Ich würde auch sehr ungern darauf verzichten wollen!

Beste Grüße

Thorsten

 

[tafkaz]

Hallo zusammen,

lese diesen Thread mit großem Interesse, denn wir haben gerade das selbe Problem, ebenfalls mit Medical Office.

Wir nutzen tatsächlich ein Raid1 an einem P840 Controler aus 2 x 1,9 TB SSD Enterprise Platten für die entsprechende VM und 256 GB RAM am Host (8GB sind der "Server" VM zugeteilt)
Ja...medical office ist nutzbar, aber eben nicht so schnell "wie früher", als es noch bare metal in der Praxis stand und alle darauf zugriffen.

Jetzt ist die Frage, ob Ihr noch irgendwelche Ideen habt, was man machen könnte?

Unser nächster Weg wäre jetzt, eine SSD direkt an die VM per PCI Passthrough durchzuschleifen und dort dann die Firebird SQL Daten abzulegen.
Dann ist wenigstens das Grundsystem weiter virtualisiert mit allen Vorteilen.
Die DB würde ich dann immer auf die virtualisierte Platte nachts sichern, so dass im Ernstfall alles vor Ort sein sollte.
Vielleicht kann mir ja schon jemand sagen, wie wir medical office beibringen, dass die DB dann an einem anderen Ort (zum Beispiel D:/DB/) liegt?

Remote Desktops wären ja eine Option, dazu müsste man dann aber komplett auf ein Windows Serversystem wechseln (momentan Windows 10 VM), jede Menge neue Lizenzen (User Cals, Office, etc.) kaufen, und auch noch einen echten Haufen Arbeitszeit investieren um alle Integrationen und Abläufe wieder hinzukriegen...möchte ich also ungern und ist wohl eher nicht gangbar.

Vielleicht hat hier noch jemand weitere Vorschläge?

Danke Euch vielmals
Sascha

 

[Ingo S]

Unser nächster Weg wäre jetzt, eine SSD direkt an die VM per PCI Passthrough durchzuschleifen und dort dann die Firebird SQL Daten abzulegen.
Dann ist wenigstens das Grundsystem weiter virtualisiert mit allen Vorteilen.
Die DB würde ich dann immer auf die virtualisierte Platte nachts sichern, so dass im Ernstfall alles vor Ort sein sollte.

Wenn wirklich die Virtualisierung die Ursache sein sollte (ich halte das aber als Argument für schlechte Performance für ziemlichen Bullsh...) dann könnte es an der Virtualisierung des IO Pfads liegen.
Wie ist denn der Speicherplatz zur Zeit in die VM eingebunden? Da gibt es in PVE ja verschiedene Optionen, wie z.B. Virtio, Virtio SCSI, IDE, SATA und versch. Emulationen von Controllern. Vielleicht kannst du mal verschiedene "Anbindungen" austesten und siehst evtl. performance Unterschiede.
Wir nutzen SCSI und über die Optionen ist das auf "Virtio SCSI" eingestellt. Das flutscht recht gut, lässt sich aber wegen unseres CEPH Storage nicht wirklich mit eurem Hardware RAID vergleichen.

Wenn du den Controller direkt per passthrough in die Maschine hängen willst, musst du schauen ob der Controller eine eigene IO_MMU Gruppe hat. Sollte der Controller in einem Slot stecken, der sich mit der Netzwerkkarte oder einem anderen für den Host wichtigen Gerät eine IO_MMU Gruppe teilt, wirst du damit wenig erfolg haben, da sich immer nur ganze IO_MMU gruppen per passthrough durchreichen lassen. Du siehst vll nur das von dir durchgereichte Gerät, aber die anderen Geräte der gleichen Gruppe stehen dem Host dann nicht mehr zur Verfügung, oder das Gerät lässt sich erst gar nicht durchreichen. Wie die Gruppen aufgeteilt sind hängt immer vom verwendeten Mainboard ab. Auf meinem privaten Server zu Hause z.B. ist der Raid Controller mit der Onboard Grafik in einer Gruppe und lässt sich dadurch partout nicht in die Maschine durchreichen, keine Chance.

 

[tafkaz]

Hi,

Danke für die schnelle Antwort.
Ja, ich halte das ja auch für groben Unfug, die Firma hinter Medical Office besteht aber darauf, dass das System unter Virtualisierung bis zu 50% langsamer läuft
Nun, so viel ist es bei uns sicher nicht, Gottseidank, aber es ist deutlich langsamer als wenn die DB auf Bare Metal läuft, keine Frage.
Wir sind uns glaube ich einig, das nicht die Virtualisierung Schuld trägt, sondern die schlampige und ressourcenverschwendende Programmierung der Software. Firebird SQL ist da wohl extrem IOPS hungrig, wenn man das nicht richtig macht.
Das Problem ist nur, dass wir so natürlich nicht weiter kommen, denn das Programm wird jetzt nicht mal eben jemand umschreiben, und natürlich ist die Software gesetzt.

Momentan sieht die Konfiguration der VM so aus:

agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0
cores: 4
cpu: Broadwell,flags=+aes
efidisk0: VM-Data-SSD:vm-1001-disk-2,size=4M
machine: pc-i440fx-5.2
memory: 32000
name: server-Windows
net0: virtio=2E:DE:EF:98:C9:2D,bridge=vmbr1,firewall=1
numa: 1
onboot: 1
ostype: win10
scsi0: VM-Data-SSD:vm-1001-disk-0,cache=unsafe,discard=on,iothread=1,size=500G,ssd=1
scsi1: none,media=cdrom
scsihw: virtio-scsi-single
smbios1: uuid=09967356-5612-4b1f-ba9a-133ea0b8e5d4
sockets: 1
tablet: 1
usb0: host=064f:2af9,usb3=1
vmgenid: d8397716-005a-4a07-893d-36eeec4795cc

Also SCSI an Virtio SCSI Single Controller.

Vielleicht habe ich am Raid Controller auch noch etwas falsch?

ssacli ctrl slot=3 show Smart Array P840 in Slot 3 Bus Interface: PCI Slot: 3 Serial Number: PDNNF0ARH7009F Cache Serial Number: PEYFP0BRH702N5 RAID 6 (ADG) Status: Enabled Controller Status: OK Hardware Revision: B Firmware Version: 7.00-0 Firmware Supports Online Firmware Activation: False Rebuild Priority: High Expand Priority: Medium Surface Scan Delay: 3 secs Surface Scan Mode: Idle Parallel Surface Scan Supported: Yes Current Parallel Surface Scan Count: 1 Max Parallel Surface Scan Count: 16 Queue Depth: Automatic Monitor and Performance Delay: 60 min Elevator Sort: Enabled Degraded Performance Optimization: Disabled Inconsistency Repair Policy: Disabled Wait for Cache Room: Disabled Surface Analysis Inconsistency Notification: Disabled Post Prompt Timeout: 15 secs Cache Board Present: True Cache Status: OK Cache Ratio: 80% Read / 20% Write Drive Write Cache: Disabled Total Cache Size: 4.0 Total Cache Memory Available: 3.2 No-Battery Write Cache: Enabled SSD Caching RAID5 WriteBack Enabled: True SSD Caching Version: 2 Cache Backup Power Source: Batteries Battery/Capacitor Count: 1 Battery/Capacitor Status: OK SATA NCQ Supported: True Spare Activation Mode: Activate on physical drive failure (default) Controller Temperature (C): 86 Cache Module Temperature (C): 56 Number of Ports: 2 Internal only Encryption: Not Set Express Local Encryption: False Driver Name: hpsa Driver Version: 3.4.20 Driver Supports SSD Smart Path: True PCI Address (Domain:Bus:Device.Function): 0000:08:00.0 Negotiated PCIe Data Rate: PCIe 3.0 x8 (7880 MB/s) Controller Mode: RAID Pending Controller Mode: RAID Port Max Phy Rate Limiting Supported: False Latency Scheduler Setting: Disabled Current Power Mode: MaxPerformance Survival Mode: Disabled Host Serial Number: MXQ54200XZ Sanitize Erase Supported: True Primary Boot Volume: None Secondary Boot Volume: None



das entsprechende logical device sieht so aus:

ssacli ctrl slot=3 ld 3 show

Smart Array P840 in Slot 3

   Array B

      Logical Drive: 3
         Size: 1.75 TB
         Fault Tolerance: 1
         Heads: 255
         Sectors Per Track: 32
         Cylinders: 65535
         Strip Size: 256 KB
         Full Stripe Size: 256 KB
         Status: OK
         Unrecoverable Media Errors: None
         MultiDomain Status: OK
         Caching:  Enabled
         Unique Identifier: 600508B1001C76698822EF684F3FA67F
         Disk Name: /dev/sdb
         Mount Points: None
         Logical Drive Label: 0960ED1BPDNNF0ARH7009F4E48
         Mirror Group 1:
            physicaldrive 1I:1:5 (port 1I:box 1:bay 5, SAS SSD, 1.9 TB, OK)
         Mirror Group 2:
            physicaldrive 1I:1:8 (port 1I:box 1:bay 8, SAS SSD, 1.9 TB, OK)
         Drive Type: Data
         LD Acceleration Method: Controller Cache

Wie gesagt, jede Hilfe ist willkommen, ich kann auch weitere Info geben, sagt einfach, was Ihr benötigt.

Danke
Sascha

 

[sb-jw]

Meine Empfehlung, cache auf Write Back und iothread und ssd flag aus der Disk entfernen. VM Stoppen und wieder starten, damit die Änderungen aktiv werden - erneut probieren und schauen, ob die Performance besser ist. Davor vielleicht mit einem der üblichen Tools nen kleinen Bench machen um vorher und nachher Vergleiche zu zu können.

CPU könnte man vielleicht auch noch auf Host stellen. Ballon noch aktivieren und alle Virt IO Treiber installieren.

Btw 32GB = 32768 und nicht 32000

 

[tafkaz]

Meine Empfehlung, cache auf Write Back und iothread und ssd flag aus der Disk entfernen. VM Stoppen und wieder starten, damit die Änderungen aktiv werden - erneut probieren und schauen, ob die Performance besser ist. Davor vielleicht mit einem der üblichen Tools nen kleinen Bench machen um vorher und nachher Vergleiche zu zu können.

CPU könnte man vielleicht auch noch auf Host stellen. Ballon noch aktivieren und alle Virt IO Treiber installieren.

Btw 32GB = 32768 und nicht 32000

Hi,

ok versuch ich:

- cache auf Write Back und iothread und ssd flag aus der Disk entfernen - bezieht sich alles auf die VM Einstellungen, richtig?
Und Write back ohne (unsafe) dann, cache=unsafe ist ja write back (unsafe)?

- CPU stell ich auf Host. Ballon aktiviere ich, aber alle Virt IO Treiber sollten bereits installiert sein.

- und 32768...naja...dit is ja ma eher n kosmetisches Problem, oder nicht?
Stell ich aber selbstverständlich auch um.

Am RAID alles töfte, oder da auch noch Ideen?

lg
Sascha

 

[tafkaz]

Hier ist mal ein Benchmark auf der VM ohne die Änderungen.
Finde ich ehrlich gesagt schon ziemlich ordentlich...



Aber wahrscheinlich sind die letzten Werte für Firebird SQL dann doch nicht hoch genug?

lg
Sascha

 

[Ingo S]

Ich bin jetzt nicht sicher, aber teilt das SSD flag nicht dem OS mit, dass es sich bei der Disk um eine SSD handelt und das OS deshalb den Trim Befehl an die virtuelle Disk durchgeben soll?
Ohne SSD flag schrumpfen bei uns jedenfalls die Images der Maschinen nicht, wenn wir Daten auf den Maschinen löschen.

 

[tafkaz]

ja, das kommt bei mir auch wieder rein, die Anpassungen haben nämlich leider alle nicht geholfen.
Ich weiß es ja auch nicht, aber das caching auf dem RAID Adapter bzw. für die LD ist ok, meint Ihr?

lg
Sascha

 

[sb-jw]

Die Disk Images können nur dann schrumpfen, wenn der Storage auch Thin Provisioning kann. Dazu muss die virtuelle Festplatte als VirtIO erstellt sein und der Discard Parameter aktiviert sein. Das SSD Flag ist dafür jedoch nicht nötig. Manche Betriebssystem mögen das eventuell benötigen, ist mir aber bei aktuellen Betriebssystemen nicht bekannt. Möglicherweise ist das bei einem Desktop OS, was aber eher weniger eine Rolle spielt, da man ein Desktop Windows in der Regel nicht als Server Betriebssystem nutzen darf (gemäß EULA).

Thin Provisioning / Discard ist grundsätzlich ein gutes Feature um Speicherplatz zu sparen. Geht aber auch immer zu Lasten der Performance, denn die Blöcke müssen ja immer wieder angefordert werden, wenn die nicht mehr zugewiesen sind. Die hier genannten Use Cases sind aus meiner Sicht aber weniger relevant für solche Features, hier laufen ja keine hunderte VMs auf einem großen SSD CEPH Storage über mehrere Nodes. Insofern kann die wissentliche nicht Nutzung auch zur Verbesserung der Performance beitragen, wenn z. B. die virtuelle Festplatte auf dem Storage auch zusammenhängend ist.

Der Benchmark mag zwar ordentlich sein, aber im Detail betrachtet ist diese Leistung nicht unbedingt realistisch, vermutlich wird der Controller Cache hier den größten Einfluss haben.
Die letzten Werte sind Random 4k IOPS, damit hat so ziemlich jeder Speicher seine Probleme, das wird aber Bare Metal auch nicht um so vieles besser sein. Meine persönliche Präferenz ist HDTune, da gibt es etwas ausführlichere Metriken, welche auch auf die IOPS gehen. Schreib und Lesedurchsatz in MB ist nicht alles, maßgeblich sind eher die IOPS als die Bandbreite.

"unsafe" ist zwar auch eine Art "Write Back", aber ich meine tatsächlich "Write Back"

Sofern nicht mehrere Sockets genutzt werden, kann man NUMA auch deaktivieren. Bringt möglicherweise zusätzliche Performance.

Also ich persönlich empfehle ein RAID 1 maximal noch für das Betriebssystem. Als Storage darunter dann eher mal ZFS oder besser ein CEPH.

Konkret wäre meine Empfehlung daher, erst mal HDTune Pro installieren (15 Tage for free) einen ausführlichen Benchmark machen um Bandbreite, IOPS und auch Latenzen zu messen (Screenshots zum Vergleichen nicht vergessen). Dann meine empfehlungen noch mal einstellen (balloon aktivieren, disk auf VirtIO stellen mit Discard aktiviert und cache auf Write Back, numa deaktivieren und CPU auf Host stellen). Dann VM Stoppen, wieder starten und erneut einen Benchmark machen um zu sehen ob tatsächlich alle Werte schlechter oder gleich geblieben sind.

Was mir noch ein wenig fehlt sind die Hardware Details, eventuell lässt sich hier ja noch was optimieren. Perse kann der Performance Mode schon was bringen. Energie sparen ist immer schön und gut, geht aber zu Lasten der Performance.

Eines meiner Probleme ist noch, dass ich die Software nicht kenne und nicht habe und ich es daher auch nicht mal eben bei mir testen oder debuggen könnte.

 

[tafkaz]

Hi,

ok...teste ich.
Hier schon mal der Test vor den Änderungen:



Vielleicht könnt Ihr dazu etwas sagen.

Ich nehme die Änderungen nun vor und schicke dann den neuen Test.
Danke
Sascha

 

[tafkaz]

ok...
Einstellungen sehen jetzt so aus:

agent: 1
balloon: 16000
bios: ovmf
boot: order=scsi0
cores: 4
cpu: host
efidisk0: VM-Data-SSD:vm-1001-disk-1,size=4M
machine: pc-i440fx-5.2
memory: 32768
name: server-Windows
net0: virtio=2E:DE:EF:98:C9:2D,bridge=vmbr1,firewall=1
numa: 0
onboot: 1
ostype: win10
parent: vor_aenderungen
scsi0: VM-Data-SSD:vm-1001-disk-0,discard=on,size=500G
scsi1: none,media=cdrom
scsihw: virtio-scsi-single
smbios1: uuid=09967356-5612-4b1f-ba9a-133ea0b8e5d4
sockets: 1
tablet: 1
unused0: VM-Data-SSD:vm-1001-disk-2
unused1: VM-Data-SSD:vm-1001-disk-3
usb0: host=064f:2af9,usb3=1
vmgenid: d8397716-005a-4a07-893d-36eeec4795cc

Die V-Disk auf Virtio Block stellen ging leider nicht, da dann das Windows nicht mehr bootet (ja ich habe vorher eine zweite Platte als virtio angelegt und in Windows nutzen können...Treiber sind also prinzipiell da, schätze eher, dass es am UEFI liegt)
Ich habe das also jetzt erstmal auf SCSI gelassen, oder ist das wirklich der Knackpunkt?

Benchmarks:




Also eher schlechter...
Oder interpretiere ich etwas falsch?
Danke
Sascha

 

[Dunuin]

Du solltest wirklich mal virtio SCSI testen. Ein Win kann nicht von virtio booten, wenn es nicht auf virtio installiert wurde. Das kann man aber mit ein paar Tricks umgehen. Musst du mal hier im Forum nach googlen wie das andere gemacht haben.