Performance Probleme

[bursch]

Hallo Leute

Ich habe ein spezielles Phänomen. Wir haben einen unserer alten physikalischen Server auf die ESXi Umgebung konvertiert. Es handelte sich dabei um einen alten HP Proliant DL380 G5 W2K8-R2 mit einer Pervasive SQL Datenbank.

Kaum virtualisiert, stellten wir fest, dass der virtuelle Server, obwohl dieser neu auf einer viel schnelleren Plattform G7/G8 betrieben wird, rund 1/3 der Performance verliert. Ein solches Verhalten, konnten wir bisher nie feststellen, wir konnten zumindest die Performance halten.

Wir haben extrem viel getestet (SAN v. lokale SAS-Disk, verschiedene Raid-Levels, Raid-Cache, Sockets/Kerne/ RAM, verschiedene Servermodell, verschieden ESX Versinen usw.) das Resultat bleibt immer das Gleiche. Beim physikalischen Betrieb ist der Server rund 1/3 schneller als im virtuellen Betrieb.

Als Test lesen wir eine Tabelle mit ca. 80'000 Datensätze aus und exportieren diese als DBF File auf den gleichen Disk wie die Tabelle.

Hat jemand eine Idee? Danke für Euer Feedback.

Vielen Dank
Bursch

[pirx]

Habt ihr eine P2V durchgeführt oder alles sauber neu installiert? Wird eine der üblichen Ressourcen CPU/MEM/Disk als Engpass erkannt? Wie sehen die Performance Graphen in der Zeit aus? Was sagt Windows Task Manager während der Zeit in der die DB ihren Export durchführt?

[PeterDA]

Hi,
ein paar mehr Infos wären echt Hilfreich, sonst können wir hier eigentlich nur ein Layer-8 Problem diagnostizieren.

Folgende Infos wären Hilfreich:
- Anzahl vCPUs
- Summer vRAM
- Hostausstattung (CPU & RAM & Storage (RAID Level & Spindeln)
- wenn P2V sind die HP Treiber sauber deinstalliert worden?
- Sind VMware Tools installiert

So das wär es dann fürs erste.

Gruß Peter

[Dayworker]

Das die komplette HW-Virtualisierung ala VMware, mit ihren in SW abgebildeten Plattencontrollern und somit in Abhängigkeit zur Host-/Gastauslastung stehenden Schreibperformance, keine festen Durchsatzraten erlaubt, sollte dir immer bewußt sein. Daran ändern auch optimierte Treiber recht wenig, zumal sich bei fehlender Schreibperformance inzwischen auch immer häufiger die Frage nach dem korrekten Alignment von DS und VMDK stellt.
Speziell bei Datenbanken können sich unaligned Schreib-IOs vernichtend auf die Gesamtperformance auswirken.

[bursch]

Hallo Leute

Danke für die Antworten. Sorry für die späte Antwort - bin viel unterwegs.

Physikalisch Hardware vor der Virtualisierung
> HP ProLiant ML350R x2.33/1333 G5 / QC
> 2 Prozessoren
> 13 12 GB RAM
> SmartArray 400 / 256 KB RW Cache
> 2 x Raid-1 / SAS 72GB/146GB, 16K^
> DB ist auf dem zweiten Raid-1
> Windows 2008/R2 Std.

ESXi Host (3 Stück)
> HP ProLiant DL380p 2.3/2630 G8 6C
> 2 Prozessoren
> 64 GB RAM
> SmartArray xx 2 GB RW-Cache
> 1 RAID-1 / SAS 300 GB 10K, 6GB DP
> 2 x HP Controller SAS H221

> HP P2000 G3 2.5" Base Model
> HP P2000 SAS Controller G3
> Raid-5 mit 15 HP Harddisk 146GB SAS DP HPL, 2.5, Hot Plug, 2.5", 15K, 6GB/s
> Raid-5 mit HP Harddisk 600GB SAS HPL, 2.5", Hot Plug 2.5", 10K, 6GB/s (Clones usw.)

Wichtig?
Wir haben den physikalischen Server mit dem "standalone Konverter" migriert. Haben aber auch das Ganze mal neu installiert, mit dem gleichen Resultat.

Wir haben bei der VM mit unterschiedlichen Anzahl von Sockets und Cores getetstet, von 1 Socket mit 1 Core / 4 Socket mit je einem Core / 8 Socket mit 4 Cores usw.. - immer das gleiche Resultat
Wir haben verschieden Disktreiber ausprobiert ohne Erfolg
Wir haben das Ganze von der SAN auf die lokalen Disk des ESXi Servers migriert - ohne Erfolg.

- DB-Testzeit physikalisch: 23 Min.
- DB-Testzeit auf VM: 36 Min.
- DB-Testzeit physikalisch - ESXi Host missbraucht: 20 Min.

Danke und Gruss

Bursch

[Dayworker]

Also du hattest physikalisch 2x Raid1 mit 15kU/min und einer Trennung der DB auf dem zweiten Raid1. Deine ESXi dagegen haben nur ein Raid1 und die Platten laufen ausserdem nur mit 10kU/min. Inwieweit deine HP P2000 da mitspielt, kann ich nicht recht nachvollziehen.
Falls du jedoch sehr viele oder hauptsächlich Schreibzugriffe in der DB tätigst und dabei das Raid5 zum Einsatz kommt, sollten dir die Schreibperformanceverluste eines jeden Raid5 nicht unbekannt sein.

Das du keinen grossen Unterschied zwischen lokalem DAS mit einem die Performance höchstens in Leserichtung verbessernden Raid1 und einem Raid5 mit seiner Schreibschwäche, überrascht mich nicht wirklich. Dazu sind auch noch zu viele Fragen offen. Interessant dabei wäre, mit welcher Datensatzgrösse operiert wird oder mit welcher Stripesize das Raid5 eingerichtet wurde. Gerade letzteres könnte neben dem Alignment ein Hauptgrund für weitere Verluste sein. Denn wenn die Stripesize unpassend ist, werden Anfragen letztendlich nur von einer einzigen Platte bedient und die anderen in deinem Fall 14 Platten drehen einfach nur Däumchen.

Du solltest auch genau überprüfen, welchen CPU-Bedarf die DB wirklich hat. Die bisherige Maxime in der Computerbranche "viel hilft viel" ist bei Virtualisierung absolut kontraproduktiv und verlangsamt in den meisten Fällen sogar noch deren Ausführung. DBs profitieren am Meisten von viel RAM.

Könnte es sein, daß du bei der Virtualisierung auch vom falschen Standpunkt "Virtualisierung macht alles schneller" ausgegangen bist?
Dem ist nämlich leider nicht so. Bei Virtualisierung geht es ausschließlich um Konsolidierung bestehender Server unter höherer Auslastung der verbleibenden Server und um die Schaffung ein HW-Unabhängigkeit von sich ständig veraltender Rechner-HW. Für die Performance einer VM ist es daher kein Fehler, diese nur mit einem Singlecore auszustatten und sich dann ggf auf einen zweiten Kern vorzutasten. Mehrkern-VMs bekommen bekanntlich nur dann Rechenzeit zugeteilt, wenn die benötigte Kernanzahl auf dem Host auch frei ist oder sie bei Round-Robin durch unfreie Kerne und somit keine Ausführung entsprechende Pluspunkte angesammelt haben, die die VM dann auch mal zur Ausführung berechtigen.