SQL Server-Lasttest mit HammerDB

In dieser Anleitung wird beschrieben, wie mit HammerDB Lasttests für eine Google Compute Engine-SQL Server-Instanz durchgeführt werden. In den folgenden Anleitungen erfahren Sie, wie eine SQL Server-Instanz installiert wird:

Es gibt eine Reihe von Tools für Lasttests. Einige sind kostenlos und als Open Source verfügbar, für andere sind Lizenzen erforderlich. HammerDB ist ein Open-Source-Tool, mit dem die Leistung der SQL Server-Datenbank im Allgemeinen gut überprüft werden kann. In dieser Anleitung werden die Standardschritte bei der Verwendung von HammerDB beschrieben. Es gibt aber auch noch andere Tools. Sie sollten jenes Tool auswählen, das Ihrer Arbeitslast am besten gerecht wird.

Zielsetzungen

  • SQL Server für Lasttests konfigurieren
  • HammerDB installieren und ausführen
  • Laufzeitstatistiken erfassen
  • TPC-C-Lasttest ausführen

Kosten

Neben vorhandenen SQL Server-Instanzen, die in Compute Engine ausgeführt werden, werden in dieser Anleitung kostenpflichtige Komponenten der Google Cloud Platform (GCP) verwendet, einschließlich der Folgenden:

  • Google Compute Engine
  • Windows Server

Der Preisrechner kann eine Kostenschätzung basierend auf der voraussichtlichen Nutzung generieren. Der bereitgestellte Link zeigt eine Schätzung der Kosten für die in dieser Anleitung verwendeten Produkte, die sich auf durchschnittlich 16 US$ pro Tag belaufen können. Neuen Nutzern der Cloud Platform steht unter Umständen eine kostenlose Testversion zur Verfügung.

Vorbereitung

  1. Melden Sie sich in Ihrem Google-Konto an.

    Wenn Sie noch kein Konto haben, registrieren Sie sich hier für ein neues Konto.

  2. Wählen Sie ein Google Cloud Platform-Projekt aus oder erstellen Sie eines.

    Zur Seite "Ressourcen verwalten"

  3. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Platform-Projekt aktiviert ist.

    Informationen zum Aktivieren der Abrechnung

  4. Wenn Sie auf Ihrem lokalen Computer nicht Windows verwenden, installieren Sie den RDP-Client eines Drittanbieters, wie etwa Chrome RDP von FusionLabs.

SQL Server-Instanz für Lasttest konfigurieren

Bevor Sie beginnen, müssen Sie prüfen, ob die Windows-Firewallregeln so eingerichtet sind, dass Traffic von der IP-Adresse der neu erstellten Windows-Instanz zugelassen wird. Erstellen Sie dann eine neue Datenbank für den TPCC-Lasttest und konfigurieren Sie wie unten beschrieben ein Nutzerkonto:

  1. Klicken Sie mit der rechten Maustaste auf den Ordner Datenbanken in SQL Server Management Studio und wählen Sie dann Neue Datenbank aus.
  2. Geben Sie "TPCC" als Namen der neuen Datenbank ein.
  3. Legen Sie für die anfängliche Größe der Datendatei 190.000 MB und für die Logdatei 65.000 MB fest.
  4. Erhöhen Sie die Grenzwerte für die Automatische Vergrößerung. Klicken Sie hierzu wie im folgenden Screenshot dargestellt auf die Auslassungspunkte:

    Limits für automatische Vergrößerung festlegen

  5. Legen Sie fest, dass die Datendatei um jeweils 64 MB unbegrenzt vergrößert werden kann.

  6. Deaktivieren Sie die automatische Vergrößerung für die Logdatei.

  7. Klicken Sie auf OK.

    Dialogfeld "Automatische Vergrößerung ändern"

  8. Wählen Sie im Dialogfeld Neue Datenbank im linken Bereich die Seite Optionen aus.

  9. Setzen Sie Kompatibilitätsgrad auf SQL Server 2012 (110).

  10. Setzen Sie das Wiederherstellungsmodell auf Einfach, sodass die Transaktionslogs beim Laden nicht ausgefüllt werden.

    Wiederherstellungsmodell auf "Einfach" setzen

  11. Klicken Sie auf OK, um die TPCC-Datenbank zu erstellen. Dieser Vorgang kann einige Minuten dauern.

  12. Im vorkonfigurierten SQL Server-Image ist nur die Windows-Authentifizierung aktiviert, sodass Sie die Authentifizierung wie in dieser Anleitung (nur auf Englisch verfügbar) beschrieben im gemischten Modus innerhalb von SSMS aktivieren müssen.

  13. Führen Sie diese Schritte aus (nur auf Englisch verfügbar), um auf Ihrem Datenbankserver ein neues SQL Server-Nutzerkonto zu erstellen, das die DBOwner-Berechtigung hat. Geben Sie dem Konto den Namen "loaduser" und weisen Sie ihm ein sicheres Passwort zu.

  14. Notieren Sie sich die interne IP-Adresse des SQL Servers mithilfe des Get-NetIPAddress-Cmdlets. Aus Leistungs- und Sicherheitsgründen muss unbedingt die interne IP-Adresse verwendet werden.

