"20.000 IOPS pro Knoten bieten eine gute Leistung bei einer Latenz von 5 ms." Für OLTP - nein

Der Grund für das Schreiben dieses Artikels war eine sehr würdige Überprüfung, wie wir VMware vSAN ... CROC getestet haben. Die Rezension ist es wert, aber sie enthält einen Satz, mit dem ich seit mehr als einem Jahrzehnt zu kämpfen habe. Speicheradministratoren, Virtualisierer und Integratoren wiederholen immer wieder: "Verzögerungen von 5 ms sind ein hervorragender Indikator." Auch die Zahl von 5 ms für zehn Jahre ändert sich nicht. Ich habe das mindestens ein Dutzend Mal live von hoch angesehenen Admins gehört. Von weniger angesehenen - Dutzenden und wie oft ich im Internet lese ... Nein, nein, nein. Bei OLTP-Lasten von 5 ms, insbesondere wenn sie normalerweise gemessen werden, handelt es sich um epische Fehler. Ich musste die Gründe dafür oft erklären, diesmal beschloss ich, meine Gedanken in einer wiederverwendbaren Form zu sammeln.

Ich muss sofort sagen, dass der oben erwähnte Artikel keine derartigen Fehler enthält, sondern dass der Ausdruck als Auslöser fungierte.

Typischer Start

Alles, was in diesem Artikel beschrieben wird, gilt für gängige DBMS, die für typisches Geschäfts-OLTP verwendet werden. Vor allem habe ich Erfahrung mit MS SQL Server, aber zumindest für PostgeSQL, Oracle und Sybase werden auch viele Punkte und Schlussfolgerungen zutreffen.

Leistung DBMS ist normalerweise mit allen unzufrieden. Wenn es in einem großen System ein DBMS gibt - und es plötzlich fast immer da ist -, ist dieses DBMS ein Engpass. Nun, oder es wird sofort zu einem Engpass, wenn Sie anfangen, alles andere zu optimieren. Und so kommt der Kunde und sagt mit menschlicher Stimme: "Hilfe! Sparen! Sie haben $ NNNNNNNN für den Server und den Speicher bezahlt, aber die Geschwindigkeit steigt nicht! Oh, und der Administrator hat eingerichtet und der Anbieter hat sich beraten, bewegt sich aber immer noch nicht." Wenn die Entwickler des Systems der Definition von Lawrow entsprechen (wir können auf ein genaues Angebot verzichten) und die Betriebs- und Wartungsspezialisten „mit Vorfällen durch Neustart des Servers kämpfen“, ist das Problem oft einfach und unprätentiös: Es gibt keine Indizes, krummen Abfragen, schwerwiegende Konfigurationsfehler (über die die Dokumentation fett gedruckt ist) es heißt "das kannst du nicht !!!" ), übermäßige Sperren, Deadlocks und anderer einfacher und klarer Unsinn. Es gibt viele solcher Fälle, die meisten, aber nicht alle. Wenn das System in seiner Komplexität oder Auslastung eine unsichtbare Grenze überschritten hat, stirbt es entweder an diesen Problemen oder geht zur nächsten Ebene über.

Auf dieser Ebene befindet sich der Server nicht mehr unter der Tabelle des Direktors, die Festplatten befinden sich nicht mehr im Server, aber im Speichersystem kennen Entwickler Indizes und Administratoren kennen PowerShell bereits, und IT-Manager beginnen, intelligente Wörter wie SLA und RPO / RTO zu sagen. Auf dieser Ebene ergibt sich eine interessante Situation:

• DBMS ist ein Engpass.
• Der Server scheint in jeder Hinsicht ausreichend zu sein.
• DBMS kann programmgesteuert weiter verbessert werden, ist jedoch schwierig (entweder zu teureren Lizenzen wechseln oder zur Optimierung in die "rote Zone der Shipilev-Kurve" wechseln)
• Das Festplattensystem ist teuer gekauft und anscheinend sogar irgendwie konfiguriert.

