Performance

[sb-jw]

Bei Balloon reicht es den Haken zu setzen, da muss kein anderer Wert rein. Der Haken bewirkt im zusammenspiel mit den korrekten Treibern, dass Proxmox die aktuelle RAM Belegung auslesen kann (ohne ist immer mehr RAM in PVE belegt als Windows hat).

In der Tat ein kleines Kommunikationsproblem, mit VirtIO ist nicht gemeint, dass die Disk als VirtIO rein soll (SCSI ist hier absolut korrekt) sondern der Controller Type soll auf VirtIO. Bei der Kommunikation mit meinen Kollegen ist klar, was man meint. Falsche Erwartung von mir, entschuldige

Das Ergebnis wundert mich doch sehr und wirkt auf mich erst mal unerklärlich. Vermutlich wird hier "write back" in Kombination mit dem RAID Controller nicht gut laufen. Hast du mal die verschiedenen Modi durch probiert, was hier besser läuft?

Aber ja, du hast das schon korrekt interpretiert, die Leistung ist deutlich unter der vorherigen.

 

[tafkaz]

ja langsam...nicht, dass wir uns hier falsch verstehen.
Der SCSI Controller steht auf "virtio SCSI single"
Die Harddisk dann auf SCSI.
Was nicht geklappt hat, ist das Umstellen der Harddisk auf Virtio Block.

Nach meinen Informationen ist doch die Kombination virtio SCSI / SCSI HD die empfohlene, oder nicht?

lg
Sascha

 

[Dunuin]

Nach meinen Informationen ist doch die Kombination virtio SCSI / SCSI HD die empfohlene, oder nicht?

Ja. Virtio block fehlen in der PVE Implementation features wie discard. Da muss die HDD dann schon auf SCSI laufen. Ich würde da auch virtio SCSI + SCSI nehmen.

 

[tafkaz]

...und SSD Emulation sollte ich aus performance Gründen lieber weglassen?
Die Festplatte sollte ich also in etwa so anlegen?

 

[Dunuin]

Was du auch noch versuchen könntest wäre virtio SCSI mit 4K statt 512B laufen zu lassen. Meistens sind die physischen Laufwerke ja 4K LBA, das Dateisystem vom Gast-OS hat meist 4K Blockgröße, aber bei PVE arbeitet virtio immer mit 512B LBA, sofern du das nicht manuell über Argumente in der VM-Konfig-Datei überschreibst.

Das ist ja glaube ich per default schon etwas ungünstig:
4K (phy disk) <- XX K (variabel je nach Blocksize des raid; wäre bei ZFS z.B. per default 8K) <- 512B (virtio SCSI) <- 4K (Gast-FS)

 

[tafkaz]

Also gut, hier die ersten Ergebnisse:

mit "writethrough":


mit "direct sync":




mit "writeback":



und mit "no cache":



Den Ausreisser mit "writethrough" verifiziere ich noch mal, aber so richtig riesig sind die Unterschiede jetzt nicht, oder?

lg
Sascha

 

[tafkaz]

Was du auch noch versuchen könntest wäre virtio SCSI mit 4K statt 512B laufen zu lassen. Meistens sind die physischen Laufwerke ja 4K LBA, das Dateisystem vom Gast-OS hat meist 4K Blockgröße, aber bei PVE arbeitet virtio immer mit 512B, sofern du das nicht manuell über Argumente in der VM-Konfig-Datei überschreibst.

Ja klar, probier ich aus, wie stell ich das ein und wo?

Einfach ans Ende der Harddisk Zeile ,block_size_4k=1 hängen, also:

scsi0: VM-Data-SSD:vm-1001-disk-0,cache=writethrough,discard=on,size=500G,block_size_4k=1

?


Danke
Sascha

 

[Dunuin]

Die Zeile args: -global scsi-hd.physical_block_size=4k in die Config-Datei der VM (/etc/pve/qemu-server/<VMID>.conf) schreiben.

Guck aber besser das du vorher ein backup machst, da die HDD dann ja mit 512B LBA formatiert wurde danach als 4K LBA HDD benutzt wird.

 

