none
Empfehlung bei SQL Server mit VMWare RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo

    Wie sind Eure Erfahrungen betreffend Performance. Bei einem VMWare-System(Cloud ohne direkte HD-Zuweisung etc) frage ich mich, ob IIS und SQL Server auf einem virt. Server installiert werden sollte und CPU/RAM/HD voll diesem Server zuzuweisen oder auf zwei virt. Server verteilen und dann z.B. dem IIS 2CPU und 2GB RAM und dem SQL Server 4 CPU und 16 GB RAM zuzuweisen.

    Betreffend Verbindungsaufbau würde doch bei der 1. Variante Shared Memory und bei 2. TCP/IP eingesetzt werden, oder täusche ich mich? Gibt es da Nachteile?

     

    Gruss Christoph

    Samstag, 1. Oktober 2011 20:34
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Christoph,

    beide Konstellation haben seine Vor- und Nachteile; welche die bessere ist, hängt von der Nutzung der Systeme ab.

    1 VM
    - OS wird gemeinsam genutzt, das schont Resourcen und Patch-Aufwand.
    - Gibt es Spitzenlast-Zeiten, kann die gesamte CPU/RAM Resource von einem genutzt werden
    - Nachteil: Läuft ein Dienst auf 100%, ist der andere kaum noch nutzbar

    2 VMs
    - Bessere Resourcen-Kontrolle, Last auf einem Dienst beeinflußt den anderen nicht
    - Separat patchbar, nur ein Dienst wäre während Wartung nicht verfügbar
    - Leichter skalierbar, da die einzelnen VMs auf andere System verschoben werden könnten
    - Nachteil: "Langweilt" sich ein System, bleiben die Resourcen völlig ungenutzt und können nicht von der anderen VM verwendet werden

    Siehe auch die gute Zusammenfassung & Linksammlung von Steffen Krause:

    http://blogs.technet.com/b/steffenk/archive/2011/08/23/betreiben-von-sql-server-in-virtualisierungsumgebungen-einige-hinweise.aspx

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Mittwoch, 5. Oktober 2011 16:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf

    Genau diese Gedanken habe ich mir auch gedacht.

    1. Da es IIS und SQL Server ist(sonst nichts) spielt die 100%-Last weniger eine Rolle. Wenn SQL 100% hat, kann der IIS eh nicht mehr liefern, auch wenn es auf 2 verteilt ist.
    Die Tatsache, dass man sich nicht entscheiden muss, ob jetzt beide 4 Kerne bekommen oder zusammen 8 und einmal braucht der IIS mehr, dann der SQL, finde ich positiv.

    2. Wenn nur der SQL währen Patch nicht verfügbar ist, geht IIS eh auch nicht mehr weil keine Daten kommen.

    Werde mir den Blogeintrag gleich mal durchlesen.

     

    Gruss Christoph

     

     

    Mittwoch, 5. Oktober 2011 19:38
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Christoph,

    dann würde sich anbieten, alles in einer VM laufen zu lassen; wäre höchstens noch der Punkt der Skalierbarkeit.

    Wegen der zweiten Frage, auf die ich noch nicht geantwortet hatte: Wenn beides in einer VM läuft, greift die IIS Applikation in der Tat per Shared Memory auf den SQL Server zu und das ist auch das optimale Protokoll in dem Fall. Für den Fall, das aus bestimmten Gründen die Verbindung trotzdem über TCP/IP erfolgen soll, kannst Du das im Connection String festlegen, indem Du vor dem SQL Server Name "tcp:" setzt, also z.B.

    Server=tcp:local\SQLEXPRESS

    Analog geht es mit np: für Named Pipes; das wäre aber sehr suboptimal.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Donnerstag, 6. Oktober 2011 15:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Christoph,

     

    Hat die Antwort von Olaf deine Situation abgeklärt?

     

    Viele Grüße,

    Alex

    Freitag, 7. Oktober 2011 20:06
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf

    Habe mal auf einer Test-Installation wo IIS und SQL auf dem gleichen Rechner ist, einen Test mit dem tcp: gemacht und da sind die Werte um rund einen Faktor 2 schlechter.

    Bei diesem Test wird vom IIS aus zuerst 100 mal ein Datensatz eingefügt, dann 2000 gelesen.

    Es geht also vorallem um die Abfrage/Verbindungsaufbau auf die DB selber.

    Ist das jetzt rein durch das tcp oder könnte man da noch etwas umstellen, damit es auch mit tcp schneller wird?

     

    Gruss Christoph

    Sonntag, 9. Oktober 2011 07:09
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Cristoph,

    Faktor 2 in welchem Bezug? Rein für den Verbindungsaufbau oder für die Auführung der gesamten Abfrage? TCP verursacht natürlich als Protokoll einen zusätzlichen Aufwand, aber das es sich dadurch derart verlangsamen soll kann ich mir nur schwerlich vorstellen.

    Und warum unbedingt TCP, lass doch ruhig die Verbindung per Shared Memory aufbauen.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Sonntag, 9. Oktober 2011 08:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf

    Bei diesem Test(ist ein Test aus der Software heraus) wird die Zeit vom Start bis zum Ende gemessen. Dabei wie erwähnt 100 Insert(und danach delete) in eine Key/Value-Tabelle und danach 2000 mal daraus lesen.

    Da z.B. beim Lesen das Select immer nacheinander kommt, dürfte das im Cache der DB sein.

    Ich habe jetzt einfach bei der DB-Verbindung das tcp vorangestellt(wie von dir geschrieben).

    Diese gemessene Zeit beträgt jetzt mit SM rund 600ms und bei TCP bei 1200ms.

    Sonst hat sich da nichts geändert. Den Test mache ich ja, um den Unterschied zwischen SM und TCP herauszufinden. Wenn ich das runter bringen, ist es dann auch besser, wenn Web und SQL auf zwei seperaten Servern liegen.

    Gruss Christoph

    Sonntag, 9. Oktober 2011 08:59
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo

    Nochmals eine Frage zum ganzen Thema. Kann ich mit SQL-Server-Tools(Profiler,..) messen, wie lange ein Verbinungsaufbau geht oder wie die Zeit ist, bis der Client(IIS) seine angeforderten Daten hat?

    Ich habe immer noch das Gefühl, dass mit der Verbindung etwas nicht korrekt läuft.

    Gruss Christoph

    Montag, 23. Januar 2012 15:15
    |
  • Question
    Anmelden
    0
    Anmelden

    bis der Client(IIS) seine angeforderten Daten hat?


    Hallo Christoph,

    Nein. Der Profiler kann nur den internen Ablauf im SQL Server wiedergeben, also z.B. wie lange die Laufzeit eines Statements ist.

    Wie lange die Netzwerkkommunikation dauert, kannst Du damit nicht ermitteln, aber dafür sollte es analoge Tools geben.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Montag, 23. Januar 2012 16:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen

    Jetzt hatte ich gerade mit einem Kunden ein Gespräch zu Aufteilung IIS/SQL-Server auf zwei VMWare-VM's. Beim Kunde seit gestern noch ein externer Berater gewesen(haben Netzwerk analysiert) und dieser meinte, dass er kürzlich an einem Vortrag/Präsentation von Microsoft gewesen sei und da wurde empfohlen, bei IIS/SQL-Server-Umgebungen IIS und SQL-Server auf eine VM zu nehmen. Dann hört man aber wie von SQL-Server-Experten, dass der SQL-Server alleine laufen soll :-0

     

    Gruss Christoph

    Mittwoch, 25. Januar 2012 08:52
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Christoph,

    damit wären wir wieder am Anfang, siehe mein erstes Post.
    Wie es immer so ist, 5 Personen => 7 Meinungen.

    Olaf Helper
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich
    Blog Xing
    Mittwoch, 25. Januar 2012 17:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich "mische" mich auch mal mit ein, weil wir sehr viel virtualisieren und ich damit schon so meine Erfahrungen gemacht habe.

    1. Wenn die Hardware ausreichend ist (Diskussione liefen ja bereits) würde ich IIS und SQL auf eine VM packen
        a) CPU für den SQL kann man mittels [Processor Affinity] regulieren
        b) RAM kann ich im SQL auch regulieren

    Somit wäre zumindest das Ressourcenproblem keines mehr

    2. Shared Mem vs. TCP/IP

    Da haben wir erst vor kurzem unsere Erfahrungen gemacht. Grundsätzlich kannst Du nur den ganzen Batch mit dem "Profiler" messen daraus kannst Du zumindest ermitteln, wie lange der gesamte Prozess dauert.

    In Bezug auf die Performance kannst Du nicht allgemein sagen, daß Shared Mem schneller ist als TCP/IP. Es hängt - das haben meine bisherigen Erfahrungen gezeigt - ganz deutlich von der Anwendung ab:

    - werden parametrisierte Abfragen verwendet
    - werden Stored Procs statt hunderter Einzelabfragen verwendet

    Dann kommt als ein nicht zu vernachlässigender Faktor (unabhängig von VM oder Physik) auch noch dazu, wo die Tempdb liegt, welches RAID (5, 1 oder 10) ihr verwendet, SAN, DAS, SSD, ...

    Mein erster Tipp wäre - wie Olaf ausgeführt hatte - alles auf eine VM. Sofern die Ressourcen nicht reichen, kann man später immer noch skalieren.
    Das sind ja gerade die Stärken des SQL Servers :D

    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de
    Donnerstag, 26. Januar 2012 16:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Uwe

    Zu deinem 2. Punkt. Es sind da schon sehr viele Einzelabfragen, welche auf den SQL-Server gemacht werden. Z.B bei einem integrierten Webmail werden pro Postfach die ungelesen Mail abgefragt und noch viele solcher kleiner Abfrage(welche Funktionen darf er alles sehen,....)

    Weil die VM's in der Cloud laufen, haben wir keine Möglichkeit, die Disks genau zu definieren sondern können die DB's einfach auf seperate Laufwerke verteilen.

    Besten Dank für die div. Beiträge. Ich werde das mal zusammenführen.

    Gruss Christoph

    Samstag, 28. Januar 2012 09:58
    |