1. #21
    Membre averti
    Inscrit en
    juin 2010
    Messages
    456
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 456
    Points : 375
    Points
    375

    Par défaut

    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

  2. #22
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    5 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : août 2005
    Messages : 5 076
    Points : 11 812
    Points
    11 812

    Par défaut

    Hello,

    Citation Envoyé par StringBuilder Voir le message
    Tiens, je viens de voir un truc qui m'étonne.
    En effet, dans le document on compare Windows avec une taille de cluster de 64 Ko (recommandation Microsoft) alors que Linux est avec une taille d'allocation minimum de 512 octets.
    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 Voir le message
    Après, je ne sais pas si Linux sait adapter automatiquement la taille de ses "clusters" en fonction de ce qu'il fait dedans, mais il on part du principe que c'est bien des cluster de 512 octets, ça veut dire qu'on peut faire jusqu'à 128 lectures "physiques" pour lire une page sous Linux là où avec Windows on garanti qu'il n'y en aura qu'une seule.
    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 commande

    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.

  3. #23
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 234
    Points : 5 271
    Points
    5 271
    Billets dans le blog
    1

    Par défaut

    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).
    On ne jouit bien que de ce qu’on partage.

  4. #24
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 983
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 983
    Points : 41 979
    Points
    41 979

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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.
    Oui
    Donc les 64 Ko.
    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...

    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
    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...

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #25
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    5 076
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : août 2005
    Messages : 5 076
    Points : 11 812
    Points
    11 812

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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.
    Microsoft ne recommande rien de tel sur Linux (le coup du cluster NTFS à 64KB sur Windows)

    Citation Envoyé par StringBuilder Voir le message
    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.
    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 Voir le message
    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

    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.

    Citation Envoyé par StringBuilder Voir le message
    - 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.
    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 Voir le message
    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).
    Il suffit d'aller voir les différents bench qui existent sur internet avec différentes tailles de blocs. NTFS n'arrive jamais devant ...

    ++

  6. #26
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    3 234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 3 234
    Points : 5 271
    Points
    5 271
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Non, ça c'est la taille de l'extent... La page fait bien 8 Ko.
    J'avoue que je suis complètement perdu
    Va falloir que je révise un peu ces histoires de pages et extent !

    Citation Envoyé par mikedavem Voir le message
    Il suffit d'aller voir les différents bench qui existent sur internet avec différentes tailles de blocs. NTFS n'arrive jamais devant...
    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.
    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.
    On ne jouit bien que de ce qu’on partage.

Discussions similaires

  1. Réponses: 0
    Dernier message: 17/08/2017, 11h01
  2. SQL server sous windows server 2003(VMWARE)
    Par brahimthebig dans le forum Virtualisation
    Réponses: 4
    Dernier message: 06/05/2011, 14h21
  3. Réponses: 1
    Dernier message: 29/12/2009, 12h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo