Requête SSIS s'exécutant très lentement dans le travail du catalogue. wait_type: ASYNC_NETWORK_IO

Question

J'ai un paquet SSIS dans le cadre d'un projet. Lorsqu'il est exécuté à partir de ma machine via SSIS, il faut environ 15 minutes pour traiter les enregistrements 15M. Une fois déployé dans le catalogue sur le serveur et exécuté par un travail, cela fait maintenant plus de 2 heures.

Ce paquet particulier déplace des données sur le serveur lui-même (en transit), donc il n'y a pas de goulots d'étranglement sur le réseau.

Voici quelques statistiques de SP_WHO3:

cpu_time: 484482

requested_memory_kb: 2469520

granted_memory_kb: 2469520

ideal_memory_kb: 14508048

query_cost: 85,3073051231772

wait_type: ASYNC_NETWORK_IO

En regardant le moniteur de ressources sur le serveur, je vois que les E/S disque sont terriblement élevées (bien sûr), principalement par le processus Système, à ~ 190,000,000 B/Sec, et arrivant à un loin seconde est sqlserver.exe à ~ 300 000 B/Sec

Le package est configuré avec BufferTempStoragePath réglé sur c: \ temp \ DefaultBufferMaxRows = 10 000 DefaultBufferSize = 10485760

Où dois-je aller à la recherche afin de trouver la cause première de cette exécution lente?

Merci!

Answer 1

ASYNC_NETWORK_IO est causée par le code client de ne pas consommer les lignes en provenance de SQL assez vite

Avez-vous déployé le paquet sur le même serveur que vous interrogez des données à partir? Parce que pour traiter ces lignes nécessite de la mémoire que le serveur SQL utilisera probablement.

L'exécuter localement sur votre PC sépare cette charge. "Processus système, à ~ 190,000,000 B/Sec" peut être beaucoup de pagination mémoire trop où vous êtes en train de battre le disque et la mémoire parce que vous avez peu de mémoire. Personnellement, j'utiliserais toujours un serveur ETL (SSIS) dédié séparé.

Cependant, je passerais en revue votre mémoire SQL Server max et la réduirai pour permettre l'exécution du package SSIS.