HammerDB installieren

Sie können HammerDB direkt in der SQL Server-Instanz ausführen. Erstellen Sie aber für einen genaueren Test eine neue Windows-Instanz und testen Sie die SQL Server-Instanz per Remotezugriff.

Instanz erstellen

Führen Sie die folgenden Schritte aus, um eine neue Compute Engine-Instanz zu erstellen:

  1. Gehen Sie in der Google Cloud Platform Console zur Seite VM-Instanzen.

    WEITER ZUR SEITE "VM-INSTANZEN"

  2. Setzen Sie Name auf hammerdb-instance.

  3. Geben Sie für Maschinentyp mindestens halb so viele CPUs wie für die Datenbankinstanz an.

  4. Klicken Sie im Abschnitt Bootlaufwerk auf Ändern, um mit der Konfiguration des Bootlaufwerks zu beginnen.

  5. Wählen Sie auf dem Tab Betriebssystemimages die Option Windows Server 2012 R2 aus.

  6. Wählen Sie im Abschnitt Bootlaufwerkstyp die Option Nichtflüchtiger Standardspeicher aus.

  7. Klicken Sie auf Auswählen.

  8. Klicken Sie auf Erstellen.

Software installieren

Stellen Sie mit RDP die Verbindung zur neuen Windows Server-Instanz her und installieren Sie die folgende Software:

HammerDB ausführen

Führen Sie nach der Installation von HammerDB die Datei hammerdb.bat aus. HammerDB wird in der Anwendungsliste des Startmenüs nicht angezeigt. Mit folgendem Befehl führen Sie HammerDB aus:

C:\Program Files\HammerDB-2.20\hammerdb.bat

Verbindung und Schema erstellen

Wenn die Anwendung ausgeführt wird, muss als Erstes die Verbindung konfiguriert werden, um das Schema zu erstellen.

  1. Doppelklicken Sie im Steuerfeld Benchmark auf SQL Server.
  2. Wählen Sie TPC-C aus, ein Akronym für "Transaction Processing Performance Council – Benchmark C". Auf der Website TPC.org steht dazu Folgendes:
    TPC-C umfasst eine Mischung aus fünf gleichzeitigen Transaktionen unterschiedlichen Typs und unterschiedlicher Komplexität, die entweder online ausgeführt werden oder zur verzögerten Ausführung in der Warteschlange stehen. Die Datenbank besteht aus neun Typen von Tabellen mit einem breiten Spektrum an Datensatz- und Populationsgrößen. TPC-C wird in Transaktionen pro Minute (tpmC) gemessen.
  3. Klicken Sie auf OK.

    TPC-C-Benchmark-Optionen festlegen

  4. Klicken Sie im Steuerfeld Benchmark neben SQL Server auf +, um die Optionen einzublenden.

  5. Klicken Sie unter TPC-C auf Schema Build (Schema-Build). Doppelklicken Sie dann auf Options (Optionen).

  6. Füllen Sie das Formular so aus, dass es wie unten dargestellt aussieht. Verwenden Sie dabei Ihre IP-Adresse, Ihren Nutzernamen und Ihr Passwort.

    TPC-C-Build-Optionen festlegen

  7. Wählen Sie Updated (Aktualisiert) für die Option Schema aus. Dadurch wird ein besseres TPC-C-Schema mit einer geeigneteren Struktur und besseren Indexen erstellt.

  8. In diesem Fall ist Number of Warehouses (Anzahl der Warehouses) (die Skalierung) auf 2.000 gesetzt. Sie müssen den Wert jedoch nicht so hoch ansetzen, weil das Erstellen von 2.000 Warehouses mehrere Stunden dauert. Einige Richtlinien empfehlen 10 bis 100 Warehouses pro CPU. Legen Sie im Rahmen dieser Anleitung einen Wert fest, der der Anzahl der Kerne mal 10 entspricht: 160 bei einer Instanz mit 16 Kernen.

  9. Wählen Sie bei Virtual Users to Build Schema (Virtuelle Nutzer zum Erstellen des Schemas) einen Wert aus, der ein- bis zweimal so hoch wie die Anzahl der Client-vCPUs ist. Sie können auf den grauen Balken neben dem Schieberegler klicken, um die Anzahl zu erhöhen.

  10. Klicken Sie auf OK.

  11. Doppelklicken Sie auf die Option Build unter dem Abschnitt Schema Build (Schema-Build), um das Schema zu erstellen und die Tabellen zu laden. Wenn dieser Schritt abgeschlossen ist, klicken Sie auf das rote Blitzlichtsymbol oben in der Mitte des Bildschirms, um den virtuellen Nutzer zu löschen, und gehen Sie zum nächsten Schritt.

Wenn Sie die Datenbank mit dem Wiederherstellungsmodell Simple erstellt haben, können Sie es an dieser Stelle wieder in Full ändern, um ein Produktionsszenario genauer testen zu können. Dies wird erst wirksam, nachdem Sie eine vollständige oder differenzielle Sicherung vorgenommen haben, um das Starten der neuen Logkette auszulösen.

Treiberskript erstellen

HammerDB verwendet das Treiberskript, um den Fluss der SQL-Anweisungen an die Datenbank zu steuern und die erforderliche Last zu generieren.

  1. Blenden Sie im Steuerfeld Benchmark den Abschnitt Driver Script (Treiberskript) ein und doppelklicken Sie auf Options (Optionen).
  2. Prüfen Sie, ob die Einstellungen mit den Angaben im Dialogfeld Schema Build (Schema-Build) übereinstimmen.
  3. Wählen Sie Timed Test Driver Script (Zeitgesteuertes Testtreiberskript) aus.
  4. Die Option Checkpoint when complete (Checkpoint bei Abschluss) zwingt die Datenbank, am Ende des Tests alles auf das Laufwerk zu schreiben. Aktivieren Sie diese Option also nur, wenn Sie mehrere Tests hintereinander ausführen möchten.
  5. Für einen gründlichen Test setzen Sie Minutes of Rampup Time (Minuten zum Hochfahren) unbedingt auf 5 und Minutes for Test Duration (Minuten für die Testdauer) auf 20.
  6. Klicken Sie auf OK, um das Dialogfeld zu schließen.
  7. Doppelklicken Sie im Abschnitt Driver Script (Treiberskript) des Steuerfelds Benchmark auf Load (Last), um das Treiberskript zu aktivieren.

TPC-C-Treiberoptionen festlegen)

Virtuelle Nutzer erstellen

