Forum Discussion
Inconsistent Execution Times in Microsoft Fabric Pipeline
- Anonymous1 year ago
I think there are two distinct issues at play here, one you have noticed and one you might not be aware of.
Issue #1: Inconsistent processing time between invocations of any particular notebook:
This can be caused by a few things, including the time it takes to create a spark session (though, that shouldn't take more than a few minutes). You could also be hitting your spark pool max, or your Fabric capacity maximums. If you have access, you can view the compute usage in the Capacity Metrics Report. If you open up the individual notebook activites in the monitoring details, you can go to the spark monitoring, and there is a "resources (preview)" tab in there that should show you how efficiently your notebook utilized its allocated resources over the duration of its execution. Here you would also see if your spark pool was running out of resources, so notebooks were 'waiting' or 'queueing' for the pools resources to free up so they could allocate them.
There is also the real possibility that some of your data ingestions include more data than others. Which logically, you might expect would take longer to handle. Have you looked into the amount of data being written/read by these notebooks that are taking longer?
There is also the possibility that the API doesn't like you hitting it with a bunch of request very quickly, and might be delaying their responses. Have you logged the API calls from the notebook? You might want to look at when the API was called, when spark got a response, etc.
Issue #2: Notebook parallelization via the Pipeline for-each:
This is what I think you should look into if you really want to increase performance. The way you are executing one notebook at a time, in its own session, is not an effective use of the notebook's ability to perform dynamic parallelization and resource allocation on its own. I highly suggest using one invocation of a notebook which calls usesmssparkutils.notebook.runMultiple() to execute multiple invocations of a notebook, all in a single spark session, rather than simply calling one notebooks repeatedly in a for-each loop. This way, spark is able to really leverage its ability to perform concurrent tasks efficiently. This is a pretty decent article on the subject, which includes some examples of this method (and others) and has good explanations:
https://learn-it-all.medium.com/parallelism-in-spark-notebook-execution-in-microsoft-fabric-8fb6ac3f79be
Best of luck!
Hi Anonymous,
Thank you for your response and suggestions. Unfortunately, I am still experiencing the same issue, even after enabling High Concurrency Mode. As shown in the image, the pipeline recently got stuck on a single notebook execution for over 8 hours, despite the notebook successfully connecting to the server and completing the data ingestion.
This erratic behaviour continues to be unpredictable, with prolonged delays occurring at seemingly random intervals. Any further guidance or troubleshooting steps would be greatly appreciated.
Best regards,
Ifeanyi
Hi Anyi ,
Can you try Spark Autotune? Does the troubleshooting documentation I posted below help you?
Best Regards,
Yang
Community Support Team
If there is any post helps, then please consider Accept it as the solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!