[tafkaz]

Danke, probiere ich sofort!

 

[tafkaz]

Scheint vordergründig (via benchmark) nicht den erhofften Effekt gehabt zu haben, aber vielleicht morgen im laufenden Betrieb.
Evtl. sind die Zugriffe auf die Firebird DB doch schneller jetzt.

Danke Euch, ich melde mich morgen wieder.
lg
Sascha

 

[tafkaz]

Guten Morgen, zusammen.
Nein, das Programm ist weiterhin recht langsam.
So langsam schwindet bei mir die Hoffnung, dass ich dieses Mistding ohne eine Bare Metal Installation wie erwartet zum Laufen bekomme.

Ich hatte ja ursprünglich vor, die Firebird DB direkt auf eine durchgeschliffene SSD (PCI Passthrough) auszulagern, aber das geht auch nicht so mal eben...
"Es müsste an allen Rechnern, nicht nur am Server, dann in Registry und lokalen Dateien der neue Pfad zur Datenbank angegeben werden,
des weiteren müssen mobile Geräte vermutlich neu installiert werden da ja ein Abgleich statt findet…."

Ich verstehe nicht, warum in 2021 so etwas überhaupt noch im Umlauf ist...

Eine Option wäre vielleicht den P840 auf HBA zu stellen und dann ein ZFS zu bauen, wenn das überhaupt geht.
Dann müsste ich zwar den Proxmox neu installieren (und aus Sicherungen wieder herstellen) und die VMs einmal sauber aus den Backups restoren, aber wenn das den nötigen Performanceschub bringt, meinetwegen.

Auf jeden Fall werde ich heute, wenn die Praxis geschlossen hat, mal die neueste HP Firmware aufspielen, da gibt es wohl seit ein paar Wochen was neues...

Was denkt Ihr?
lg
Sascha

 

[tafkaz]

Also, neue Firmware ist drauf, ZFS habe ich mir erstmal gespart.
Ich glaube, dass es nicht viel besser werden wird.
Ich denke, wir werden darauf hinwirken, dass man über einen Programmwechsel nachdenkt...

Ich habe noch eine Frage, vielleicht habt Ihr dazu auch eine Idee:
Wir haben zusätzlich noch virtuelle Windows 10 Arbeitsplätze erstellt (welche dann per RDC bzw xfreerdp genutzt werden).
Diese laufen prima, allerdings ist das scrollen mit der Maus (auch wieder nur in medicaloffice) unter RDC und auch unter SPICE sehr laggy.
Es sieht so aus, als ob in medical office für das Darstellen der Grafik und damit auch beim Scrollen, die 3D Funktionen der VGA genutzt werden, daher haben wir das Problem an physikalischen Arbeitsplätzen nicht.
Seht Ihr irgendeine Möglichkeit, wie man dieses Verhalten verbessern könnte?

Danke
Sascha

 

[Ingo S]

Ich hab das jetzt nicht mehr ganz im Überblick, aber konntest du testen, ob das direkte Passthrough eines Gerätes (z.B. Raid Controller oder HBA) etwas ändert?
So richtig näher gekommen sind wir der Ursache für die schlechte Performance ja noch nicht. Zeigen sich denn beim Betrieb der Software auf dem Server ungewöhnlich hohe IOWAIT Werte? Interessant wäre auch, ob man irgendwie messen kann, wie viele IO/s da im Betrieb wirklich anfallen und ob sich das zwischen Baremetal und VM unterscheidet.
Möglich wäre außerdem auch eine andere Ursache, z.B. das die Software mit irgendwelchen Dingen abseits des Storage nicht gut umgehen kann. Vielleicht liegts an der Architektur (i440fx | q35) oder an besonderen CPU funktionen, die die Software direkt verwenden möchte, die aber in der Virtualisierung nur emuliert werden o.ä.

 

[birdy]

