SQLExpress in Hyper-V

Hallo,

das liegt einzig und allein an der Express Variante des SQL.der ist so beschnitten worden das er nicht mehr kann. Egal ob virtuelle oder nicht.

Übrigens kann er auch nur 1Gb Arbeitsspeicher und max 10Gb Datenbank

Der SQL Express läuft maximal auf einem Kern, der Host bzw. die VM können aber dennoch mehr Kerne haben. Wenn du also deiner VM 2 Kerne spendierst und der SQL Express darauf läuft nutzt die DB einen und das OS oder was sonst noch auf der VM läuft kann den anderen oder auch beide nutzen, je nach Last.

Auf einem Hyper-V installiert man sicherlich keine Software lokal, auch bzw. erst recht keine DB. Deine Wahl ist also ein Windows direkt auf dem Blech mit SQL Express oder ein Hyper-V mit einer VM in der SQL Express läuft + ggf. weitere VMs. Da SQL Express die bereits genannten Limitierungen hat wäre es i.d.R. Schwachsinn einen ganzen Hardware Server nur für SQL Express auf zu setzen, die Frage stellt sich also gar nicht.

Hallo,

da muß ich korrigieren: die Aussage von CyborgWeasel stimmt, es kann maximal ein Prozessor oder bis zu vier Kerne sein.

Aber Hyper-V sollte das durchaus beherrschen.

Gruß, Mad Max

Heißt das Hyper-V prüft was in der (ausgeschalteten) VM für eine Software läuft während man die Sockets / Cores einstellt? Kann ich mir kaum vorstellen. Ich nutze nur VMware aber wäre das nicht sehr aufwendig und fehleranfällig?

N'Abend.
Nein. Auf einem HyperV-Host betreibt man gar nichts. Außer der HyperV-Rolle. Ok, Backup-Agent. That's it.
Von der Fragestellung her sehr interessant - aber ehrlich gesagt: Wenn ich SQLEXPRESS nutzen kann/will/muss, da stellt sich die Performancefrage doch erst gar nicht.

Um deine eigentliche Frage zu beantworten: Ich teste es morgen einfach mal, wir haben auch solche Konstrukte am Laufen.

Cheers,
jsysde

Entschuldigung, da habe ich mich mißverständlich ausgedrückt. Das mit dem einen Prozessor oder vier Kernen hat sich auf SQL Server Express bezogen.

Es ist also so, daß SQL Server Express maximal einen Prozessor oder bis zu vier Kerne unterstützt ("Limited to lesser of 1 socket or 4 cores").

Und Hyper-V unterstützt auf jeden Fall mehrere Prozessoren. Zum einen hat das @MysticFoxDE oben mit dem Screenshot gezeigt und zum anderen haben wir ein paar Kunden, die Hyper-V einsetzen und SQL Server Standard oder auch Enterprise mit mehr als einem Prozessor in der VM.

Was aber durchaus sein könnte, wohlgemerkt nur hypothetisch, mit Hyper-V kenne ich mich zu wenig aus, wenn Hyper-V tatsächlich mit "Prozessoren" Prozessoren mit je einem Kern meint, dann würde SQL Server Express nur einen dieser Prozessoren mit einem Kern nutzen. Vier Kerne kann er nur nutzen, wenn sie in einem Prozessor stecken. Aber wenn ich mir folgendes Bildchen anschaue, dann denke ich, das wäre auch unter Hyper-V einstellbar (Virtuelle CPUs für Windows Server Hyper-V konfigurieren):

Wobei ich wohl ein bisschen präziser mit den Begriffen sein sollte. Was bei SQL Server "Core" heißt, ist bei Hyper-V der Prozessor und Socket ist in beiden Fällen gleich. Wenn also in Hyper-V ein Socket mit vier Prozessoren eingestellt wird, müßte bei SQL Server Express dieser eine Socket mit den vier Cores genutzt werden können.

Gruß, Mad Max

So hätte ich das auch vermutet. SQL Express prüft die bereit gestellten Ressourcen der VM oder auch die der Hardware. Wenn 2 Sockets erkannt werden wird das DBMS nur einen nutzen, der andere kann aber durch das OS oder andere Anwendungen sinnvoll genutzt werden.

Wenn man natürlich pro Socket 4 Kerne hat (um dem SQL Express sein Maximum zu gewähren), dann wären 4 weitere Kerne nur für ein OS etwas viel. Dann kann man natürlich auch auf z.B. 1 Socket mit 6 Kernen gehen, je nach Auslastung.

Moin ukulele-7,


Ein SQL-Server sollte aus Performancegründen am Besten nicht über mehrere Sockets und oder NUMA's laufen,
da werden die Dinger eher zäh. Gilt aber nicht nur für MS, sondern auch für so gut wie jeder andere Datenbank-Plattform.

Gruss Alex

Deine zentrale Annahme wird sein das eine VM mit 2 vSocket (ich nehme bewusst vSocket nicht vCPU um das klarer abzugrenzen) auf 2 pSockets laufen würde, wohingegen eine VM mit 1 vSocket nur auf einer pCPU läuft. Ich bin mir ziemlich sicher das diese Annahme falsch ist.

Meiner Meinung nach teilt der Scheduler die vSockets und vCores auf die pSockets und pCores auf wie er es für richtig hält, so das es aus Performance-Sicht fast egal ist. Der Scheduler wird alle vCPUs bevorzugt auf einer pCPU laufen lassen, egal ob Socket oder Core, denn er weiß das das performanter ist. Erst wenn die Anzahl der vCore die pCore übersteigt (oder der vRAM den pRAM an einer pCPU übersteigt) geht das halt nicht mehr, NUMA wird relevant. Alternativ könnte der Scheduler noch durch andere VMs, die Ressourcen bei ihm buchen, dazu bewogen werden, eine VM tatsächlich über mehr als eine pCPU zu verteilen, aber nie wenn er nicht muss weil er nicht will

Ich befasse mich in der Hinsicht immer mit VMware aber MS macht das 100% nicht anders weil es sinnvoll ist.
https://community.spiceworks.com/topic/189740-vmware-virtual-sockets-vs- ...
https://www.ewams.net/?date=2020/04/17&view=sockets_vs_cores_for_esx ...

Moin.
HyperV-VM, 4vCPUs, 8GB RAM, SQL Server Express 2017, darin u.a. eine SQL-Instanz für unsere Inventarisierung. Wenn ich diese nun mit Reports oder gar der Ausgabe aller inventarisierten Assets "quäle", sehe ich kurz Last auf allen 4 vCPUs. Sieht für mich also erstmal so aus, als würde das ganz gut funktionieren.

Verwirrend ist die RAM-Nutzung, die Instanz zieht aktuell ~4GB RAM, obwohl sie eigentlich nur 2GB bekommen dürfte.

Cheers,
jsysde

Die Aussage ist falsch.
Hyper-V stellt so viele Kerne zur Verfuegung wie du hast.
In der Regel (Standardserver) sind 4. - siehe Printscreens der anderen Beitraege.
Wie viele wirklich genutzt werden haengt dann von der Applikation selber ab.
Virtualisierung von SQL auf Hyper-V macht also Sinn.