Für eine realistische Last müssen in der Regel Skripts für mehrere unterschiedliche Nutzer ausgeführt werden. Erstellen Sie daher für den Test einige virtuelle Nutzer.

  1. Blenden Sie den Abschnitt Virtual Users (Virtuelle Nutzer) ein und doppelklicken Sie auf Options (Optionen).
  2. Wenn Sie die Warehouse-Anzahl (Skalierung) auf 160 eingestellt haben, setzen Sie Virtual Users (Virtuelle Nutzer) auf 16, denn die TPC-C-Richtlinien empfehlen einen Faktor von 10, um zu verhindern, dass Zeilen gesperrt werden. Klicken Sie das Kästchen Show Output (Ausgabe anzeigen) an, damit Fehlermeldungen in der Konsole angezeigt werden.
  3. Klicken Sie auf OK.

Laufzeitstatistiken erfassen

Das Erfassen detaillierter Laufzeitstatistiken ist bei HammerDB und SQL Server nicht ganz einfach. Auch wenn die Statistiken tief innerhalb von SQL Server verfügbar sind, müssen sie regelmäßig erfasst und berechnet werden. Wenn Sie noch keine Prozedur und kein Tool zur Erfassung dieser Daten haben, können Sie mit der folgenden Prozedur während des Tests einige nützliche Messwerte erfassen. Die Ergebnisse werden in eine CSV-Datei im Windows-Verzeichnis temp geschrieben. Mit der Option Inhalte einfügen > CSV einfügen können Sie die Daten in eine Google-Tabelle kopieren.

Um diese Prozedur zu verwenden, müssen Sie zuerst OLE-Automatisierungsprozeduren vorübergehend aktivieren, um die Datei auf das Laufwerk zu schreiben. Nach dem Testen muss die Option wieder deaktiviert werden:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Ole Automation Procedures', 1;
GO
RECONFIGURE;
GO

Mit dem folgenden Code kann in SQL Server Management Studio die Prozedur sp_write_performance_counters erstellt werden. Bevor Sie den Lasttest starten, führen Sie diese Prozedur in Management Studio aus:

USE [master]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

/***
LogFile path has to be in a directory that SQL Server can Write To.
*/
CREATE PROCEDURE [dbo].[sp_write_performance_counters] @LogFile varchar (2000) = 'C:\\WINDOWS\\TEMP\\sqlPerf.log', @SecondsToRun int =1600, @RunIntervalSeconds int = 2

AS

BEGIN
--File writing variables
DECLARE @OACreate INT, @OAFile INT, @FileName VARCHAR(2000), @RowText VARCHAR(500), @Loops int, @LoopCounter int, @WaitForSeconds varchar (10)
--Variables to save last counter values
DECLARE @LastTPS BIGINT, @LastLRS BIGINT, @LastLTS BIGINT, @LastLWS BIGINT, @LastNDS BIGINT, @LastAWT BIGINT, @LastAWT_Base BIGINT, @LastALWT BIGINT, @LastALWT_Base BIGINT
--Variables to save current counter values
DECLARE @TPS BIGINT, @Active BIGINT, @SCM BIGINT, @LRS BIGINT, @LTS BIGINT, @LWS BIGINT, @NDS BIGINT, @AWT BIGINT, @AWT_Base BIGINT, @ALWT BIGINT, @ALWT_Base BIGINT, @ALWT_DIV BIGINT, @AWT_DIV BIGINT

SELECT @Loops = case when (@SecondsToRun % @RunIntervalSeconds) > 5 then @SecondsToRun / @RunIntervalSeconds + 1 else @SecondsToRun / @RunIntervalSeconds end
SET @LoopCounter = 0
SELECT @WaitForSeconds = CONVERT(varchar, DATEADD(s, @RunIntervalSeconds , 0), 114)
SELECT @FileName = @LogFile + FORMAT ( GETDATE(), '-MM-dd-yyyy_m', 'en-US' ) + '.txt'

