Discussion :

[hmira]

Bonjour,

J'ai lu d'ici et là, que les partitions systèmes NTFS destinées au stockage des fichiers data et log des base de données SQL Server (.mdf, ndf, ldf , ... ), y compris pour les fichiers des bases de données systèmes SQL Server notamment tempdb, doivent être formatées avec des blocs de 64Ko, et que SQL Server, fonctionnerait mieux avec des blocs de 64K (?).
En effet, par défaut, et généralement, la taille des blocs des partitions NTFS est de 4Ko.
Ils disent que cette recommandation (64Ko) s'applique uniquement aux disques contenant les fichiers de données et journaux de transactions, et qu'elle ne s'applique pas à la partition purement système destinée à Windows. Le lecteur C généralement réservé au système doit être séparé avec une taille de bloc de 4Ko.

Voilà, je voudrais avoir votre avis sur sujet.
Recommandez-vous, voire même appliquez-vous cette pratique consistant à définir des blocs de 64Ko pour les partitions systèmes destinées uniquement aux stockages des fichiers de données et journaux de transactions ?

Merci pour vos conseils avisés.

A+

[SQLpro]

Aujourd'hui cette préconisation de 64 Ko n'est plus très importante.... Pour C, encore moins !

A +

[hmira]

Bonjour SQLPro et Merci pour ta réponse.
Ceci dit, je n'ai pas bien compris les raisons exactes, ou plutôt ce que tu sous-entends par "Aujourd'hui"
Est-ce que cela veut dire que cette préconisation était valable et pertinente à une époque lointaine, et que, aujourd'hui compte tenu de l'évolution de l'architecture interne du noyau SQL Server (?) c'est préco n'est plus d'actualité.
Pour le disque C, tu as raison, généralement le disque C est réservé uniquement au système et il n'est pas opportun de changer la taille par défaut du bloc lors du formatage.

Merci.

A+

[hmira]

Pour Info.
Je viens de trouver également cet article dans le présent site DVP
David Barbarin, (s'il nous écoute ), dans son article, lien ci-dessous, fait aussi allusion à ce sujet et à ce précepte des blocs de 64Ko (?)

Alignement de partitions pour amélioration des performances de MS-SQL Server
http://mikedavem.developpez.com/sqls.../architecture/

A+

[SQLpro]

et à l'époque Windows 2008 !

A +

[hmira]

OK.
Merci SQLPro pour cette réponse.
Donc, à priori, ce serait une évolution du système Windows, qui rend cette préconisation (bloc 64K) sans intérêt majeur.

A+

[SQLpro]

Notamment, mais pas que....

A +

[janlouk]

Et c'est moins important sur le disque LOG si je ne me trompe pas?

Je suis étonné car Christophe (Laporte) en a encore parlé à la préconf des SQL Saturday à Toulouse.

[SQLpro]

Oui.

Il faut de toutes façons une taille de formatage donc 64 privilégie les extents...

A lire : https://blog.purestorage.com/what-is...io-block-size/

A +

[hmira]

Bonjour,

Merci beaucoup SQLPro pour ces précisions complémentaires très intéressantes :

Finalement, j'en conclus les points suivants :

1 - L'impact de cette recommandation n'est pas très important contenu du fonctionnement interne I/O de SQL Server.
Même en définissant, lors du formatage, une taille de boc à 64Ko, la taille des blocs I/O utilisée par SQL Server diffère, et ne sera pas constamment la même. La taille des blocs I/O utilisée par SQL Server dépend de la nature des opérations effectuées (Transaction log write, Check point/Lazywriter, Read-Ahead Scans , Bulk Loads, Backup / Restore, ColumnsStore Read-Ahead, File Initialization , In-Memory OLTP Chek point etc.. ) , tel que expliqué dans le lien que tu nous as indiqué ci-dessus.

2 - On peut toutefois recommander cette pratique (64Ko), même si cela ne signifie pas que SQL Server utilisera toujours une taille de bloc I/O de 64Ko et qu'il choisira d'autres tailles de blocs (plus petites que 64KO voire plus grandes que 64Ko), et ce, en fonction de la nature des opérations à effectuer, comme cela a été brièvement expliqué au point 1 ci-dessus.
64K permet néanmoins de privilégier les I/O sur les "Extents" (soit 8 pages contiguës), ce qui n'est pas complètement dénoué d'intérêt.

Donc, sauf indication contraire, personnellement j'opterais et j'appliquerais désormais cette recommandation de formatage taille des blocs à 64Ko pour les partitions réservées aux fichiers de données ou journaux de transactions SQL Server.

Merci,

A+

[SQLpro]

À une toute petite correction près, je suis entièrement d'accord...
"...ce qui n'est pas complètement dénoué d'intérêt. "
Enlève le haut !!!!

A +

[hmira]

Non ! Je n’enlèverais jamais le haut. Mon éducation stricte de Gentleman, respectueuse des autres ne me le permet pas.
Et si d’aventure, je le ferais, nombre de femmes du présent forum seraient ébranlées, voire même excitées, et cela foutrait le bordel !

Ma langue, enfin je voulais dire mon clavier, a fourché, et au lieu d’écrire « … dénuée d’intérêt » j’ai, par erreur, écrit « … dénouée d’intérêt ». Certains esprits mal placés ont peut-être entendu « … dénudée d’intérêt ».

La prochaine fois, j’utiliserais le terme dépourvue et je dirais « … dépourvue d’intérêt ». Je prendrais ainsi beaucoup moins de risques.

Enfin, nous pouvons dire que nous avons fini par dénouer cette affaire, en affirmant que cette recommandation (64Ko) n’est pas complètement dénuée d’intérêt.

Merci SQLPro pour ton aide,

A+

[mikedavem]

Pour Info.
Je viens de trouver également cet article dans le présent site DVP
David Barbarin, (s'il nous écoute ), dans son article, lien ci-dessous, fait aussi allusion à ce sujet et à ce précepte des blocs de 64Ko (?)

J'écoute

La recommandation Microsoft est toujours d'actualité pour les dernières version de Windows (2008, 2012 et 2016) si l'on continue à utiliser NTFS.
Depuis Windows 2012, il existe aussi un autre système de fichiers qui est ReFS avec visiblement une base NTFS et beaucoup d'améliorations. Néanmois je l'exclue de cette discussion car pas assez familier avec pour le moment. J'ajouterai juste mes commentaires aux points suivants (bien que la discussion soit clôturée):

1 - L'impact de cette recommandation n'est pas très important contenu du fonctionnement interne I/O de SQL Server.
Même en définissant, lors du formatage, une taille de boc à 64Ko, la taille des blocs I/O utilisée par SQL Server diffère, et ne sera pas constamment la même.

La taille de cluster (ou ALLOCATION_UNIT_SIZE) n'a pas de rapport direct avec les I/O effectués par une application (comme SQL Server= lorsqu'il s'agit de performance. La taille de cluster affecte uniquement la taille de la MFT qui permet de connaitre où blocs de fichiers se trouvent sur disque ainsi que la taille du bitmap qui surveille l'espace libre.

Cependant on commence à voir la différence dans des situations où le FS est vraiment fragmenté ou lorsque l'applicatif procède à de nombreuses opérations d'ajout suppression d'espace (ce qui peut être le cas de SQL Server). Dans le 2ème cas, il faut mettre à jour les métadonnées dans la MFT et la taille de cluster peut faire la différence (Grosse taille de cluster = moins d'I/O pour la mise à jour).

Je pense que la bonne pratique des 64KB vient de là. SQL Server travaille avec des extensions (64K) et aligner la taille de cluster peut avoir du sens ici. Mais cela n'empêchera pas SQL Server de faire des I/O variant de 8K à plus en fonction des opérations à effectuer . Les 2 ne sont pas directement corrélés.

Pour finir en aparté, on voit que sur Linux il n'y a pas une telle recommandation car les FS fonctionnement différement (EXTx, XFS ...). D'ailleurs et sauf erreur de m part, seul XFS permet d'allouer une taille d'extension à 64K mais la gestion des pages au niveau Kernel est limité à 4KB pour le moment.

Un exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
mkfs.xfs -f -b size=65536 /dev/sda1
mkfs.xfs -f -b size=8192 /dev/sda1
mount: mount /dev/sda1 on /u100 failed: Function not implemented

++

[hmira]

Merci beaucoup David Barbarin (mikedavem) pour ces précisions complémentaires très détaillées et très intéressantes.
Cela nous aide à mieux comprendre les mécanismes internes et les raisons exactes d'une telle recommandation.

Encore une fois Merci,

A+