Hatte voor einige Jahren auch mal so ein Problem mit eine Firebird basierte Anwendung. Performance war nicht gut und die Firma, die die Anwendung geliefert hat, behauptete es lag am storage (DELL Equallogic mit 48 HDD) unsere VMware Umgebung, weil auf Baremetal bei Ihnen war alles superschnell. Aber weil die andere Anwendungen (ua Exchange, MS SQL, Sharepoint, Progress Openedge) gut liefen waren wir nicht dieser Meinung und dachten es lag an Firebird (aus welchen Grund dann auch). Verschiedene Sachen ausprobiert (sogar ein Flashstorage ausgeliehen zum vergleichen) aber haben das nie so richtig hinbekommen. Glücklichetweisse hat die Firma dann umgestellt auf MS SQL. Dann lief alles wie geschmiert.

 

[tafkaz]

Hi, danke Euch für die Antworten.

@Ingo S
tja...PCI Passthrough war eine Idee, aber

Ich hatte ja ursprünglich vor, die Firebird DB direkt auf eine durchgeschliffene SSD (PCI Passthrough) auszulagern, aber das geht auch nicht so mal eben...
"Es müsste an allen Rechnern, nicht nur am Server, dann in Registry und lokalen Dateien der neue Pfad zur Datenbank angegeben werden,
des weiteren müssen mobile Geräte vermutlich neu installiert werden da ja ein Abgleich statt findet…."

Ich verstehe nicht, warum in 2021 so etwas überhaupt noch im Umlauf ist...

