Ich antworte in zwei Teilen: Erstens: "Warum die traditionelle Antwort über die Trennung von sequentiell und zufällig oft nicht zutrifft."
Anschließend werden die potenziellen Vorteile der Trennung von Dateien auf der physischen Windows-Festplatte sowie das Hinzufügen zusätzlicher vHBAs und das Verteilen der physischen Festplatten auf diese beschrieben.
Der erwartete Vorteil der Trennung von zufälligen und sequenziellen Festplatten-E / A-Vorgängen auf der Ebene der physischen Windows-Festplatte setzt normalerweise Festplattengeräte für die Datenspeicherung voraus. In der Regel wird auch davon ausgegangen, dass separate Windows-Festplatten separate Festplattengeräte bedeuten. Die Idee ist, dass einige Festplatten hauptsächlich sequentielle Festplatten-E / A-Vorgänge verarbeiten und nur eine sehr begrenzte Bewegung des Festplattenkopfs aufweisen (z. B. die Festplatten, die ein einzelnes, geschäftiges txlog * hosten), während ein separater Festplattensatz zufällige Festplatten-E / A-Vorgänge verarbeitet.
Diese Annahmen treffen heutzutage nur noch selten zu - insbesondere in einer virtuellen Maschine. Wenn es sich bei den Windows-physischen VMs nicht um RDMs handelt, können sich mehrere in einem einzelnen Datenspeicher befinden - oder möglicherweise befinden sich mehrere Datenspeicher auf einer einzelnen ESXi-Host-LUN. Was also im Gast getrennt ist, kann auf der ESXi-Host-Ebene gemischt werden.
Angenommen, RDMs werden verwendet, oder jede physische Gastfestplatte befindet sich in einem eigenen Datenspeicher, in einer eigenen ESXi-LUN. Sogar dann wird das Array häufig getrennt von zufälligen Io-Sequenzen im Gast gemischt, da die dem ESXi-Host präsentierten LUNs möglicherweise aus demselben Pool von Festplattengeräten stammen. Nahezu jedes Speicher-Array tut dies jetzt - entweder exklusiv oder als Option, um die Verwaltung zu vereinfachen und die Effizienz des Arrays / die Ressourcennutzung zu steigern.
Schließlich ist so viel Speicher heutzutage entweder alles Flash oder Hybrid Flash + HDD. Da keine Kopfbewegungen zu befürchten sind, kümmert sich Flash nicht um die Trennung von sequentiellen für zufällige… kümmert sich nicht einmal um IO-Weben.
Also… all das sind die Gründe, warum die Trennung von sequentiell und zufällig möglicherweise nicht so vorteilhaft ist. Weiter, warum das Verteilen von Dateien auf physische Festplatten und das Verteilen von physischen Festplatten auf vHBAs die Leistung trotzdem steigern kann.
* In diesem HDD-Beispiel habe ich absichtlich ein einzelnes Transaktionsprotokoll erwähnt. Wenn mehrere sequenzielle Festplatten-E / A-Streams (z. B. 8 Transaktionsprotokolle) auf derselben Festplatte ausgeführt werden - es sei denn, fast alle Aktivitäten befinden sich im SAN-Cache - führt eine konstante Kopfbewegung zwischen den sequenziellen E / A-Tracks zum E / A-Weben. Dies ist eine bestimmte Art von Plattenkopfthrashing, die zu einer "schlechteren als zufälligen" Latenzzeit führt. Tritt bei RAID5 und RAID10 auf, obwohl RAID10 in dieser Hinsicht nur geringfügig mehr Abweichungen tolerieren kann als RAID5, bevor es zu einer wesentlichen Verschlechterung kommt.
Nun - angesichts der langwierigen Diskussion darüber, wie das Trennen von sequentiellen und zufälligen Dateien möglicherweise nicht hilft - wie kann das Verteilen von Dateien auf physische Festplatten weiterhin helfen? Wie kann das Verteilen von physischen Festplatten unter vHBAs helfen?
Es dreht sich alles um Festplatten-E / A-Warteschlangen.
Jede physische Windows-Festplatte oder LogicalDisk kann bis zu 255 ausstehende Festplatten-E / A-Vorgänge gleichzeitig in der von perfmon als "Current Disk Queue" angegebenen Warteschlange ausführen. Von den ausstehenden Festplatten-E / A-Vorgängen in der physischen Festplattenwarteschlange kann der Storport bis zu 254 an den Minitreiber übergeben. Der Minitreiber kann aber auch sowohl eine Warteschlange (die an die nächstniedrigere Ebene weitergeleitet wird) als auch eine Warteschlange haben. Und Storport kann angewiesen werden, die Anzahl der Weiterleitungen von 254 zu verringern.
In einem VMware Windows-Gast hat der pvscsi-Treiber eine Standard-Warteschlangentiefe von "Gerät" von 64, wobei das Gerät eine physische Festplatte ist. Obwohl perfmon für eine einzelne physische Festplatte bis zu 255 Festplatten-E / A-Vorgänge in der "aktuellen Warteschlangenlänge" anzeigen kann, werden jeweils nur bis zu 64 von ihnen an die nächste Ebene übergeben (es sei denn, die Standardeinstellungen werden geändert).
Wie viele Datenträger IOs kann hervorragend sein , um einBelegtes Transaktionsprotokoll gleichzeitig? Nun, Transaktionsprotokoll-Schreibvorgänge können bis zu 60 KB groß sein. Während einer hochskalierten ETL sehe ich oft, dass jeder Schreibvorgang mit 60 KB in das txlog geschrieben wird. Der TXLOG-Writer kann bis zu 32 Schreibvorgänge von jeweils 60 KB für ein TXLOG ausführen. Was ist, wenn sich auf derselben physischen Festplatte ein beschäftigtes Staging-TXLOG und ein beschäftigtes DW-TXLOG mit den standardmäßigen VMware-Einstellungen befinden? Wenn beide txlogs bei jeweils 32 ausstehenden 60-KB-Schreibvorgängen maximal sind, befindet sich diese physische Festplatte in ihrer Warteschlangentiefe von 64. Was ist nun, wenn sich auch Flatfiles als ETL-Quelle auf der physischen Festplatte befinden? Naja ... zwischen den Lesevorgängen für die Flatfiles und den Schreibvorgängen für txlog müssten sie die Warteschlange verwenden, da immer nur 64 auf einmal aussteigen können. Für Datenbanken mit solchen ausgelasteten TXLogs, egal ob physischer oder virtueller Server, empfehle ich das TXLog auf einer eigenen physischen Festplatte. mit nichts anderem auf der physischen Festplatte. Auf diese Weise wird ein Anstehen auf dieser Ebene verhindert und die Sorge um den Inhalt mehrerer verschachtelter Dateien beseitigt (was heutzutage ein weitaus geringeres Problem darstellt).
Wie viele Datenträger-E / A-Vorgänge können gleichzeitig für eine Zeilendatei ausstehen (aus Sicht von SQL Server müssen sie nicht unbedingt an niedrigere Ebenen gesendet werden)? In SQL Server selbst gibt es keine wirkliche Beschränkung (die ich sowieso gefunden habe). Unter der Annahme, dass sich die Datei auf einer einzelnen physischen Windows-Festplatte befindet (ich empfehle nicht, dynamische Striped-Festplatten für SQL Server zu verwenden, da dies ein Thema für eine andere Zeit ist), gibt es ein Limit. Es ist der 255, den ich zuvor erwähnt habe.
Mit der Magie von SQL Server Readahead und asynchronem E / A habe ich 4 gleichzeitige Abfragen gesehen, von denen jede auf einem seriellen Laufwerk mit einer "aktuellen Warteschlangenlänge" von über 1200 ausgeführt wird! Aufgrund der Beschränkung auf 255 ist dies nicht einmal bei allen Zeileninhalten auf einer einzelnen physischen Festplatte möglich. Es handelte sich um eine primäre Dateigruppe mit 8 Dateien, die sich jeweils auf einer eigenen physischen Festplatte befanden.
Readahead-Lesevorgänge können daher sehr aggressiv sein und E / A-Warteschlangen belasten. Sie können so aggressiv sein, dass andere Rowfile-Lese- und -Schreibvorgänge warten. Wenn sich Transaktionsprotokolle auf derselben physischen Festplatte wie Zeilendateien befinden, kann es beim gleichzeitigen Lesen und Schreiben von Texten sehr leicht zu Wartezeiten kommen. Auch wenn diese Wartezeit nicht die "aktuelle Warteschlangenlänge" aufweist, wartet sie möglicherweise in der Gerätewarteschlange (standardmäßig 64 bei pvscsi).
Sicherungslesevorgänge für Zeilendateien können auch aggressiv sein, insbesondere wenn die Pufferanzahl optimiert wurde, um den Sicherungsdurchsatz zu maximieren.
Es gibt noch einen weiteren SQL Server io-Typ, den Sie berücksichtigen sollten, wenn Sie erwägen, txlogs zu isolieren: Abfrageabgabe an tempdb. Wenn ein Abfrageablauf stattfindet, schreibt jede Abfragearbeit in tempdb. Haben Sie viele Parallelarbeiter gleichzeitig? Das kann eine ziemliche Schreiblast sein. Es kann sehr hilfreich sein, ein volles txlog und wichtige zeilendateien davon fernzuhalten :-)
Jetzt ist es möglich, die Standardtiefe der Gerätewarteschlange für den pvscsi-Treiber zu ändern. Der Standardwert ist 64 und kann auf 254 eingestellt werden. Dies ist der Storport, der am häufigsten weitergegeben wird. Aber seien Sie vorsichtig, wenn Sie dies ändern. Es wird immer empfohlen, die Warteschlangentiefe des Gastgeräts an der zugrunde liegenden Warteschlangentiefe der ESXi-Host-LUN auszurichten. Best Practices für das Festlegen der Tiefe der ESXi-Host-LUN-Warteschlange pro Array. Verwenden Sie eine EMC VNX? Die Tiefe der Host-LUN-Warteschlange sollte 32 betragen. Gast verwendet RDMs? Groß. Stellen Sie die Warteschlangentiefe für Gast-PVSCSI-Geräte auf 32 ein, damit sie mit der Warteschlangentiefe der ESXi-Host-LUN übereinstimmt. EMC VMAX? Normalerweise 64 auf ESXi-Hostebene, 64 als Gast. Pure / Xtremio / IBM FlashSystem? Manchmal wird die Tiefe der Host-LUN-Warteschlange auf 256 festgelegt! Stellen Sie anschließend die Warteschlangentiefe für pvscsi-Geräte auf 254 (Maximal möglich) ein.
Hier ist ein Link mit Anweisungen.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Der Link spricht auch über requestringpages - WhatAreThose ?? Sie bestimmen die Warteschlangentiefe für den pvscsi-Adapter selbst. Jede Seite enthält 32 Steckplätze für die Tiefe der Adapterwarteschlange. Standardmäßig ist requestringpages 8 für eine Adapterwarteschlangentiefe von 256. Sie kann für 1024 Adapterwarteschlangentiefen-Slots auf 32 festgelegt werden.
Angenommen, alles ist in der Standardeinstellung. Ich habe 8 physische Datenträger mit Zeilendateien und SQL Server ist leicht ausgelastet. Es gibt durchschnittlich 32 "aktuelle Warteschlangenlänge" über die 8, und keine ist höher als 64 (alles passt in die verschiedenen Gerätewarteschlangen). Großartig - das ergibt 256 OIO. Es passt in die Gerätewarteschlangen und in die Adapterwarteschlange, sodass alle 256 Benutzer nicht mehr zu Warteschlangen auf der ESX-Hostebene gelangen.
Aber ... wenn die Dinge ein wenig geschäftiger werden, sind es durchschnittlich 64 mit einer Warteschlange einiger physischer Festplatten von bis zu 128. Bei Geräten mit mehr als 64 ausstehenden Geräten befindet sich die Überlastung in einer Warteschlange. Befinden sich auf den 8 physischen Festplatten mehr als 256 Geräte in der Servicewarteschlange, befindet sich die Überlastung in einer Warteschlange, bis sich Steckplätze in der Adapter-Servicewarteschlange öffnen.
In diesem Fall verdoppelt das Hinzufügen eines weiteren pvscsi-vHBA und das Verteilen der physischen Datenträger zwischen ihnen die Gesamttiefe der Adapterwarteschlange auf 512. Gleichzeitig kann mehr io vom Gast an den Host übergeben werden.
Ähnliches könnte erreicht werden, wenn Sie bei einem pvscsi-Adapter bleiben und die Anforderungsseiten erhöhen. Wenn Sie auf 16 wechseln, erhalten Sie 512 Slots und 32 1024 Slots.
Wenn möglich, empfehle ich, zunächst die Breite (Hinzufügen von Adaptern) und dann die Tiefe (Erhöhen der Tiefe der Adapterwarteschlange) zu erhöhen. Aber… auf vielen der am stärksten ausgelasteten Systeme müssen Sie beides tun: Platzieren Sie 4 vHBAs auf dem Gast und erhöhen Sie die Anforderungsseiten auf 32.
Es gibt noch viele andere Überlegungen. Dinge wie sioc und adaptive Warteschlangentiefenbeschränkung bei Verwendung von VMDKS, Konfiguration von Multipathing, Konfiguration des ESXi-Adapters über die LUN-Warteschlangentiefe hinaus usw.
Aber ich möchte mein Willkommen nicht überschreiten :-)
Lonny Niederstadt @sqL_handLe