Aber nein. Das Krokodil wird nicht gefangen, die Kokosnuss wächst nicht und die Systemleistung ist gleich oder niedriger als auf dem alten Server. Ich schaue in sys.dm_os_waitsats und sehe oben WRITELOG , PAGEIOLATCH_SH und PAGEIOLATCH_EX , die durchschnittliche Wartezeit beträgt 5+ ms. Nun, typisch, cho: "Hey, Admins und DBA, hier hast du ein Diskettensystem - Engpass" und hier beginnt ein altes Lied über 5 ms:

• Wir haben 5 ms für SLA
• Ja, wir haben ein Regiment von 20.000 IOPS
• Der Anbieter teilte uns mit, dass sich alle Datenbankdateien auf einer Partition befinden können
• Wir haben Virtualisierung und Hyperkonvergenz und können keine separaten Festplatten unter der Datenbank zuordnen
• Nach unseren Angaben beträgt die Serverauslastung 5%
• Alles ist gemäß den Empfehlungen konfiguriert
• Ihre Datenbanken benötigen nicht viel Leistung, sie leisten nicht mehr als 300 IOPS (und wir haben ein Regal für 20.000 IOPS).

Übrigens, all das, nicht nur über "ihre" Server, sondern auch über Cloud-Dienste und Virtualisierung. Es gibt eine Reihe eigener Besonderheiten, aber das typische klinische Bild ist ungefähr das gleiche: mäßig optimierte Datenbank, cleveres Entwicklungs- und Wartungspersonal, eine Reserve für Prozessor und Speicher, der "Auspuff" aus weiteren Investitionen ist nahezu Null.

Also. Dieses ganze Lied über "5 ms" ist Unsinn und Unsinn. Wenn Sie dies selbst sagen, lesen Sie diesen Artikel. Und wenn sie dir das sagen, bereite die Argumente vor. Früher, als ich diese Worte hörte, war ich wütend, aber ich bin nicht mehr wütend. Ich habe wie dieser Topf mit einer Petunie aus dem Per Anhalter durch die Galaxis nur einen Gedanken: "Nun, wieder ...".

Wer ist schuld?

Warum ist die Datenbank so langsam? Nun, es scheint, dass ein typischer Server mit 20-64 Kernen bei einer Frequenz von 2-3 GHz 50-150 Milliarden einfache Operationen ausführen kann, und die maximalen (synthetischen) Datenbanktests zeigen auf solchen Maschinen nur 10.000-50000 Transaktionen pro Sekunde. Hey! Nun, das sind eine Million bis ein Dutzend mögliche Millionen von Transaktionen pro Transaktion. Es ist nicht nur viel, es ist viel zu spüren.
Ein solcher Overhead kostet ACID- Anforderungen für Transaktionen.

• Eine Tomicity - entweder ist die gesamte Transaktion abgeschlossen oder das Ganze ist nicht abgeschlossen.
• C onsistancy - Beim Ein- und Ausstieg einer Transaktion befindet sich das System in einem konsistenten Zustand
• Ich solation - Transaktionen sehen nicht die Zwischenzustände des anderen
• Dauerhaftigkeit - Wenn die Transaktion erfolgreich abgeschlossen (festgeschrieben) wurde, müssen die vorgenommenen Änderungen unabhängig von den Umständen im System verbleiben.

Buchstabe für Buchstabe werden diese Anforderungen übrigens fast nirgendwo und nie erfüllt, sondern einfach nie in verteilten Systemen (der CAP-Satz greift ein). In unserer Situation ist die D-Anforderung höchstwahrscheinlich teurer als andere. Diese Anforderung wird durch den Schlüsselmechanismus aller gängigen OLTP-DBMS bereitgestellt: WAL, Write-Ahead-Protokoll (PostgeSQL), es ist auch ein Transaktionsprotokoll (SQL Server), auch bekannt als REDO-Protokoll (Oracle). Hier ist es - ein Stein am Hals der Produktivität, und es ist die Grundlage für Durability-Transaktionen.

