Performance virtualisierter MSSQL-Server

[_Holger_]

Hallo zusammen,

das Virtualisieren eines SQL-Servers wird ja sehr unterschiedlich diskutiert. Das Ergebnis ist (so scheint mir), dass es durchaus auch für Produktivsysteme denkbar ist und nur kleine Leistungseinbußen auftreten. Das Problem ist, dass es scheinbar keine objektiven Messkriterien für die Geschwindigkeit gibt.

Meine Vergleiche haben ergeben, der virtuelle SQL-Server ist um mindestens Faktor 3 (!!!) langsamer als ein gut ausgestatteter Arbeitsplatzrechner.

Das kann doch nicht sein, oder?

Hier die Maschinendaten:

Dell PowerEdge 2900 mit 2x Intel Xenon X5355 mit 2,66 GHz = 8 Prozessorcores, 24 GB RAM, IBM SAN per Fibre Channel , ESX V4.0.0 und keine andere virt. Maschine aktiv

Virt. Maschine: 4 Kerne, 6 GB RAM, Virtuelle Festplatten per LSI Logic Parallel
Windows 2008 64Bit, MSSQL 2008 64Bit

Anliegendes SQL-Skript läuft dort etwa 1,5 Minuten (Dauer: 86800 ms)
30 Sekunden erreicht ein gut ausgestatteter Arbeitsplatzrechner ohne jegliche Optimierung.

Also ist dies das Aus für die Virtualisierung eines MSSQL-Servers, oder muss man hierzu erst an einigen „Schrauben“ drehen? Würde ich ja gerne tun, aber welche...

Danke für Feedback und möglicherweise auch Vergleichswerte von euren Maschinen.

Gruß

Holger

Hier das SQL-Skript:

set nocount on;
go
if (exists(select * from master..sysdatabases where name = 'test'))
begin
use master
drop database test;
end
go
create database test
go
use test
go
create table testtable (lfdnr int not null, field1 varchar(255), field2 text, field3 money);
go
alter table testtable add constraint PK_Testtable_Reckey primary key clustered (lfdnr)
go
declare @strFiles varchar(8000);
declare @strName sysname;
set @strFiles = '';
declare csr cursor for
select filename from sysfiles
open csr
fetch next from csr into @strName
while (@@fetch_status <> -1)
begin
if (@@fetch_status <> -2)
begin
set @strFiles = @strFiles + @strName + ' '
end
fetch next from csr into @strName
end
close csr
deallocate csr

declare @starttime datetime;
declare @i int;
declare @j int;
set @starttime = getdate();
set @i = 1;
while @i<=20
begin
set @j = 1;
while @j<=5000
begin
insert into testtable (lfdnr, field1, field2, field3) values (@j, 'testtesttest',

'testtesttest', @j * 2);
set @j=@j+1;
end
select count(*) as count into newtable from testtable;
drop table newtable;
delete from testtable;
set @i=@i+1;
end
print 'SQL-Server: ' + @@servername
print 'MachineName: ' + convert(varchar, serverproperty ('machinename'))
print 'Product: ' + convert(varchar, serverproperty ('ProductVersion')) + ' ' + convert(varchar,

serverproperty ('ProductLevel'))
print 'Edition: ' + convert(varchar, serverproperty ('edition'))
print 'Data Files: ' + @strFiles
print ''
print 'Dauer: ' + convert(varchar, datediff(ms, @starttime, getdate())) + ' ms'
print ''
print 'Verarbeitung beendet'
go
use master
go
drop database test;
go

[_Holger_]

Sorry, hatte die Daten der Festplattenmessung per H2benchw vergessen:

Kapazität: CHS=(3658/255/63), 58765770 Sektoren = 28694 MByte

Interface-Transferrate mit Blockgröße 128 Sektoren bei 0.0% der Kapazität:
Sequenzielle Leserate Medium (ungebremst): 140934 KByte/s
Sequenzielle Leserate Read-Ahead (Verzögerung: 0.50 ms): 159465 KByte/s
Wiederholtes sequenzielles Lesen ("Coretest"): 161728 KByte/s

Dauertransferrate (Blockgröße: 128 Sektoren):
Lesen: Mittel 138673.6, Min 88334.0, Max 180826.5 [KByte/s]

Zugriffszeit Lesen: Mittel 3.66, Min 0.17, Max 42.30 [ms]
Zugriffszeit Lesen (<504 MByte): Mittel 3.04, Min 0.32, Max 54.76 [ms]

Anwendungsprofil `Swappen': 17287.5 KByte/s
Anwendungsprofil `Installieren': 32827.0 KByte/s
Anwendungsprofil `Word': 68890.8 KByte/s
Anwendungsprofil `Photoshop': 45397.4 KByte/s
Anwendungsprofil `Kopieren': 153638.3 KByte/s
Anwendungsprofil `F-Prot': 15488.8 KByte/s
Gesamtergebnis: Anwendungsindex = 39.3


Timerauflösung: 0.279 µs, 3.580 MHz
Timerstatistik: 147258525 Aufrufe, min 0.00 µs, mittel 7488.93 µs, max 1284007.60 µs
Testbeginn: 02.09.10 17:41:43
Testversion: $Id: h2bench.c 6 2009-05-04 12:51:13Z bo $/Win32

[irix]

Also meine PowerEdge 2900 mit 2x XEON DC 5150@2.66Mhz braucht fuer dein Script

Code: Alles auswählen

SQL-Server: CHALCEDON
MachineName: CHALCEDON
Product: 10.50.1600.1 RTM
Edition: Standard Edition (64-bit)
Data Files: E:\MSSQL\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\test.mdf E:\MSSQL\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\test_log.LDF
 
Dauer: 28550 ms
 
Verarbeitung beendet

Die VM hat eine CPU und 4GB memory und es ist ein vSphere 4.0u2.

1. Performancesteigerung ist nicht das primaere Ziel von virtualisierung. Ob es schnell genug ist haengt davon ab ob deine 86 Sek. fuer dich akzeptabel sind und nicht ob ein anderes System das schneller hinbekommt.
2. Was passiert wenn die vDISK mit der DB auf einem lokalem Datastore liegt und nicht im SAN?

Gruss
Joerg

[irix]

Dein SQL Script macht doch hauptsaechlich INSERTS und somit Writes. Was genau bringt dann ein Benchmark welcher Sequentielle Reads macht?

Gruss
Joerg

[omicronont]

Hallo,

Host: Intel XEON E5520@2.66

ergibt:

Code: Alles auswählen

Product: 10.0.2531.0 SP1
Edition: Standard Edition (64-bit)
[..]
Dauer: 61220 ms


1 vCPU, 8 GB RAM

Gerade beim SQL-Server ist es zwar interessant, was ein einzelnes T-SQL-Script an Last erzeugt - aber wirklich wichtig ist ja, wie sich der Server verhält, wenn viele Benutzer darauf zugreifen. Dann wird Deine Plattenstrecke ganz anders gefordert, und die Verteilung der Datenbank-Dateien über viele Spindeln zahlt sich dann aus.

Davon abgesehen: Die Mehrzahl der Zugriffe auf eine SQL-Datenbank sind ja lesend. Insofern ist es fraglich, ob Dein Benchmark das abbildet.

Schaue auch mal hier: http://vmware-forum.de/viewtopic.php?p=87761.

Wenn es Dir eine Hilfe ist: 100 User, die mit unterschiedlichen Applikationen auf mehrere Datenbanken zugreifen, werden bei uns problemlos vom virtualisierten SQL-Server bedient.

Gruß,

Knut

[_Holger_]

Guten Morgen,

dieser Test beschreibt ganz gut unser Szenario. Es werden viele Daten angelegt und das dauert ewig. Lesezugriffe sind nur vereinzelt und die Geschwindigkeit ist erträglich.

Folgendes habe ich mal verändert:

Umstellen auf eine CPU: 78753 ms
(seltsam, eine ist schneller als 4)

Verlagerung der Datenplatte aus dem SAN auf das lokale RAID: 25330 ms
(das SAN war wohl ursächlich...)

Eigenartig, es sollte viel schneller sein als die lokalen Platten.

Ich finde den Test gut, hiermit lassen sich schnell und einfach Leistungsdaten vergleichen.

Danke an alle für ihre Ergebnisse. Jetzt sehe ich, dass ich mit nunmehr 25 Sekunden ganz gut liege.

Viele Grüße

Holger

[irix]

Guten Morgen,

dieser Test beschreibt ganz gut unser Szenario. Es werden viele Daten angelegt und das dauert ewig. Lesezugriffe sind nur vereinzelt und die Geschwindigkeit ist erträglich.

Folgendes habe ich mal verändert:

Umstellen auf eine CPU: 78753 ms
(seltsam, eine ist schneller als 4)

Warum verwunderlich? Deine Anwendung war hier nicht CPU Bound, dass heist meine eine CPU hatte noch Luft. Somit bringen weitere CPUs nichts und das Gegenteil tritt ein da der Verwaltungsoverhead sich bemerkbar macht.

Verlagerung der Datenplatte aus dem SAN auf das lokale RAID: 25330 ms
(das SAN war wohl ursächlich...)

Eigenartig, es sollte viel schneller sein als die lokalen Platten.

Von aussen ist immer Schlecht zu sehen was dein SAN gerade noch alles macht bzw. im schlimmsten Fall ist die LUN auf einer RAID Gruppe welche nicht die Anforderungen fuer schnelles Schreiben mit der Bockgroesse welche nun gerade deine Anwendung benutzt geeignet.

Ich finde den Test gut, hiermit lassen sich schnell und einfach Leistungsdaten vergleichen.

Natuerlich ist der Test gut, weil er auf die Anwendung bezogen ist und fuer uns leicht anwendbar war. Meine Aussage bezog sich alleine auf H2benchw welche eine andere Hauptcharakteristik verwendete (READ).

Gruss
Joerg