Oui tu as forcément des cluster sur un disque magnétique, sur SSD non enfin ce sont des cellules enfin bref et le systeme de mba etc. est le même ce sont des standards
Version imprimable
Oui tu as forcément des cluster sur un disque magnétique, sur SSD non enfin ce sont des cellules enfin bref et le systeme de mba etc. est le même ce sont des standards
Hello,
Je pense qu'il faut comparer ce qui est comparable ici. Les 512 octets correspondent en fait à une taille de secteur disque et 64KB correspondent à une taille d'unité d'allocation (qui correspond à la taille de cluster) au niveau FS et qui couvrent N secteurs disques (dans le cas Windows 64KB = 128 secteurs de disque). Sur les disques modernes on parle souvent de taille de secteurs à 4KB qui permettent de fiabiliser la détection d'erreurs principalement.Citation:
Envoyé par StringBuilder
Que ce soit Windows ou Linux cela ne change pas grand car on parle de secteurs physiques de disques au final. Sur linux au niveau partition on va plutôt parler de taille de block (juste un changement de vocabulaire) qui correspond par défaut à 4KB et on peut monter jusqu'à 64KB. Cependant il faut juste savoir que la seule taille de page système au niveau supportée pour le moment est 4KB (si on décide de monter le FS en question). Il suffit de voir le résultat de la commandeCitation:
Envoyé par StringBuilder
Après des différences existent au niveau des algorithmes de placement / vérification des block / allocation de blocks différés etc ... sous Linux et qui sont reconnus pour être meilleurs que pour NTFS au niveau de la performance.Code:getconf PAGESIZE
Cela ne change rien au fait que SQL Server travaille avec des pages de 64 Ko, et que Microsoft recommande d'utiliser une taille de cluster de 64 Ko pour stocker les fichiers de données.
En effet, si je modifie un octet dans une page, SQL Server va demander au système de mettre à jour toute la page.
Donc les 64 Ko.
Si j'ai une taille de cluster de 4 Ko, je risque :
- D'avoir des pages fragmentées réparties dans jusqu'à 16 blocs différents
- D'avoir des lectures/écritures concurrentes qui viennent interrompre la mise à jour des 16 blocs, et ainsi prolonger inutilement la durée de la modification
Sur un disque magnétique en tout cas, la différence de performances est flagrante.
Je me pose simplement la question avec un disque SSD : a priori la fragmentation ne va pas poser de souci majeur. Mais le faire de faire 16 écritures "physiques" au lieu de 1 seule par page, à mon avis ça augmente le risque d'avoir des lectures/écritures qui se concurrencent inutilement.
Que Linux gère mieux ou moins bien les accès disques n'est pas le fond du problème : si le bench travaille avec des cluster de moins de 64 Ko, on est clairement dans des conditions potentiellement dégradées (d'autant que le bench se fait avec des disques magnétiques, donc très sensibles à la fragmentation).
OuiCitation:
Envoyé par StringBuilder
Non, ça c'est la taille de l'extent... La page fait bien 8 Ko. Mais tu ne met jamais un seul octet à jour... En effet, si tu as activé le CHECKSUM (recommandé) alors il y aura recalcul de la somme de contrôle ce qui change d'autres octets. Si tu as mis en place le versionnement via le mode d'isolation snapshot, tu aura modification du tag de version pour ce slot de ligne, si l'octet mis à jour augmente la taile d'une données dimensionnée en VAR... il y aura modification de la taille dans le tableau des longueurs...Citation:
Donc les 64 Ko.
Les extents sont des blocs de 8 pages TOUJOURS contiguës. Si le cluster fait 4 Ko, l'extent sera créé sur 16 cluster de 4 ko contigües. Il n'y a jamais de fragmentation physique ni des pages, ni des extents...Citation:
Si j'ai une taille de cluster de 4 Ko, je risque :
- D'avoir des pages fragmentées réparties dans jusqu'à 16 blocs différents
- D'avoir des lectures/écritures concurrentes qui viennent interrompre la mise à jour des 16 blocs, et ainsi prolonger inutilement la durée de la modification
Citation:
Sur un disque magnétique en tout cas, la différence de performances est flagrante.
Je me pose simplement la question avec un disque SSD : a priori la fragmentation ne va pas poser de souci majeur. Mais le faire de faire 16 écritures "physiques" au lieu de 1 seule par page, à mon avis ça augmente le risque d'avoir des lectures/écritures qui se concurrencent inutilement.
Que Linux gère mieux ou moins bien les accès disques n'est pas le fond du problème : si le bench travaille avec des cluster de moins de 64 Ko, on est clairement dans des conditions potentiellement dégradées (d'autant que le bench se fait avec des disques magnétiques, donc très sensibles à la fragmentation).
Sur un disque SSD, dans certains cas, mieux vaut la fragmentation !!!!
A +
Microsoft ne recommande rien de tel sur Linux (le coup du cluster NTFS à 64KB sur Windows)Citation:
Envoyé par StringBuilder
SQL Server ne modifiera que la page en question donc 8KB sur les 64KB de l'extension où elle est stockée.Citation:
Envoyé par StringBuilder
Citation:
Envoyé par StringBuilder
Le coup de la fragmentation est beaucoup plus valable avec NTFS sur Windows que d'un FS sous Linux comme EXT4 ou XFS par exemple.
La lecture / écriture des pages se fait toujours en mémoire et pas sur disque. Lors d'une écriture SQL Server modifie des pages de 8KB (à noter que la taille d'une page en mémoire est de 4KB sur Windows également à moins d'utiliser les Large Pages) et va écriture de manière asynchrone ces pages de 8K rassemblées dans des blocs contigus pour optimiser les écritures séquentielles (les fameux I/O vectorisées avec les méthodes Scatter/Gather). Donc s'il y a concurrence d'accès ca sera au niveau mémoire pas au niveau disque.Citation:
Envoyé par StringBuilder
Il suffit d'aller voir les différents bench qui existent sur internet avec différentes tailles de blocs. NTFS n'arrive jamais devant ...Citation:
Envoyé par StringBuilder
++
J'avoue que je suis complètement perdu :DCitation:
Envoyé par SQLpro
Va falloir que je révise un peu ces histoires de pages et extent !
Ca j'ai jamais dis le contraire : j'ai juste pensé que le bench ne se faisait pas dans les conditions les plus favorables sous Linux. Visiblement j'étais dans le faux.Citation:
Envoyé par mikedavem
Après, Linux ou Windows plus rapide/plus lent, c'est autre chose.
Juste que je pensais que d'un côté on chargeait une brouette de sable avec une pelle et de l'autre avec une paire de baquettes chinoises. Apparemment non.
Bonjour,
je ne comprend pas le choix du FS EXT4 et pas un truc plus sympa genre ZFS ... qui me parait plus puissant et plus souple.
Stéphane
Je dirais pour cette raison :
https://docs.microsoft.com/fr-fr/sql...ql-server-2017
Citation:
Quels systèmes de fichiers Linux SQL Server peut-il utiliser comme fichiers de données ?
SQL Server sur Linux prend en charge ext4 et XFS. Prise en charge d’autres systèmes de fichiers est ajouté en fonction des besoins à l’avenir.
Je pense que cela est surtout du aux recommandations des distros Linux pour les bases de données.
SLE / RHEL recommandent d'utiliser XFS pour les bases de données (meilleurs performance IO).
++
Merci pour ce retour qui m'intrigue aussi.Citation:
Envoyé par StringBuilder
Avant tout il manquerait quelques éléments pour mieux appréhender le problème
- Vitesse des disques : https://gallery.technet.microsoft.co...orage-6ef84e62
- Qualité de la RAM
- Qualité des CPU
Ce n'est pas que les mesures nous éclaireront vraiment sur le fait qu'il y ait plus ou moins d'activité disque mais ça évitera de supputer dans le vague.
De même il est IMPORTANT de valider que les instances soient effectivement configurées de la même manière.
Ce que je relève est :
- la forte variabilité des lecture (quantité et volume) alors qu'il n'y pas de stress mémoire attendu.
- La faible variabilité des écritures
je partirais sur une analyse différentielle de l'évolution des compteurs mémoire pendant (un peu avant et un peu après le test c'est mieux ;) )
voir ici : https://solutioncenter.apexsql.com/t...sure-counters/
Comme ça on dirait que les pages non dirty ont été recyclées prématurément.
Il serait je pense intéressant de refaire le test avec un Windows en mode Core. Ca pourrait peut-être faire des gains en faveur de Windows.