Considérations relatives aux performances pour NTFS transactionnel

Ntfs transactionnel (TxF) a été soigneusement conçu pour les performances et fonctionnera généralement mieux que les alternatives transactionnelles à usage général dans des scénarios similaires. Toutefois, les transactions de système de fichiers ont plus de surcharge que les opérations non traitées, et certaines réductions des performances d’E/S par rapport aux E/S non traitées doivent être attendues. Les applications critiques en matière de performances doivent effectuer un cycle de qualification d’adoption de la technologie, en évaluant l’impact sur les performances des opérations de système de fichiers traitées.

Vue d’ensemble des opérations TxF

TxF utilise annuler journalisation pour enregistrer les modifications nécessaires pour remettre le système de fichiers dans un état cohérent, également appelé restauration, si une transaction est abandonnée. Cette journalisation d’annulation génère des E/S supplémentaires et est la source de la surcharge de performances TxF par rapport aux opérations de système de fichiers non transactionnelles.

Voici un résumé de haut niveau du fonctionnement de TxF :

• À mesure qu’une transaction progresse, TxF écrit annuler enregistrements dans son fichier journal pour chaque modification apportée au système de fichiers. Si un abandon se produit, ces enregistrements d’annulation sont analysés pour remettre le système de fichiers dans l’état où la transaction a commencé.
• Une modification des métadonnées 'enregistrement d’annulation décrit une modification uniquement des métadonnées du système de fichiers. Voici quelques exemples de déplacement, de renommages, d’ajouts et de modifications d’attribut. Pour les enregistrements d’annulation des métadonnées, toutes les informations nécessaires pour annuler la modification se trouve dans l’enregistrement et stockées dans le fichier journal.
• Un remplacer'enregistrement d’annulation décrit un remplacement d’une partie d’un fichier. Lorsqu’un remplacement de fichier se produit, le contenu d’origine du fichier est stocké dans un fichier d’annulation spécial dans un répertoire masqué et l’enregistrement d’annulation de remplacement pointe vers ce fichier. Lorsque les mises à jour de fichiers sont finalement vidées du cache vers le disque, le contenu du fichier d’annulation doit également être vidé. Par conséquent, un remplacement de fichier traité peut générer jusqu’à deux opérations d’E/S aléatoires supplémentaires : une pour lire les anciennes données et l’autre pour l’écrire dans le fichier d’annulation. Ces opérations d’E/S supplémentaires sont un coût de performances de TxF.
• Lorsqu’une validation se produit, TxF vide d’abord toutes les informations d’annulation, vide les modifications réelles du fichier, puis écrit et vide un enregistrement de validation. S’il n’existe aucun fichier d’annulation à vider, la seule surcharge TxF supplémentaire relative aux E/S non traitées est le vidage des journaux eux-mêmes. Toutefois, les vidages de journal entraînent des écritures séquentielles volumineuses efficaces afin que le coût des performances soit minimal.
• TxF est optimisé pour la validation. Il est prévu que la plupart des transactions réussissent et n’ont pas besoin de restaurer, par conséquent, tous les enregistrements d’annulation d’une transaction sont censés être inutilisés. Du point de vue des performances, les opérations de validation TxF sont rapides et les restaurations sont gourmandes en ressources.
• La restauration est plus intensive que la validation. Pendant la restauration, toutes les modifications qui ont été apportées dans la transaction doivent être non effectuées. En règle générale, la durée de restauration peut être approximativement la même que celle nécessaire pour apporter initialement les modifications. Par exemple, s’il a fallu 1 seconde pour apporter toutes les modifications, il pourrait prendre environ 1 seconde pour les annuler. Pour les transactions très longues, la restauration peut créer des impacts supplémentaires sur les performances. Par exemple, l’heure de démarrage du système peut être retardée si le système doit restaurer automatiquement une transaction si le système cesse de répondre et doit effectuer un redémarrage non planifié.

Les conclusions récapitulatives sur les performances qui peuvent être tirées de la liste précédente sont les suivantes :

• Le coût des performances de TxF pour les transactions impliquant des remplacements de fichiers peut être significatif.
• Le coût des performances de TxF pour les transactions impliquant uniquement des opérations de métadonnées peut être relativement faible, à condition que les transactions volumineuses soient utilisées. Une transaction volumineuse est lorsqu’il existe de nombreux enregistrements d’annulation pour chaque enregistrement de validation.

Recommandations pour des performances optimales

Amortir la surcharge TxF sur les transactions plus volumineuses. Par exemple, si vous avez n ensembles de modifications pour apporter des modifications où chaque modification a étapes M et que vous avez la possibilité de procéder comme N transactions de M étapes chacune ou de le faire en tant que transaction unique avec M*N étapes, cette dernière option serait plus efficace.

Tenez compte de l’impact possible sur le démarrage de transactions très volumineuses. Comme indiqué précédemment, la restauration peut être lente et retardera le temps de démarrage si le système doit effectuer des restaurations automatiques comme heure de démarrage. Plus la transaction est grande, plus le délai est long.

Conservez les transactions à la plupart des opérations de métadonnées. C’est ce que TxF est optimisé et, en général, les performances sont identiques aux E/S de fichiers non transactionnés pour les transactions de métadonnées volumineuses. Les fonctions TxF de métadonnées efficaces sont MoveFileTransacted, SetFileAttributesTransacted, CopyFileTransacted, DeleteFileTransacted, CreateHardLinkTransacted, et les écritures ajoutées (appels à la fonction WriteFile lorsque le pointeur de fichier à la fin du fichier, ou EOF). Un exemple d’opérations sans métadonnées nécessitant beaucoup de ressources est l’appel à la fonction WriteFile lorsque le pointeur de fichier n’est pas au niveau de l’EOF.

Résumé des attentes en matière de performances TxF

Pour les mises à jour sur place, les remplacements dans une section d’un fichier seront beaucoup plus lents que les E/S de fichiers non traités, tandis que les performances TxF pour les opérations de métadonnées du système de fichiers (par exemple, créer, déplacer et ajouter) sont comparables aux E/S de fichiers non traitées pour les transactions volumineuses.