Was ist WAL?

Vergessen wir für einen Moment moderne SSDs, coole Speichersysteme. Angenommen, wir haben einen Server, der eine oder mehrere Festplatten hat.
Jede Transaktion, auch das Einfügen eines Datensatzes, ist zumindest potenziell, aber tatsächlich fast immer und realistisch eine nichtatomare Aktion. Wir müssen fast immer nicht nur die Seite ändern, auf der sich der Datensatz befindet, sondern auch Indexseiten, möglicherweise Serviceseiten. Darüber hinaus kann sich dieselbe Seite in derselben Transaktion viele Male ändern. Außerdem können andere Transaktionen parallel zu uns durchgeführt werden. Darüber hinaus "ziehen" die zeitlich benachbarten Transaktionen ständig die gleichen Seiten. Wenn wir warten, bis jede Seite auf die Festplatte geschrieben ist, bevor wir fortfahren, was im Wesentlichen für die Haltbarkeit erforderlich ist, müssen wir ein Vielfaches mehr schreiben und warten, bis jede Aufnahme auf nichtflüchtigen Medien abgeschlossen ist. Keine Caches, keine Neuordnung von Operationen in der Warteschlange, sonst gibt es keine Integrität! Außerdem müssen wir irgendwie feststellen, welche Daten sich bereits auf festen Transaktionen befinden und welche noch nicht (und welche Daten zuvor waren). Zum Verständnis - eine typische einzelne Festplatte (HDD) in diesem Modus liefert 50-100 IOPS, und dies ist seit 20 Jahren eine Konstante. Eine kleine Transaktion erfordert 5-10 Schreibvorgänge. Ah ja, um zu wissen, was aufzunehmen ist, müssen Sie es lesen. Selbst sehr, sehr stark beschreibbare OLTP-Systeme lesen dreimal mehr als sie schreiben. Somit kostet unsere Transaktion 20-40 IO, was 0,2-0,8 Sekunden pro Festplatte bedeutet.
2 Transaktionen pro Sekunde. Nicht genug? Versuchen wir, die Festplatten zu verteilen. Oh, aber wir müssen noch warten, bis die vorherige aufgenommen ist und es am Ende keine Parallelität gibt. Wie man ist Und starten wir eine Protokolldatei, in der wir nacheinander alle Schreibvorgänge in der Datenbank und die Transaktionsmarken aufzeichnen! Vorteile:

• Informationen über den Vorgang können viel kompakter sein als das Aufzeichnen der gesamten Seite (eine typische Seitengröße beträgt 8 KB, in das Protokoll geschriebene Informationen betragen häufig 0,5 bis 1 KB).
• Anstatt darüber zu schreiben, ob die Transaktion direkt auf der Seite aufgezeichnet wurde oder nicht, gibt es im Protokoll genügend Beschriftungen für den Beginn und die Korrektur der Transaktion.
• Seiten können nicht nach jeder Transaktion geschrieben werden - um ein Vielfaches weniger. Das Lesen / Schreiben von Daten wird vollständig aus dem Protokoll "gelöst".
• Die Hauptsache. Wenn wir unser Journal auf einer separaten Festplatte ablegen und Datensätze nacheinander schreiben, werden aufgrund der Tatsache, dass Sie die Festplattenköpfe nicht ständig neu positionieren müssen, selbst eine Haushaltsfestplatte in diesem Modus bis zu 1000 IOPS komprimiert, da kleine Transaktionen 2-4 Journaleinträge „kosten“. dann können Sie 200-400 TPS drücken
• Im Falle eines Fehlers kann der Status der Datendatei aus einem solchen Protokoll wiederhergestellt werden. Wenn die Transaktion abgebrochen wird, kann sie zurückgesetzt werden

Ein solches Protokoll wird als Vorausschreibprotokoll / Transaktionsprotokoll / REDO-Protokoll bezeichnet.