--Create the File Handler and Open the File
EXECUTE sp_OACreate 'Scripting.FileSystemObject', @OACreate OUT
EXECUTE sp_OAMethod @OACreate, 'OpenTextFile', @OAFile OUT, @FileName, 2, True, -2

--Write the Header
EXECUTE sp_OAMethod @OAFile, 'WriteLine', NULL,'Transactions/sec, Active Transactions, SQL Cache Memory (KB), Lock Requests/sec, Lock Timeouts/sec, Lock Waits/sec, Number of Deadlocks/sec, Average Wait Time (ms), Average Latch Wait Time (ms)'
--Collect Initial Sample Values
SET ANSI_WARNINGS OFF
SELECT
  @LastTPS= max(case when counter_name = 'Transactions/sec' then cntr_value end),
  @LastLRS = max(case when counter_name = 'Lock Requests/sec' then cntr_value end),
  @LastLTS = max(case when counter_name = 'Lock Timeouts/sec' then cntr_value end),
  @LastLWS = max(case when counter_name = 'Lock Waits/sec' then cntr_value end),
  @LastNDS = max(case when counter_name = 'Number of Deadlocks/sec' then cntr_value end),
  @LastAWT = max(case when counter_name = 'Average Wait Time (ms)' then cntr_value end),
  @LastAWT_Base = max(case when counter_name = 'Average Wait Time base' then cntr_value end),
  @LastALWT = max(case when counter_name = 'Average Latch Wait Time (ms)' then cntr_value end),
  @LastALWT_Base = max(case when counter_name = 'Average Latch Wait Time base' then cntr_value end)
FROM sys.dm_os_performance_counters
WHERE counter_name IN (
'Transactions/sec',
'Lock Requests/sec',
'Lock Timeouts/sec',
'Lock Waits/sec',
'Number of Deadlocks/sec',
'Average Wait Time (ms)',
'Average Wait Time base',
'Average Latch Wait Time (ms)',
'Average Latch Wait Time base') AND instance_name IN( '_Total' ,'')
SET ANSI_WARNINGS ON
WHILE @LoopCounter <= @Loops
BEGIN
WAITFOR DELAY @WaitForSeconds
SET ANSI_WARNINGS OFF
SELECT
  @TPS= max(case when counter_name = 'Transactions/sec' then cntr_value end)   ,
  @Active = max(case when counter_name = 'Active Transactions' then cntr_value end)   ,
  @SCM = max(case when counter_name = 'SQL Cache Memory (KB)' then cntr_value end)   ,
  @LRS = max(case when counter_name = 'Lock Requests/sec' then cntr_value end)   ,
  @LTS = max(case when counter_name = 'Lock Timeouts/sec' then cntr_value end)   ,
  @LWS = max(case when counter_name = 'Lock Waits/sec' then cntr_value end)   ,
  @NDS = max(case when counter_name = 'Number of Deadlocks/sec' then cntr_value end)   ,
  @AWT = max(case when counter_name = 'Average Wait Time (ms)' then cntr_value end)   ,
  @AWT_Base = max(case when counter_name = 'Average Wait Time base' then cntr_value end)   ,
  @ALWT = max(case when counter_name = 'Average Latch Wait Time (ms)' then cntr_value end)   ,
  @ALWT_Base = max(case when counter_name = 'Average Latch Wait Time base' then cntr_value end)
FROM sys.dm_os_performance_counters
WHERE counter_name IN (
'Transactions/sec',
'Active Transactions',
'SQL Cache Memory (KB)',
'Lock Requests/sec',
'Lock Timeouts/sec',
'Lock Waits/sec',
'Number of Deadlocks/sec',
'Average Wait Time (ms)',
'Average Wait Time base',
'Average Latch Wait Time (ms)',
'Average Latch Wait Time base') AND instance_name IN( '_Total' ,'')
SET ANSI_WARNINGS ON

SELECT  @AWT_DIV = case when (@AWT_Base - @LastAWT_Base) > 0 then (@AWT_Base - @LastAWT_Base) else 1 end ,
    @ALWT_DIV = case when (@ALWT_Base - @LastALWT_Base) > 0 then (@ALWT_Base - @LastALWT_Base) else 1 end

SELECT @RowText = '' + convert(varchar, (@TPS - @LastTPS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, @Active) + ', ' +
          convert(varchar, @SCM) + ', ' +
          convert(varchar, (@LRS - @LastLRS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@LTS - @LastLTS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@LWS - @LastLWS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@NDS - @LastNDS)/@RunIntervalSeconds) + ', ' +
          convert(varchar, (@AWT - @LastAWT)/@AWT_DIV) + ', ' +
          convert(varchar, (@ALWT - @LastALWT)/@ALWT_DIV)

SELECT  @LastTPS = @TPS,
    @LastLRS = @LRS,
    @LastLTS = @LTS,
    @LastLWS = @LWS,
    @LastNDS = @NDS,
    @LastAWT = @AWT,
    @LastAWT_Base = @AWT_Base,
    @LastALWT = @ALWT,
    @LastALWT_Base = @ALWT_Base

EXECUTE sp_OAMethod @OAFile, 'WriteLine', Null, @RowText

SET @LoopCounter = @LoopCounter + 1

END

--CLEAN UP
EXECUTE sp_OADestroy @OAFile
EXECUTE sp_OADestroy @OACreate
print 'Completed Logging Performance Metrics to file: ' + @FileName

END

GO

TPC-C-Lasttest ausführen

Führen Sie die Erfassungsprozedur in SQL Server Management mit dem folgenden Skript aus:

Use master
Go
exec dbo.sp_write_performance_counters

Starten Sie den Test auf der Compute Engine-Instanz, auf der Sie HammerDB installiert haben, in der HammerDB-Anwendung:

  1. Doppelklicken Sie im Steuerfeld Benchmark unter Virtual Users (Virtuelle Nutzer) auf Create (Erstellen), um die virtuellen Nutzer zu erstellen. Dadurch wird der Tab Virtual User Output (Virtuelle Nutzerausgabe) aktiviert.
  2. Doppelklicken Sie direkt unter der Option Create (Erstellen) auf Run (Ausführen), um den Test zu starten.
  3. Nach Abschluss des Tests sehen Sie die Berechnung für die Transaktionen pro Minute (TPM) auf dem Tab Virtual User Output (Virtuelle Nutzerausgabe).
  4. Die Ergebnisse der Erfassungsprozedur finden Sie im Verzeichnis c:\Windows\temp.
  5. Speichern Sie diese Werte in einer Google-Tabelle und verwenden Sie sie für den Vergleich mehrerer Testläufe.

Bereinigen

Nachdem Sie die Anleitung für den SQL Server-Lasttest abgeschlossen haben, können Sie die Ressourcen bereinigen, die Sie in der Google Cloud Platform erstellt haben, damit sie Ihnen nicht später in Rechnung gestellt werden. In den folgenden Abschnitten wird beschrieben, wie diese Ressourcen gelöscht oder deaktiviert werden können.

Projekt löschen

Am einfachsten vermeiden Sie unnötige Kosten, wenn Sie das erstellte Projekt löschen.

So löschen Sie das Projekt:

  1. Rufen Sie in der GCP Console die Seite Projekte auf.

    Zur Seite Projekte

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie auf Löschen delete.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

Instanzen löschen

So löschen Sie eine Compute Engine-Instanz:

  1. Wechseln Sie in der GCP Console zur Seite VM-Instanzen.

    Zur Seite "VM-Instanzen"

  2. Klicken Sie auf das Kästchen neben der Instanz, die Sie löschen wollen.
  3. Klicken Sie oben auf der Seite auf Löschen delete, um die Instanz zu löschen.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine