Microsoft SQL Server 2017 plus rapide sous Linux que Windows ? Pas si sûr…

Comparatif sans concession

Frédéric Brouard

Le but de cet article est de comparer les performances de Microsoft SQL Server 2017 sous Linux par rapport à Windows. Il a été élaboré sur des machines physiques strictement identiques pour ôter tout biais lié à l'utilisation de machines virtuelles.

Si vous souhaitez réagir à cet article, un espace vous est proposé sur le forum. N'hésitez pas à partager votre avis. Commentez

- Titre : Microsoft SQL Server 2017 plus rapide sous Linux que Windows ? Pas si sûr…

- Auteur : Frédéric Brouard

- Parution : 4 avril 2018

- Public visé :

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2018 Auteur. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. L'auteur

- II. Machines de test

- II-A. Configuration OS

- III. Installation de SQL Server sous Linux Ubuntu

- IV. Modification de l'installation par défaut

- V. TEST 1 - Page et Extensions

- V-A. CONCLUSIONS

- VI. Test 2 - Spatial

- VI-A. CONCLUSIONS

- VII. Linux plus rapide que Windows ? Oui, mais…

- VIII. Annexe

- Remerciements

I - L'auteur

le blog :
https://blog.developpez.com/sqlpro
le site :
https://sqlpro.developpez.com
L'entreprise :

II - Machines de test

Nos deux serveurs ont les mêmes configurations au niveau hardware :

Hewlett Packard Proliant DL 385 G7

- RAM : 32 Go

- Disques : 8 SAS 300 Go 10 Krpm

- 2 CPU AMD Opteron 6136 soit 2 nœuds NUMA 3 cœurs par nœuds (soit 12 cœurs), cadencés à 2,4 Ghz

Configuration du stockage :

- 2 partitions RAID 1 avec 2 disques

- 1 partition RAID 10 avec 4 disques

Soit 3 volumes.

Figure 1 - nos serveurs HP de tests

II-A - Configuration OS

Pour Windows :

Version 2016 standard 64 bits
File Système NTFS, cluster 64 Ko

- C : 279 Go (RAID 1)

- D : 279 Go (RAID 1)

- E : 558 Go (RAID 10)

NOTA : Windows Defender installé par défaut…

Pour Linux :

Version Ubuntu 16.04.3 LTS.
Montage des volumes :

- /dev/sda : 279,4 Go (RAID1)

- /dev/sdb : 279,4 Go (RAID 1)

- /dev/sdc : 558,7 Go (RAID 10)

Tous formatés de la même façon :

- Unités : sectors of 1 * 512 = 512 octets

- Sector size (logical/physical): 512 bytes / 512 bytes

- I/O size (minimum/optimal): 512 bytes / 512 bytes

File système : ext4

Aucune couche graphique d'installée, ni antivirus.

III - Installation de SQL Server sous Linux Ubuntu

Il n'y a pas d'interface graphique pour installer SQL Server sous Linux. Néanmoins, Microsoft propose une documentation fournie pour ce faire :

https://docs.microsoft.com/fr-fr/sql/linux/sql-server-linux-setup

C'est mon collègue Arian Papillon qui a installé la version Linux de SQL Server. À ce titre, il a édité un petit article intitulé « SQL Server sous Linux pour les NUL(L)S ».

Figure 2 - Arian Papillon, champagne à la main, fête la victoire d'avoir su dompter Linux pour y installer SQL Server 2017 !

Nos deux installations de SQL Server sous Windows et Linux sont strictement identiques.

Figure 3 : caractéristiques des versions de SQL Server sous Windows et Linux

Notez la différence des « builds » :

- Pour Windows : 14.0.1000.169 ;

- Pour Linux : 14.0.3006.16.

Ceci ne devrait avoir aucune importance pour nos tests.

Remarque : il n'est pas possible en l'état actuel de la version Linux de SQL Server de disposer d'instances nommées. Autrement dit, vous ne pouvez installer qu'une instance par défaut pour SQL Server, ce qui limite les possibilités de multiinstance.

IV - Modification de l'installation par défaut

Nous avons modifié les fichiers de la base tempdb (objets temporaires) afin d'être en correspondance avec l'installation sous Windows. En effet, la version Linux ne propose pas de créer autant de fichiers que celle de Windows et ne crée que deux fichiers, l'un pour le journal de transaction, l'autre pour les données.

En d'autres termes, nous avons rajouté sept fichiers de données à la base tempdb. Cette multiplicité de fichiers sert à améliorer le parallélisme d'accès aux différents threads utilisant la base tempdb contenant les objets temporaires.

Figure 4 - configuration du stockage de la base tempdb pour la version 2017 de SQL Server sous Windows

Nous avons aussi fait en sorte que sur les deux serveurs (Linux comme Windows) les fichiers des bases soient stockés sous E pour les données (RAID 1) et D (RAID 10) pour les transactions, ce qui correspond, dans notre installation Linux à :

Figure 5 - Chemin des fichiers des bases par défaut pour SQL Server version Linux

REMARQUE : tous les tests ont été effectués depuis un PC tiers à l'aide de la console SSMS (SQL Server management Studio).

V - TEST 1 - Page et Extensions

Le but de ce test est de voir à quelle vitesse se font les écritures dans une table dont chaque ligne remplit une page.

La base est créée comme ceci :

1. USE master;

2. GO

3. CREATE DATABASE DB_TEST_IO

4. GO

Dans les deux cas, la base est créée avec les caractéristiques suivantes au niveau du stockage :

Figure 6 - configuration du stockage pour la base de tests

Une table est créée de la sorte :

1. USE DB_TEST_IO

2. GO

3. SET NOCOUNT ON;

4. GO

5. CREATE TABLE TIO

6. (TIO_ID INT IDENTITY,

7. TIO_DATA CHAR(8000))

8. GO

9. BACKUP DATABASE DB_TEST_IO

10. TO DISK = 'DB_TEST_IO.bak';

11. GO

Et finalement, on effectue une sauvegarde pour initialiser le journal des transactions.

Le test proprement dit consiste à insérer huit lignes d'un coup et l'on recommence ce test 128 000 fois, soit 1 024 000 pages insérées.

1. --========================================================================--

2. --> ATTENTION : cette partie du test doit être exécutée EN UNE SEULE PHASE

3. --== ======================================================================--

4. SELECT SYSUTCDATETIME() AS DH INTO T;

5. GO

6. INSERT INTO TIO VALUES (''), (''), (''),(''), (''), (''),(''), ('');

7. GO 128000

8. CHECKPOINT ;

9. GO

10. SELECT DATEDIFF(millisecond, DH, SYSUTCDATETIME())

11. FROM T;

12. SELECT CASE "type" WHEN 1 THEN 'TRAN' ELSE 'DATA' END AS "Type",

13. CAST(mf.size/128.0 AS DECIMAL(18,2)) AS File_Size_MB,

14. num_of_reads, num_of_bytes_read, io_stall_read_ms,

15. num_of_writes, num_of_bytes_written, io_stall_write_ms,

16. CAST(fs.io_stall_read_ms/(1.0 + fs.num_of_reads) AS NUMERIC(10,1)) AS avg_read_stall_ms,

17. CAST(fs.io_stall_write_ms/(1.0 + fs.num_of_writes) AS NUMERIC(10,1)) AS avg_write_stall_ms

18. FROM sys.database_files AS mf WITH (NOLOCK)

19. CROSS APPLY sys.dm_io_virtual_file_stats(DB_ID(), file_id) AS fs;

20. --========================================================================--

21. --> FIN DE LA PHASE

22. --========================================================================--

Le test durant environ 20 minutes, nous avons procédé à cinq essais et conservé toutes les mesures.

Les opérations de disque sont alors collectées uniquement pour les fichiers de cette base à l'aide de la dernière requête.

Résultats pour Linux :

Fichier

Lecture

Écritures

Latences moyennes

Type

Size_Mo

Reads

bytes_read

stall_read_ms

Writes

bytes_written

stall_write_ms

avg_read_stall_ms

avg_write_stall_ms

DATA

8008.00

211

11067392

392

9297

8400756736

252474

1.8

27.2

TRAN

9480.00

180

1757184

96

257495

9905119232

1176244

0.5

4.6

DATA

8008.00

217

11468800

330

9286

8400805888

262233

1.5

28.2

TRAN

9480.00

180

1757184

98

257520

9905446912

1169819

0.5

4.5

DATA

8008.00

211

11067392

271

9298

8400764928

259384

1.3

27.9

TRAN

9480.00

180

1757184

124

257490

9905299456

1168945

0.7

4.5

DATA

8008.00

211

11067392

304

9357

8401264640

239911

1.4

25.6

TRAN

9480.00

180

1757184

96

257484

9905221632

1172908

0.5

4.6

DATA

8008.00

211

11067392

346

9282

8400625664

253313

1.6

27.3

TRAN

9480.00

180

1757184

123

257492

9905139712

1173015

0.7

4.6

Moyenne des latences relevées pour LINUX :

Lectures

Écritures

Données

1,34

27,24

Transactions

0,58

4,56

Résultat pour Windows :

Fichier

Lecture

Écritures

Latences moyennes

Type

Size_Mo

Reads

bytes_read

stall_read_ms

Writes

bytes_written

stall_write_ms

avg_read_stall_ms

avg_write_stall_ms

DATA

8008.00

224

12771328

1069

10268

8406908928

300629

4.8

29.3

TRAN

8712.00

168

1700352

67

257528

9122321408

1106818

0.4

4.3

DATA

8008.00

214

11788288

873

10689

8410341376

386398

4.1

36.1

TRAN

8712.00

168

1700352

92

257637

9122304512

1113679

0.5

4.3

DATA

8008.00

223

12427264

830

10469

8408686592

386004

3.7

36.9

TRAN

8712.00

168

1700352

72

257653

9122348544

1118436

0.4

4.3

DATA

8008.00

214

11788288

806

10491

8408670208

404745

3.7

38.6

TRAN

8712.00

168

1700352

74

257618

9122206208

1119310

0.4

4.3

DATA

8008.00

223

12427264

935

11467

8414969856

267804

4.2

23.4

TRAN

8712.00

168

1700352

71

258379

9122649600

1123934

0.4

4.3

DATA

8008.00

223

12427264

1158

10442

8408580096

363042

5.2

34.8

TRAN

8712.00

168

1700352

71

257620

9122288128

1123246

0.4

4.4

Moyenne des latences relevées pour WINDOWS :

Lectures

Écritures

Données

3,34

32,86

Transaction

0,42

4,3

V-A - CONCLUSIONS

Lectures

Écritures

Gains

Linux

Windows

Linux

Windows

Lecture

Écriture

Données

1,34

3,34

27,24

32,86

2,5 x (Linux)

1,2 x (Linux)

Transactions

0,58

0,42

4,56

4,3

1,4 x (Windows)

1,06 x (Windows)

Linux s'en sort mieux pour toutes les opérations dans les fichiers de données et en particulier pour les lectures ou le gain est important (2,5 fois plus rapide que sous Windows). En revanche, Windows s'en sort généralement mieux pour toutes les opérations portant sur le journal de transaction, bien que le gain sur les écritures soit insignifiant.

Le point critique d'une base de données est les écritures sur le journal de transaction qui sont synchronisées à la pose des verrous transactionnels. En effet, tant que les écritures du journal ne sont pas finalisées, les objets invoqués dans la requête sont verrouillés. Il en résulte donc un blocage pour les autres utilisateurs qui doivent attendre. On constate alors que la version Windows de SQL Server s'en sort mieux, mais de peu sur les écritures.

Pour les lectures, du journal, rares en pratique, la différence est peu sensible en faveur de Windows.

Il existe bien une différence importante sur les opérations portant sur le fichier de données. Or les données étant écrites de manière asynchrone (environ toutes les minutes par défaut), ceci est bien moins important que tout ce qui porte sur le journal de transaction. Néanmoins, les lectures sont beaucoup plus rapides et ce point mériterait d'être approfondi avec un test de vidage du cache et lectures physiques.

Notons enfin que les écritures transactionnelles sont plus volumineuses dans la version Linux que dans la version Windows (912 Mo contre 990), ceci expliquant peut-être la différence de vitesse observée.

En conclusion, nous dirons qu'il existe peu de différences au niveau transactionnel, mais avec un petit avantage à Windows tandis qu'au niveau « data » Linux est bien plus rapide, ne serait-ce que pour monter en cache les données.

VI - Test 2 - Spatial

Ce test a pour but d'exécuter des requêtes de calculs utilisant la SQL CLR (machine virtuelle .net intégrée à SQL Server) via l'appel de méthodes spatiales.

Nous avons repris l'ensemble des requêtes de notre benchmark PostGreSQL vs SQL Server pour le spatial dont vous trouverez la description dans l'article intitulé « BENCHMARK SIG : PostGreSQL vs MS SQL Server ».

La méthode de tests est restée la même que dans l'article original : 10 exécutions pour chaque requête, élimination des temps extrêmes (plus court et plus long) moyenne sur les 8 résultats restants.

Les résultats sont les suivants :

Figure 7 - Résultats des tests spatiaux

UCT : temps d'utilisation des processeurs
T : temps intrinsèque de la requête

VI-A - CONCLUSIONS

Dans six requêtes, Linux s'avère plus rapide que Windows. Pour trois requêtes, le gain dépasse 50 %. Globalement, au niveau des temps d'utilisation des processeurs, le gain en faveur de Linux n'est que de 7,5 % ce qui n'est guère significatif. Là aussi, cela mériterait un test plus approfondi.

En revanche, Linux s'avère plus rapide de 40 % dans la restitution des résultats. Ceci n'est pas négligeable.

VII - Linux plus rapide que Windows ? Oui, mais…

S'il semble que la version Linux de SQL Server soit quelque peu plus rapide que sous Windows, il ne faudrait pas oublier certains détails importants susceptibles de remettre en cause ce résultat :

- D'abord, par défaut, Windows active beaucoup de services parfois inutiles. Sur notre OS de test, où nous n'avons effectué aucun réglage particulier, nous comptons 73 services actifs tandis que dans Linux, seuls 33 services sont actifs (voir Annexe).

- Windows Server est installé par défaut avec l'antivirus maison « Windows Defender ». Linux n'a aucun antivirus installé ni activé par défaut (ne serait-ce pas une faille de sécurité ?).

- Notre version de Windows est installée avec une couche graphique par défaut, tandis que Linux n'est accessible que par ligne de commande. Nous aurions pu installer la version « core » de Windows…

Il est probable qu'en désactivant les services inutiles de Windows, en installant un antivirus sur notre OS Linux et en utilisant une version « core » de Windows, les résultats auraient été un peu différents.

C'est pourquoi nous allons continuer nos tests et publierons régulièrement des résultats complémentaires dans les mois qui suivent !

VIII - Annexe

Voici comment nous avons obtenu les listes des services actifs :

Pour Windows, commande : cmd /k net start.

Services activés :

- Agent de stratégie IPsec

- Alimentation

- Appel de procédure distante (RPC)

- Assistance IP

- Assistance NetBIOS sur TCP/IP

- CDPUserSvc_3777bd

- Client de stratégie de groupe

- Client de suivi de lien distribué

- Client DHCP

- Client DNS

- Configuration des services Bureau à distance

- Connaissance des emplacements réseau

- Coordinateur de transactions distribuées

- CoreMessaging

- Découverte SSDP

- Détection matériel noyau

- Enregistreur VSS SQL Server

- Expériences des utilisateurs connectés et télémétrie

- Gestion … distance de Windows (Gestion WSM)

- Gestionnaire de comptes de sécurité

- Gestionnaire de session locale

- Gestionnaire des connexions Windows

- Gestionnaire des utilisateurs

- Gestionnaire d'informations d'identification

- Gestionnaire d'installation de périphérique

- Hôte de synchronisation_3777bd

- Informations d'application

- Infrastructure de gestion Windows

- Isolation de clé CNG

- Journal d'événements Windows

- Lanceur de processus serveur DCOM

- Mappeur de point de terminaison RPC

- Moteur de filtrage de base

- Pare-feu Windows

- Planificateur de tâches

- Plug-and-Play

- Propagation du certificat

- Redirecteur de port du mode utilisateur des services Bureau à distance

- Serveur

- Serveur de modèles de données de vignette

- Service Broker des événements système

- Service Broker pour les connexions réseau

- Service Broker pour les événements horaires

- Service de cache de police Windows

- Service de découverte automatique de Proxy Web pour les services HTTP Windows

- Service de géolocalisation

- Service de journalisation des accès utilisateur

- Service de l'Assistant Compatibilité des programmes

- Service de notification d'événements système

- Service de plateforme des appareils connectés

- Service de profil utilisateur

- Service de stratégie de diagnostic

- Service du système de notifications Push Windows

- Service d'infrastructure des tâches en arrière-plan

- Service d'énumération de périphériques de carte à puce

- Service Interface du magasin réseau

- Service Liste des réseaux

- Service State Repository (StateRepository)

- Service Windows Defender

- Services Bureau à distance

- Services de chiffrement

- Spouleur d'impression

- SQL Full-text Filter Daemon Launcher (SQLWIN17SGAN)

- SQL Server (SQLWIN17SGAN)

- SQL Server Browser

- SQL Server CEIP service (SQLWIN17SGAN)

- SQL Server Integration Services 14.0

- SQL Server Integration Services CEIP service 14.0

- Station de travail

- Système d'événement COM+

- Temps Windows

- Thèmes

- Windows Driver Foundation - Infrastructure de pilote mode-utilisateur

Pour linux : sudo service --status-all.

Services activés :

- [ + ] acpid

- [ + ] apparmor

- [ + ] apport

- [ + ] atd

- [ + ] console-setup

- [ + ] cron

- [ + ] dbus

- [ + ] grub-common

- [ + ] irqbalance

- [ + ] iscsid

- [ + ] keyboard-setup

- [ + ] kmod

- [ + ] lvm2-lvmetad

- [ + ] lvm2-lvmpolld

- [ + ] lxcfs

- [ + ] mdadm

- [ + ] networking

- [ + ] nmbd

- [ + ] ondemand

- [ + ] open-iscsi

- [ + ] procps

- [ + ] rc.local

- [ + ] resolvconf

- [ + ] rsyslog

- [ + ] samba

- [ + ] samba-ad-dc

- [ + ] smbd

- [ + ] ssh

- [ + ] udev

- [ + ] ufw

- [ + ] unattended-upgrades

- [ + ] urandom

- [ + ] winbind

NOTA : nous avons retiré de cette liste les services inactifs ( [ - ] ). Aucun service n'avait le statut [ ? ].

Remerciements

Nous remercions Jérôme Marsaguet pour la mise au gabarit Developpez.com, et F-Leb pour la relecture orthographique.