[François Jehl] : Montée en charge, quelques conseils.

Dans son billet [SSIS] Montée en charge, quelques conseils. François, nous propose quelques très bon conseils d'optimisation des packages SSIS.

Pour une fois qu'il ne parle pas de Data Mining (quelqu'un comprend ce qu'il raconte au moins sur le DMX), je vais me permettre d'intervenir/compléter sur un point. J'espère que ca ne te dérange pas François.

François à dit :

... SSIS est optimisé en mémoire donc à vous de l'économiser! Déjà, sélectionnez uniquement les colonnes utiles...

Dans les Data Flow Sources, il est effectivement conseillé de ne sélectionner que les colonnes qui seront effectivement utilisées par la suite. Cependant, dans la suite de votre flux de données, certaines transformations (ex : Derived Column, Data Conversion etc...) vont dupliquer les colonnes les premières ne servant vraisemblablement plus.

Une solution souvent mise en place afin d'enlever les colonnes inutiles, est d'utiliser la tache Union All. En supprimant les Output Column inutiles, on pense réduire à juste titre la mémoire utilisée. La pire solution, serait d'utiliser des taches synchrones aggregate ou sort pour supprimer ces mêmes colonnes.

Mais alors si je conviens que cela réduit bel et bien l'utilisation de la mémoire, pourquoi n'est tout de même pas une bonne idée? Tout simplement de par le fait que supprimer une colonne induit la copie des buffers du pipeline vers de nouveaux buffers. Et malheureusement l'expérience prouve que cette action de copie est bien trop couteuse en terme de cycle CPU pour contrebalancer la réduction de la mémoire utilisée.

Darren Green - 10 Mai 2007 à dit :

Something that people, including me get a bit worried about, is the fact that you end up with these big wide buffers. The classic scenario is when you need to convert between string and Unicode string or visa versa. You end up duplicating all your columns, which seems really horrid. Well it may not be great, but the alternative is even worse. Data Conversion and Derived Column transforms can do the conversion, but are synchronous, so we have duplicate columns in effect. Would it be better to have a custom component that worked asynchronously, so you didn't end up with two columns for all your strings? The short answer is no. I wrote a test component, cunningly named DeUnicodeAsynchTestComponent, and simply put it was 2 - 2.5 times slower than a data conversion transform. The cost of copying data between buffers for the asynchronous nature is far more expensive than the extra baggage of the "duplicate" columns.

Voila François, j'espère que cette petite précision intervention ne te dérangera pas trop... promis je te laisse tranquille tant que tu parle de Data Mining.... Quand à moi, je retourne à mon code C#.