Hurra! Großartig! Es gab 2 Transaktionen pro Sekunde, es wurde 300 - 150-mal verbessert. Und zu welchem ​​Preis? Wie sich herausstellt, ist der Preis erheblich:

• In allen gängigen DBMS ist die Protokollierung streng konsistent. Ein Thread ist für das Schreiben in das Protokoll verantwortlich. Haben Sie 100 Prozessoren? Cool. Und das Protokoll schreibt immer noch einen Thread. Die Tiefe der Warteschlange ist genau eins.
• Trotzdem - keine Betriebssystem-Caches, keine Operationspermutationen. Die Anforderungen an die Haltbarkeit blieben bestehen. Durchschreibvorgänge: Bis die CD mit "Ich habe geschrieben, ich habe sie direkt an die Oberfläche geschrieben, sicher nicht in den Cache" antwortete. Das DBMS funktioniert nicht weiter.
• Wenn Sie die Protokolldatei auf der Datendiskette ablegen, gehen fast alle Vorteile der sequentiellen Aufzeichnung verloren. Außerdem - für immer, wenn sich mehrere Datenbanken auf dem Server befinden, dann mehrere Datenträger für Magazine.
• Transaktions-Rollback (zumindest in MS SQL Server) - Lesen Sie das Protokoll und stellen Sie den Status wieder her. Dies sind so viele oder sogar mehr Schreibvorgänge, wie Schreibvorgänge in der Transaktion vorhanden waren. Rollback ist teuer!

Diese Erklärung ist sehr vereinfacht, "an den Fingern". Das reicht für unser Thema. WAL ist ein wichtiger, grundlegender Mechanismus zur Gewährleistung der Transaktionsfähigkeit. Es handelt sich notwendigerweise um Durchschreiben. Der Zugriff erfolgt nur für die sequentielle Aufzeichnung mit einem Thread. Aus Sicht der Speicherung beträgt die Warteschlangentiefe 1.

Das Thema der Vorausschreibprotokollierung in der Datenbank sollte jedem, der das DBMS oder die DBMS-Infrastruktur irgendwie verwaltet oder Datenbanken entwickelt, zumindest minimal bekannt sein.

WAL und SHD

Speicherhersteller von Geburt an sind mit DBMS konfrontiert. Für Datenbanken kauft das Unternehmen diese wahnsinnig teuren Komplexe: Aus den Straßenpreisspeichern von Dell-EMC, HP, Hitachi und NetApp füllen sich die Augen für die meisten Top-Manager mit Tränen, es sei denn, sie erhalten natürlich einen Prozentsatz dieses Preises. Es gibt jedoch einen Engineering- und Marketingkonflikt. Ich werde es am Beispiel von Dell-EMC erläutern, aber nur, weil ich mich daran erinnere, wo sich die Dokumentation befindet.

Also:

1. Single Threaded Journal
2. Das Durchschreibprotokoll, dh die Latenz, ist im Vergleich zur CPU-Leistung "ewig"
3. OLTP-Lasten sind viele relativ kleine Transaktionen.
4. Die meisten anderen DBMS-Lasten sind auf die eine oder andere Weise parallel.

Amdahls Gesetz sagt uns gnadenlos, dass eine Single-Threaded-Last mit geringer Leistung das Hinzufügen von Prozessoren unbrauchbar macht und die Leistung durch das Protokoll bestimmt wird. Darüber hinaus werden wir uns in diesem Moment nicht um die Leistung des Speichers in IOPS kümmern, und nur die Latenz wird wichtig.
Diskontieren Sie jedoch nicht andere Festplattenvorgänge - Lesen und Schreiben in Datendateien und tempdb . Lesen ist auch eine "wartende" Operation. Bis eine Datenseite von der Festplatte in den Speicher gelesen wird, kann der Prozessor sie nicht verarbeiten. Bei diesen Vorgängen sind jedoch große Warteschlangen und die Permutation von Vorgängen in dieser Warteschlange möglich: Das DBMS weiß häufig, welche Seiten in den Speicher geladen werden müssen, welche Seiten ausgegeben werden müssen, und stellt viele Warteschlangen gleichzeitig zum Lesen bereit. Da es in diesem Szenario wichtig ist, wenn die letzte Operation aus dem Bundle endet, ist IOPS bei dieser Last im Gegenteil wichtiger als die Latenz einer einzelnen Operation. Um den Umfang zu verstehen: Lesevorgänge in einem typischen OLTP-System sind 85% -95%. Ja, ja, ja, Schreiboperationen sind um eine Größenordnung geringer.

Vendor Storage-Ingenieure arbeiten eng mit DBMS-Anbietern zusammen und kennen alle technischen Nuancen der Funktionsweise eines DBMS mit einem Festplattensubsystem. Die ordnungsgemäße Planung, Partitionierung und Zuweisung von Festplattenressourcen für das DBMS ist eine komplexe und wichtige Kompetenz des Administrators des Speichersystems . Dieselbe Dell-EMC verfügt sogar über das grundlegende Whitepaper H14621 und H12341 zum Partitionieren von Empfehlungen für SQL Server - über hundert Seiten. Hey! Dies ist kein detailliertes Dock, dies ist das am häufigsten verwendete Whitepaper! Es gibt immer noch eine Reihe spezifischer ( h15142 , h16389 ... dort herrscht Dunkelheit). Die „Nachbarn“ von VMware - Architektur von Microsoft SQL Server auf VMware vSphere liegen nicht weit zurück. Bitte beachten Sie, dass diese Dokumente nicht nur für Datenbankadministratoren, sondern auch für Infrastruktur- und Speicheradministratoren bestimmt sind.
Ich tempdb auch fest, dass in all diesen Dokumenten separate LUNs für Daten, Protokolle und tempdb . Ja, irgendwo in den neuesten Dokumenten heißt es genau, dass es für All-Flash-Lösungen keinen Sinn macht, die Protokolle in physisch getrennte Medien aufzuteilen, aber LUNs bieten immer noch an, sie getrennt zu schneiden. Wenn Sie Daten sichern und sich bei einer LUN anmelden, handelt es sich aus Sicht des Betriebssystems um eine E / A-Warteschlange. Und es wird ein Problem geben. Latenzoperationen haben sofort eine Größenordnung mehr. Und aufgrund der Tatsache, dass nicht verschiebbare Protokollvorgänge in der Warteschlange angezeigt werden, rutscht IOPS auf Datendateien und tempdb . Dies ist keine "Entdeckung des Jahrhunderts", sondern eine elementare Wahrheit der Arbeit mit der Datenbank. Es ist nicht veraltet oder mit dem Aufkommen von All-Flash abgebrochen. Ja, Verzögerungen bei Operationen mit SSDs sind um eine Größenordnung schneller als bei Operationen mit HDDs, aber immer noch einige Größenordnungen langsamer als Operationen mit Speicher. IO ist immer noch der Engpass des DBMS.
Und die technischen Dokumente betonen korrekt, dass in den Transaktionsprotokollen die Anzahl der IOPS nicht wichtig ist, aber es ist wichtig, dass die Latenz minimal ist (in der heutigen Zeit wird geschrieben, dass weniger als 1 ms).

Aber Vermarkter müssen verkaufen. Hyperkonvergenz! Virtualisierung! Flexibilität bei der Bereitstellung! Deduplizierung! Einfache Einrichtung! Viele, viele IOPS! Schöne Präsentationen, selbstbewusste Stimme, formelle Kostüme. Aber wie kann man sonst eine Lösung mit einem 6-7-stelligen Preis in Dollar verkaufen? Aus diesem Grund wird irgendwie vergessen, dass entweder Latenz oder Durchsatz vom Speichersystem abgerufen werden können, aber nicht beide gleichzeitig, dass eine Art Lizenz für den Load Balancer wie ein anderes Regal ist, dass, wenn die intensive Aufzeichnung länger als eine Stunde dauert, der RAM der Controller Es ist nicht genug und die Produktivität wird auf "als ob es keinen Cache gibt" sinken. Die Schulung der Mitarbeiter des Kunden kostet im ersten Jahr weitere 100.000 Rubel. Nun, solche Tricks ...