Das werden wir mal lieber lassen...medical office ist ein Alptraum in meinen Augen. :-(

Wenn ich im Netz ein wenig wühle wird eigentlich klar, dass firebird SQL tatsächlich unfassbar viele IOPS verwendet, so dass die Systeme virtualisiert einfach deutlich langsamer laufen.

https://www.ibexpert.net/ibe/pmwiki.php?n=Doc.FirebirdPerformanceRecommendations

mportant

A Firebird database server should be a dedicated server and should only be responsible for the Firebird database service in order to ensure maximum performance. Virtual servers lose between 20% and 80 % of their speed under a high load on a VM. Any advantage of a VM-based Firebird Server will be paid for dearly by all employees waiting additional time to carry out and complete their jobs.

Insofern @birdy sind Deine Erfahrungen plausibel für mich.
Ob ich jetzt warten kann, bis medical office auf eine vernünftige Struktur aufsetzt, sei mal dahin gestellt.
Kennt einer denn eine Praxisverwaltungssoftware, die man empfehlen kann, weil Sie weigstens halbwegs in diesem Jahrtausend angekommen ist?

Achso, und wenn mir jemand noch einen Tipp geben kann zur Mausscrollgeschwindigkeit unter RDC / Spice, dann immer her damit

Danke
Sascha

 

[Ingo S]

Hmm also ich dachte bei Passthrough eher daran, das gesamte System so wie es ist, auf eine via Passthrough eingehängte Platte umzuziehen. Dann bleiben alle Pfade gleich also z.B. C:\Programme\Medical Office\FirebirdDB\ oder so ähnlich. Theoretisch müsste das gehen.
Da hängst du einen Controller via Passthrough in die VM, installierst alle Treiber. Anschließend machst du ein Backup, z.B. mit Clonezilla o.ä. direkt aus der Maschine heraus. Dann erstellst eine neue Maschine und hängst als einzige Platte den Controller via Passthrough ein. Dann stellst du das Backup in der neuen Maschine wieder her. Da die Treiber für den Controller installiert sind, sollte die Maschine theoretisch booten. In 9 von 10 Fällen klappt das.

Wir haben ein ähnliches Problem mit Theorg so gelöst, dass wir die Anwendung auf einem Terminal Server laufen lassen und den Benutzern (3 Leute) die Anwendung als einzelnes Fenster via RDP auf den Arbeitsplatz einblenden. Damit läuft die Anwendung auf dem selben Server wie die Firebird DB. Seitdem ist das Problem mit der Performance wie weg gepustet.

Wegen der Bildrate beim Scrolling: Da kann ich leider nicht wirklich weiterhelfen. Das scheint an der Art und Weise zu liegen, wie die Anwendung ihre Inhalte auf den Bildschirm rendert. Vll wird da eine DirectDraw Pipeline genutzt o.ä.
Wie man das aber mit RDP/Spice flott übertragen bekommt, das weiß ich leider nicht. Ich kenne nur die virtio-win-guest-tools. Die befinden sich auf der iso Datei die hier beschrieben wird: https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers
Aber da du schon scsi-virtio nutzt vermute ich, das du das schon installiert hast.

BTW: Noch ein kleiner Tip. Wir installieren Anwendungen auf Servern immer auf einem vom OS abgetrennten separaten Laufwerk z.B. D:\. So kann man besser sichern, UND man kann ohne Probleme die darunterliegende virtualisierte Hardware auch mal austauschen, ohne das sich Pfade ändern. Das hat uns schon oft viel Arbeit erspart.
Softwarehersteller und deren Dienstleister die Anwendungen bei uns unter C:\ installieren wollen, bekommen von mir immer sofort eins auf die Finger.

 

[tafkaz]

Das mit dem kompletten System auf PCI Passthrough device war mir nicht klar, klingt aber cool.
Ich dachte, dass man nur zusätzliche Geräte so einklemmen kann, aber ja, das könnte man in der Tat einmal probieren.
Danke für die sehr gute Idee.
Kann ich dann denn die Daten von der VM noch mit PBS backuppen, eher nicht, oder?

Ja die Bildrate beim Scrollen ist ein weiteres beklopptes Problem mit der Software jetzt.
virtio-guest-tools waren tatsächlich noch nicht installiert, brachten aber leider auch keine Besserung.
Oder kann man damit noch irgendwo was einstellen bezüglich der Grafik?

Und zu Deinem Tipp:
Absolut richtig, machen wir genau so...hier haben wir aber etwas bereits installiertes übernommen und dann 1:1 auf VM migriert.
Machts aber auch nicht besser...

 

[tafkaz]

So Leute, das System läuft jetzt deutlich besser, nachdem ein externer Dienstleister einige Optimierungen am PVE Host vorgenommen hat.
Zum Teil Dinge, auf die ich wirklich nie gekommen wäre.

Edit:

Ich weiß leider auch nicht genau was der Dienstleister am System gemacht hat, aber ich könnte mir vorstellen, dass am Ende vielleicht schon die allerneuesten gerade erst veröffentlichten Virtio Treiber (0.1.96) einen entscheidenden Beitrag geleistet haben könnten.

lg
Sascha

 

[birdy]

Euh... ja und jetzt? Versteh ich das jetzt richtig? Du hast Probleme, meldest dich hier im Forum, wir diskutieren, du kriegst tips von uns und wenn du dann die "Lösung" hast lässt du uns im Regen stehen? Schade.

 

[tafkaz]

ehm...nein...

Wenn das, was wir gemeinsam diskutiert haben, oder etwas, das mir selber eingefallen ist, geholfen hätte, hätte ich den Lösungsansatz selbstverständlich allen mitgeteilt.

Das war hier aber definitiv nicht der Fall.
Stattdessen habe ich einen Dienstleister beauftragt, sich die Sache anzusehen und er konnte mein Problem lösen.
Ich glaube nicht, dass jemand jetzt ernsthaft von mir erwartet, dass ich die Herangehensweise des Dienstleisters hier poste und ihm somit ein Teil seiner Geschäftsgrundlage entziehe, das wäre ja nun mal alles andere als fair, oder? Mal ganz abgesehen davon, dass ich es auch gar nicht könnte, denn das was dort gemacht wurde, hab ich mir jetzt auch nicht detailliert aufgeschrieben.
Da hat einfach eine Firma extrem viel Know-how aufgebaut.

Und damit eben keiner, der das hier liest, im Regen stehen gelassen wird und weiß, das es da jemanden gibt, der ihm vielleicht helfen kann, und auch weil ich mich unbedingt bei den Kollegen bedanken wollte, habe ich den Kontakt hier geteilt.

Passt für alle?

Und natürlich auch Euch nochmal ganz lieben Dank für Eure Ideen und Ansätze, so etwas ist auf jeden Fall fantastisch.

in diesem Sinne
Danke und Liebe Grüße
Sascha