Delen via

Basislijn verzamelen: Aanbevolen procedures voor prestaties voor SQL Server op Azure VM

  • Artikel

Van toepassing op: SQL Server op Azure VM

In dit artikel vindt u informatie over het verzamelen van een prestatiebasislijn als een reeks aanbevolen procedures en richtlijnen voor het optimaliseren van de prestaties voor uw SQL Server op Azure Virtual Machines (VM's).

Er is doorgaans een afweging tussen optimaliseren voor kosten en optimaliseren voor prestaties. Deze reeks aanbevolen procedures voor prestaties is gericht op het verkrijgen van de beste prestaties voor SQL Server op virtuele Azure-machines. Als uw workload minder veeleisend is, hebt u mogelijk niet elke aanbevolen optimalisatie nodig. Houd rekening met uw prestatiebehoeften, kosten en workloadpatronen wanneer u deze aanbevelingen evalueert.

Overzicht

Voor een prescriptieve benadering verzamelt u prestatiemeteritems met behulp van PerfMon/LogMan en legt u wachtstatistieken van SQL Server vast om algemene druk en mogelijke knelpunten van de bronomgeving beter te begrijpen.

Begin met het verzamelen van de CPU, het geheugen, IOPS, de doorvoer en de latentie van de bronworkload op piekmomenten na de controlelijst voor de prestaties van de toepassing.

Verzamel gegevens tijdens piekuren, zoals workloads tijdens uw gebruikelijke werkdag, maar ook andere processen voor hoge belasting, zoals verwerking van het einde van de dag en etL-workloads in het weekend. Overweeg om uw resources op te schalen voor atypisch zware workloads, zoals de verwerking van het einde van het kwartaal, en schaal deze vervolgens uit zodra de workload is voltooid.

Gebruik de prestatieanalyse om de VM-grootte te selecteren die kan worden geschaald naar de prestatievereisten van uw workload.

Opslag

De prestaties van SQL Server zijn sterk afhankelijk van het I/O-subsysteem en de opslagprestaties worden gemeten door IOPS en doorvoer. Tenzij uw database in het fysieke geheugen past, brengt SQL Server voortdurend databasepagina's binnen en uit de buffergroep. De gegevensbestanden voor SQL Server moeten anders worden behandeld. Toegang tot logboekbestanden is opeenvolgend, behalve wanneer een transactie moet worden teruggedraaid waar gegevensbestanden, inclusief tempdb, willekeurig worden geopend. Als u een traag I/O-subsysteem hebt, kunnen uw gebruikers prestatieproblemen ondervinden, zoals trage reactietijden en taken die niet worden voltooid vanwege time-outs.

De virtuele Azure Marketplace-machines bevatten logboekbestanden op een fysieke schijf die standaard gescheiden is van de gegevensbestanden. Het tempdb aantal gegevensbestanden en de grootte voldoen aan best practices en zijn gericht op het tijdelijke D:\ station.

De volgende Prestatiemeteritems kunnen helpen bij het valideren van de IO-doorvoer die is vereist voor uw SQL Server:

  • \LogicalDisk\Disk Reads/Sec (lees IOPS)
  • \LogicalDisk\Disk Writes/Sec (schrijf-IOPS)
  • \LogicalDisk\Disk Read Bytes/Sec (leesdoorvoervereisten voor de gegevens, logboeken en tempdb bestanden)
  • \LogicalDisk\Disk Write Bytes/Sec (vereisten voor schrijfdoorvoer voor de gegevens, logboeken en tempdb bestanden)

Met behulp van IOPS en doorvoervereisten op piekniveaus evalueert u VM-grootten die overeenkomen met de capaciteit van uw metingen.

Als voor uw workload IOPS en 10.000 IOPS voor lezen is vereist, kunt u kiezen voor E16s_v3 (met maximaal 32.000 IOPS in cache en 25600 IOPS zonder cache) of M16_s (met maximaal 20.000 in cache opgeslagen IOPS en 10.000 niet-in cache opgeslagen IOPS) met 2 P30-schijven die zijn gestreept met Opslagruimten.

Zorg ervoor dat u zowel de doorvoer- als de IOPS-vereisten van de workload begrijpt, omdat VM's verschillende schaallimieten hebben voor IOPS en doorvoer.

Geheugen

Houd zowel extern geheugen bij dat wordt gebruikt door het besturingssysteem als het geheugen dat intern door SQL Server wordt gebruikt. Het identificeren van druk voor een van beide onderdelen helpt bij het bepalen van de grootte van virtuele machines en het identificeren van mogelijkheden voor afstemming.

De volgende Prestatiemeteritems kunnen helpen bij het valideren van de geheugenstatus van een virtuele SQL Server-machine:

Compute

Compute in Azure wordt anders beheerd dan on-premises. On-premises servers zijn gebouwd voor enkele jaren zonder een upgrade vanwege de beheeroverhead en de kosten voor het verkrijgen van nieuwe hardware. Virtualisatie vermindert sommige van deze problemen, maar toepassingen zijn geoptimaliseerd om optimaal te profiteren van de onderliggende hardware, wat betekent dat elke belangrijke wijziging in het resourceverbruik de volledige fysieke omgeving opnieuw moet verdelen.

Dit is geen uitdaging in Azure waarbij een nieuwe virtuele machine op een andere reeks hardware en zelfs in een andere regio eenvoudig te bereiken is.

In Azure wilt u zoveel mogelijk resources voor virtuele machines gebruiken. Daarom moeten virtuele Azure-machines zo hoog mogelijk blijven, zonder dat dit van invloed is op de workload.

De volgende Prestatiemeteritems kunnen helpen bij het valideren van de rekenstatus van een virtuele SQL Server-machine:

  • \Processor Information(_Total)% processortijd
  • \Process(sqlservr)% processortijd

Notitie

Probeer in het ideale geval 80% van uw rekenkracht te gebruiken, met pieken boven de 90% maar niet 100% voor een langdurige periode. In principe wilt u alleen de rekenkracht inrichten die de toepassing nodig heeft en wilt u vervolgens omhoog of omlaag schalen naarmate het bedrijf dat nodig heeft.

Volgende stappen

Zie de andere artikelen in deze reeks aanbevolen procedures voor meer informatie:

Zie Beveiligingsoverwegingen voor SQL Server op virtuele Azure-machines voor aanbevolen beveiligingsprocedures.

Bekijk andere artikelen over virtuele SQL Server-machines in SQL Server op Azure Virtual Machines Overview. Als u vragen hebt over virtuele machines met SQL Server, raadpleegt u Veelgestelde vragen.