5 ms

Entweder viel vom Lesen von Vermarktern oder von Faulheit gehört zu haben oder wegen irgendeiner Art von Kakerlaken, aber aus irgendeinem Grund tun Speicheradministratoren oft so etwas. Wir nehmen ein großes Regal, kombinieren alles zu etwas Flachem, schneiden es in dünne bereitgestellte LUNs und verteilen es per LUN an den Server. Oder zwei, weil "die Systempartition gut dedupliziert ist". Und wenn ich sehe, dass mit dem Festplattensubsystem von der Seite von SQL Hölle-Hölle-Hölle, dann beginnt genau das Lied, dass "5 ms ein ausgezeichneter Indikator ist", dass "100000 IOPS", "Ihre Speicherlast ist weniger als 5%"

NEIN .

• Für OLTP-Systeme auf einer Partition mit WAL / Transaktionsprotokollen von 5 ms ist dies ein ungültiger Indikator. Auf dem "fast handelsüblichen" Stück Eisen zu einem Preis von 1000 (in Worten: tausendmal) billiger ist der normale Indikator jetzt 0,1 bis 0,3 ms. Und morgen - 0,01 ms. Geschwindigkeit wie die der Festplatte von 2008 zum Preis eines ganzen Eingangs von Wohnungen in Moskau ist nicht erforderlich. Keine „Wartungsfreundlichkeit“ lohnt sich.
• Schreibt der Anbieter, dass Transaktionsprotokolle keine Anforderungen an IOPS stellen und auf die Festplatte gestellt werden können? Ja das stimmt. Dafür ist jedoch keine dieser Festplatten erforderlich Ansteckung Zusätzlich zum Schreiben von Protokollen hat das DBMS die Aufgabe nicht berührt. Und damit das Speichersystem dem Server antwortet, dass die Daten geschrieben werden, sofort, wenn die Daten in den nichtflüchtigen Speicher gelangen (dies ist viel früher als sie geschrieben werden).
• Dünne Festplatten für echte OLTP-Datenbanken sind böse.
• Für WAL ist es absolut uninteressant, wie viel IOPS bei einer Warteschlangentiefe von 10 oder 20 herausgedrückt werden kann. Dort gibt es keine Tiefe.
• Für WAL ist dies absolut kein Indikator dafür, dass die E / A-Warteschlange im Betriebssystem "nur etwa 1" beträgt. Sie wird nicht mehr sein.
• Nein, DBA- und DB-Entwickler sind keine "Spechte, die sich nicht richtig konfigurieren können, um in die WAL-Parallele zu schreiben" (echte Meinung des Administrators).
• Die Logik der Lüfter, das Recycling in Betracht zu ziehen "Da Ihr System, das wir krumm in einer Partition konfiguriert haben, keine 10.000 IOPS ausführt, muss es von einem High-End-Array in einen mittleren Bereich verschoben werden" - dies ist eine falsche Logik.
• Wenn der 40-Core-Server eine Prozessorlast von 2,5 Prozent hat, bedeutet dies nicht, dass er nichts zu tun hat, sondern höchstwahrscheinlich, dass es eine Aufgabe gibt, die alle anderen blockiert.

Wenn das Laden einiger Daten auf den Laptop des Entwicklers 5 Minuten dauert und auf dem 40. Nuklearserver mit 1 TiB RAM und Speicher für eine halbe Million Dollar dieselbe Aufgabe eine Stunde lang ausgeführt wird, haben selbst die geduldigsten Kunden Fragen zur Machbarkeit der Kosten.

Was zu tun ist

Admin-Tipps und Datenbankadministratoren

Hören Sie bei OLTP auf, „Recycling“ und IOPS zu zählen. Unabhängig davon stelle ich fest, dass IOPS überhaupt nicht mit einer großen Warteschlangentiefe betrachtet werden: Selbst auf Datenpartitionen weisen große Warteschlangen normalerweise einen kurzen Burst auf oder etwas, das die tatsächliche Leistung von OLTP nicht beeinträchtigt.

Das Teilen von Speicherplatz durch LUN ist keine DBA-Laune. Die Datenbank verfügt über verschiedene Lastprofile des Festplattensubsystems. Zumindest kann Folgendes unterschieden werden:

• Arbeiten Sie mit Datendateien. Normalerweise liest und schreibt dies mit zufälligen Blöcken von 8/64 KiB. Messwerte 80-95%. Warteschlangen entstehen: während Dienstzeiten, während Massenladezeiten, bei ineffizienten oder Massenanforderungen und während des Prüfpunkts. Die Leistung wird durch die Reaktionsfähigkeit auf das Lesen beeinflusst. Es ist wichtig, dass die Ausrichtung der 8/64 KiB-Blöcke „durch“ das gesamte Speichersystem durchläuft.
• Das Arbeiten mit tempdb dem Arbeiten mit Datendateien, die Messwerte liegen jedoch normalerweise zwischen 40 und 75%, und die Reaktionsfähigkeit beim Schreiben kann wichtig sein. In modernen MS SQL-Systemen kann diese Datenbank um ein Vielfaches stärker geladen werden als Datendatenbanken. In einer DBMS-Konfiguration ohne Cluster sollte dieser Abschnitt von jeder Speicherreplikation ausgeschlossen werden. Sein Inhalt nach dem Neustart des Dienstes wird weiterhin zerstört.
• Arbeiten Sie mit archivierten Daten / DWH. Die Messwerte liegen nahe bei 100%. Die Größe eines Leseblocks beträgt normalerweise 64 KB. Anfragen werden häufig und hintereinander gelesen, sodass die Warteschlange bis zu 1000 oder mehr umfassen kann.
• Arbeiten Sie mit Transaktionsprotokollen. Das Lesen dient nur der Wartung (Sicherung, Replikation usw.). Die Anwendungsleistung wird nur durch das Schreiben beeinträchtigt. Aufnahme in Blöcken von 0,5-64 KiB. Ohne Warteschlange in einem Thread. Verzögerung ist für Anwendungen von entscheidender Bedeutung.
• Sichern und wiederherstellen. Aus Sicht der Datenbank wird in großen Blöcken gelesen (oft 1 MiB). Es ist wichtig, dass diese Last in einigen Fällen auf den Kanälen / Bussen (sowohl FC als auch Ethernet) und der Leistung von Speicherprozessoren ruhen kann. Das Sichern eines Servers kann die Leistung anderer Server desselben SAN / SHD beeinträchtigen.
• Arbeiten mit Anwendungsdateien: Dies sind Protokolle, Standardablaufverfolgung, Binärdateien usw. Diese Belastung ist selten signifikant und nur zu Beginn des Systems wichtig.

Es gibt andere Arten des Ladens, diese sind jedoch leicht exotisch (z. B. kann ein Repository von Dateien in Form des FileStream-Verzeichnisses in der Datenbank gespeichert sein). Alle diese Arten von Lasten haben unterschiedliche, häufig widersprüchliche Festplattenanforderungen. Wenn sie alle auf einer Partition gestapelt sind, verschlechtern Sie nicht nur die Leistung, sondern es ist auch sehr wichtig, dass Sie nicht mehr verstehen, warum das System langsamer wird, und Sie verlieren auch die Möglichkeit, nur den Teil zu verbessern, der ohne globale Verbesserungen / Upgrades des Speichers verbessert werden muss. Daher die Hauptempfehlung:

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . Das ist richtig. . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***.

Das ist alles. . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .