Hardwareoverwegingen voor In-Memory OLTP in SQL Server

In-Memory OLTP gebruikt geheugen en schijf op verschillende manieren dan traditionele schijftabellen. De prestatieverbetering die u ziet met In-Memory OLTP is afhankelijk van de hardware die u gebruikt. In dit artikel bespreken we verschillende algemene hardwareoverwegingen en bieden we algemene richtlijnen voor het gebruik van hardware met In-Memory OLTP.

CPU (Centrale Verwerkings Eenheid)

In-Memory OLTP heeft geen high-endserver nodig om een OLTP-workload met hoge doorvoer te ondersteunen. U wordt aangeraden een middelgrote server met twee CPU-sockets te gebruiken. Vanwege de toegenomen doorvoer die is ingeschakeld door In-Memory OLTP, zijn twee sockets waarschijnlijk voldoende voor uw zakelijke behoeften.

We raden u aan gelijktijdige multithreading (SMT) in te schakelen met In-Memory OLTP. Met sommige OLTP-workloads hebben we prestatieverbeteringen van maximaal 40% gezien bij het gebruik van SMT.

Memory

Alle tabellen die zijn geoptimaliseerd voor geheugen, bevinden zich volledig in het geheugen. Daarom moet u voldoende fysiek geheugen hebben voor de tabellen zelf en om de werkbelasting te ondersteunen die wordt uitgevoerd op de database: hoeveel geheugen u daadwerkelijk nodig hebt, is afhankelijk van de werkbelasting, maar als uitgangspunt hebt u voldoende beschikbaar geheugen nodig voor ongeveer twee keer de gegevensgrootte. U hebt ook voldoende geheugen nodig voor de buffergroep voor het geval de workload ook werkt op traditionele schijftabellen.

Voer de volgende query uit om te bepalen hoeveel geheugen een bepaalde tabel gebruikt die is geoptimaliseerd voor geheugen:

select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;

In de resultaten ziet u het geheugen dat wordt gebruikt voor tabellen die zijn geoptimaliseerd voor geheugen en hun indexen. De tabelgegevens bevatten de gebruikersgegevens en alle oudere rijversies die nog steeds vereist zijn voor het uitvoeren van transacties of die nog niet zijn opgeschoond door het systeem. Het geheugen dat wordt gebruikt door hash-indexen is constant en is niet afhankelijk van het aantal rijen in de tabel.

Het is belangrijk om in gedachten te houden wanneer u In-Memory OLTP gebruikt dat uw hele database niet in het geheugen hoeft te passen. U kunt een multi-Terabyte-database hebben en nog steeds profiteren van In-Memory OLTP, zolang de grootte van uw dynamische gegevens (de tabellen die zijn geoptimaliseerd voor geheugen) niet groter is dan 256 GB. Het maximum aantal controlepuntgegevensbestanden dat SQL Server voor één database kan beheren, is 4000, waarbij elk bestand 128 MB is. Hoewel dit een theoretisch maximum van 512 GB zou opleveren, om te garanderen dat SQL Server controlepuntbestanden kan bijhouden en niet de limiet van 4000 bestanden bereikt, ondersteunen we tot 256 GB. Deze limiet is alleen van toepassing op de tabellen die zijn geoptimaliseerd voor geheugen; er is geen beperking voor de grootte van de traditionele schijftabellen in dezelfde SQL Server-database.

Niet-duurzame, voor geheugen geoptimaliseerde tabellen (NDT's), dat wil zeggen tabellen die met DUURZAAMHEID=SCHEMA_ONLY zijn geoptimaliseerd voor het geheugen, worden niet op schijf bewaard. Hoewel NDT's niet worden beperkt door het aantal controlepuntbestanden, wordt slechts 256 GB ondersteund. De overwegingen voor logboek- en gegevensstations in de rest van dit bericht zijn niet van toepassing op niet-duurzame tabellen, omdat de gegevens alleen in het geheugen aanwezig zijn.

Logboekstation

Logboekrecords met betrekking tot tabellen die zijn geoptimaliseerd voor geheugen, worden samen met de andere SQL Server-logboekrecords naar het databasetransactielogboek geschreven.

Het is altijd belangrijk om het logboekbestand op een schijf met lage latentie te plaatsen, zodat transacties niet te lang hoeven te wachten en contentie bij log-I/O te voorkomen. Uw systeem wordt zo snel uitgevoerd als uw langzaamste onderdeel (Amdahl's wet). U moet ervoor zorgen dat uw I/O-logboekapparaat bij het uitvoeren van In-Memory OLTP geen knelpunt wordt. We raden u aan om een opslagapparaat met lage latentie te gebruiken, ten minste SSD.

Geheugen-geoptimaliseerde tabellen gebruiken minder logbandbreedte dan schijf-gebaseerde tabellen, omdat ze geen indexbewerkingen registreren en geen UNDO records registreren. Dit kan helpen bij het verlichten van I/O-conflicten in logboeken.

Gegevensdrager

Persistentie van tabellen die zijn geoptimaliseerd voor geheugen met behulp van controlepuntbestanden, maakt gebruik van streaming-I/O. Daarom hebben deze bestanden geen schijf met lage latentie of snelle willekeurige I/O nodig. In plaats daarvan zijn de belangrijkste factoren voor deze schijven de snelheid van sequentiële I/O en de bandbreedte van de hostbusadapter (HBA). U hebt dus geen SSD's nodig voor controlepuntbestanden; u kunt ze op high performance spindles (bijvoorbeeld SAS) plaatsen, zolang hun sequentiële I/O-snelheid voldoet aan uw vereisten.

De grootste factor bij het bepalen van de snelheidsvereiste is uw RTO [Recovery Time Objective] bij het opnieuw opstarten van de server. Tijdens het herstellen van de database moeten alle gegevens in de tabellen die zijn geoptimaliseerd voor geheugen, worden gelezen van schijf naar het geheugen. Databaseherstel vindt plaats op de sequentiële leessnelheid van uw I/O-subsysteem; schijf is het knelpunt.

Om te voldoen aan strenge RTO-vereisten, raden we u aan de controlepuntbestanden over meerdere schijven te verspreiden door meerdere containers toe te voegen aan de MEMORY_OPTIMIZED_DATA bestandsgroep. SQL Server ondersteunt parallelle belasting van controlepuntbestanden van meerdere stations. Herstel vindt plaats met de cumulatieve snelheid van de stations.

In termen van schijfcapaciteit raden we u aan om 2 - 3 keer de grootte van de beschikbare tabellen te hebben die zijn geoptimaliseerd voor geheugen.

Verwante inhoud

• Voorbeelddatabase voor In-Memory OLTP