Issues with Synapse Workflows After Updating Self-hosted Integration Runtime

Question

Issues with Synapse Workflows After Updating Self-hosted Integration Runtime

John Brynford-Jones 31

After updating the Self-hosted Integration Runtime to version 5.54.9267.1 from 5.44.xx on June 10th, the pipeline runs that previously completed in about 30 minutes are now taking several hours and worsening daily.

Uploaded image

The Integration Runtime operates on its own dedicated VM, which is managed with the Synapse Workflow. No other modifications have been made to the VM, Synapse workflows, or pipelines.

Is there a known issue with the latest version, or have the VM specifications changed?

Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-24T09:40:57.8766667+00:00
Hi @John Brynford-Jones
Thanks again for your patience while we looked into this.

Based on your description and the noticeable performance degradation after upgrading the Self-hosted Integration Runtime (SHIR), we’d like to confirm a few more details about your environment that could be contributing to the issue.

To help us assess whether this aligns with a known pattern we've seen in similar cases, could you please confirm the following:

What VM SKU is currently hosting your SHIR?

Are you observing any signs of high CPU usage or throttling on the VM?

Have you recently changed the disk type, or are you still using a Standard SSD (E-series)?

To retrieve the current VM SKU, you can run one of the following Azure CLI commands:

Option 1: If you know the VM name and resource group:

az vm show -n <VMName> -g <ResourceGroupName> --query "hardwareProfile.vmSize" -o tsv

Option 2: If the resource group is unknown:

az vm list --query "[?name=='<VMName>'].hardwareProfile.vmSize" -o tsv

This will help us validate whether the VM configuration is optimal for your current SHIR workload, especially given the runtime delays you're experiencing.

Let me know if you need help locating the VM name or running the command - happy to assist.
John Brynford-Jones 31 Reputation points

2025-06-24T09:48:38.1366667+00:00

Hello Smaran,

VM Size: Standard_B8ms

Disk: E10 Standard SSD LRS

We made no changes to anything except for updating the Integration Runtime.

Yes during runs the CPU would be hitting 100% solidily, we do not have the CPU metrics from before we upgraded to the newest Integration runtime.

I don't think it should be a performance issue as this was more than enough before the update. Pipeline runs took around 30 mins before.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-24T14:56:55.64+00:00

Hi @John Brynford-Jones
Thanks for confirming the details.

Based on the information you have shared - particularly the use of a Standard_B8ms VM and the fact that CPU usage now remains consistently at 100% during runs - this strongly suggests that the burstable VM is no longer sufficient for your current workload after the SHIR update.

While the B8ms SKU may have worked previously, it’s important to note that B-series VMs rely on accumulated CPU credits, and once those credits are exhausted (as seems to be the case now), the VM is throttled to a baseline performance level. The SHIR update may have introduced higher or more sustained resource consumption, tipping it over the edge.

Recommendation:

We recommend switching to a compute-optimized VM SKU, such as F-series (e.g., F8s_v2 or F16s_v2), which is designed for sustained high CPU workloads - no credit system involved.

Additionally, since you’re using a Standard SSD (E10), you may want to monitor disk IOPS usage after upgrading the VM. If the workload increases, upgrading to a Premium SSD (e.g., P15 or higher) may help avoid disk I/O bottlenecks.
I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-25T11:33:13.6566667+00:00

@John Brynford-Jones We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
John Brynford-Jones 31 Reputation points

2025-06-25T13:57:50.3266667+00:00

Apologies, we have since opened a direct support request with Azure Support.

We want to avoid upgrading the size of our VM if possible.

We have downgraded the SHIR app to it's previous version temporarily and the performance has been brought back to normal levels. Azure Support are currently investigating our pipeline runs and the possibilty of an issue with the latest SHIR app.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-25T14:41:25.99+00:00

@John Brynford-Jones Could you please provide the SR# so we can check internally and coordinate on your issue and its status?
John Brynford-Jones 31 Reputation points

2025-06-25T14:47:53.19+00:00

Yes it is: #2506240050000583
Chandra Boorla 15,470 Reputation points Microsoft External Staff Moderator

2025-06-27T17:55:11.7266667+00:00

@John Brynford-Jones

Thank you for sharing the support ticket number. We will reach out to the internal team and update you once we hear back from them.

Appreciate your patience.
Piotr D 0 Reputation points

2025-07-04T08:04:47.0966667+00:00

Hi John,

If Azure Support has already given you any guidance—case reference, preliminary findings, or a recommended workaround—could you share it with me? We have the same problem after update SHIR to 5.54.9267.1 version
John Brynford-Jones 31 Reputation points

2025-07-04T08:42:18.3166667+00:00

Hi Piotr,

Nothing concrete from support yet. But the fact both of us are having the same issue suggests a bug.

Thanks for sharing.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-07-07T06:17:03.13+00:00

John Brynford-Jones We have reviewed your case internally, and our team is currently awaiting further confirmation from you to proceed with resolving the issue. Could you please provide the following information.

Once we receive this information, we will be able to move forward with your case promptly.

If you have any questions or need further assistance, please feel free to reach out to us directly.

Thank you for your cooperation.
John Brynford-Jones 31 Reputation points

2025-07-07T08:15:22.3633333+00:00

Support have been in touch and they confirm there are issues with the latest version of SHIR 5.55.

"After consulting with our internal team, we’ve identified that there are some ongoing issues with the latest version of the Self-hosted Integration Runtime (SHIR). As a temporary workaround, our product team recommends reverting to the previous version of SHIR until the root cause is identified and resolved."

Answer accepted by question author

3 additional answers

Your answer

Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-24T09:40:57.8766667+00:00

Hi @John Brynford-Jones
Thanks again for your patience while we looked into this.

Based on your description and the noticeable performance degradation after upgrading the Self-hosted Integration Runtime (SHIR), we’d like to confirm a few more details about your environment that could be contributing to the issue.

To help us assess whether this aligns with a known pattern we've seen in similar cases, could you please confirm the following:

What VM SKU is currently hosting your SHIR?

Are you observing any signs of high CPU usage or throttling on the VM?

Have you recently changed the disk type, or are you still using a Standard SSD (E-series)?

To retrieve the current VM SKU, you can run one of the following Azure CLI commands:

Option 1: If you know the VM name and resource group:

az vm show -n <VMName> -g <ResourceGroupName> --query "hardwareProfile.vmSize" -o tsv

Option 2: If the resource group is unknown:

az vm list --query "[?name=='<VMName>'].hardwareProfile.vmSize" -o tsv

This will help us validate whether the VM configuration is optimal for your current SHIR workload, especially given the runtime delays you're experiencing.

Let me know if you need help locating the VM name or running the command - happy to assist.
John Brynford-Jones 31 Reputation points

2025-06-24T09:48:38.1366667+00:00

Hello Smaran,

VM Size: Standard_B8ms

Disk: E10 Standard SSD LRS

We made no changes to anything except for updating the Integration Runtime.

Yes during runs the CPU would be hitting 100% solidily, we do not have the CPU metrics from before we upgraded to the newest Integration runtime.

I don't think it should be a performance issue as this was more than enough before the update. Pipeline runs took around 30 mins before.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-24T14:56:55.64+00:00

Hi @John Brynford-Jones
Thanks for confirming the details.

Based on the information you have shared - particularly the use of a Standard_B8ms VM and the fact that CPU usage now remains consistently at 100% during runs - this strongly suggests that the burstable VM is no longer sufficient for your current workload after the SHIR update.

While the B8ms SKU may have worked previously, it’s important to note that B-series VMs rely on accumulated CPU credits, and once those credits are exhausted (as seems to be the case now), the VM is throttled to a baseline performance level. The SHIR update may have introduced higher or more sustained resource consumption, tipping it over the edge.

Recommendation:

We recommend switching to a compute-optimized VM SKU, such as F-series (e.g., F8s_v2 or F16s_v2), which is designed for sustained high CPU workloads - no credit system involved.

Additionally, since you’re using a Standard SSD (E10), you may want to monitor disk IOPS usage after upgrading the VM. If the workload increases, upgrading to a Premium SSD (e.g., P15 or higher) may help avoid disk I/O bottlenecks.
I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-25T11:33:13.6566667+00:00

@John Brynford-Jones We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
John Brynford-Jones 31 Reputation points

2025-06-25T13:57:50.3266667+00:00

Apologies, we have since opened a direct support request with Azure Support.

We want to avoid upgrading the size of our VM if possible.

We have downgraded the SHIR app to it's previous version temporarily and the performance has been brought back to normal levels. Azure Support are currently investigating our pipeline runs and the possibilty of an issue with the latest SHIR app.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-06-25T14:41:25.99+00:00

@John Brynford-Jones Could you please provide the SR# so we can check internally and coordinate on your issue and its status?
John Brynford-Jones 31 Reputation points

2025-06-25T14:47:53.19+00:00

Yes it is: #2506240050000583
Chandra Boorla 15,470 Reputation points Microsoft External Staff Moderator

2025-06-27T17:55:11.7266667+00:00

@John Brynford-Jones

Thank you for sharing the support ticket number. We will reach out to the internal team and update you once we hear back from them.

Appreciate your patience.
Piotr D 0 Reputation points

2025-07-04T08:04:47.0966667+00:00

Hi John,

If Azure Support has already given you any guidance—case reference, preliminary findings, or a recommended workaround—could you share it with me? We have the same problem after update SHIR to 5.54.9267.1 version
John Brynford-Jones 31 Reputation points

2025-07-04T08:42:18.3166667+00:00

Hi Piotr,

Nothing concrete from support yet. But the fact both of us are having the same issue suggests a bug.

Thanks for sharing.
Smaran Thoomu 33,920 Reputation points Microsoft External Staff Moderator

2025-07-07T06:17:03.13+00:00

John Brynford-Jones We have reviewed your case internally, and our team is currently awaiting further confirmation from you to proceed with resolving the issue. Could you please provide the following information.

Once we receive this information, we will be able to move forward with your case promptly.

If you have any questions or need further assistance, please feel free to reach out to us directly.

Thank you for your cooperation.
John Brynford-Jones 31 Reputation points

2025-07-07T08:15:22.3633333+00:00

Support have been in touch and they confirm there are issues with the latest version of SHIR 5.55.

"After consulting with our internal team, we’ve identified that there are some ongoing issues with the latest version of the Self-hosted Integration Runtime (SHIR). As a temporary workaround, our product team recommends reverting to the previous version of SHIR until the root cause is identified and resolved."

Answer 1

Hi John Brynford-Jones
Thank you for sharing your experience. In line with the resolution provided by the Support Team, I am sharing the findings here for the community. This information may be helpful to others who encounter a similar issue:
Summary of Findings:

After updating to Self-hosted Integration Runtime (SHIR) version 5.54.9267.1 or 5.55, several users (including us) noticed pipeline performance degradation, with runs taking much longer and consistently high CPU usage, even on previously sufficient VMs.

Confirmed Issue:

Azure Support has confirmed that there are known issues with the latest SHIR version (5.55) that may increase resource consumption or trigger throttling, especially on burstable VMs like Standard_B8ms.

Workaround:

As a temporary solution, we downgraded to the earlier SHIR version (5.44.x) — this immediately restored performance to normal levels.

Azure Support has recommended this downgrade while the product team continues to investigate the issue and work on a fix for the latest SHIR version.

If You're Affected:

Consider rolling back to a stable SHIR version (e.g., 5.44.x) if your pipelines have slowed significantly after the update.
If you're using a B-series (burstable) VM, be aware that SHIR updates may now require more CPU resources - monitor CPU usage or consider switching to compute-optimized VMs like F8s_v2 if downgrading doesn't help.

If you have any other questions, please let me know. Thank you again for your time and patience throughout this issue.

Please don’t forget to Accept Answer and Yes for "was this answer helpful" wherever the information provided helps you, this can be beneficial to other community members

Anders Schou 10 Reputation points

2026-03-06T03:39:42.17+00:00

Is version 5.44 still working, and when will that expire ?

Answer 2

Jasper Batterink 15

Here also the same issue with multiple customer platforms (at least 3) having issues with update versions above 5.54. Since it is not publicly available here a link to download 5.54 that a colleague found: https://download.microsoft.com/download/E/4/7/E4771905-1079-445B-8BF9-8A1A075D8A10/IntegrationRuntime_5.54.9267.1.msi.

We're also testing newer versions (up to 5.60) but keep having issues. @Smaran Thoomu , do you have any insight on a fix so we can update again maybe? In our case the customer platform have different VM's SKU (either B or D family sku's) where the same issue appears.

Anders Schou 10 Reputation points

2026-03-06T03:46:57.67+00:00

@Jasper Batterink is your 5.54 SHIR still working? And do you know when it expires?

Answer 3

Anders Schou 10

we the exact same issue after an automatic update of our integration runtime the 15 of November 2025. we we able to uninstall and downgrade to an earlier version. 5.50.9162.1, in order to make the ADF pipelines faster. however it was lucky we had the earlier version stored. does anyone know how to find earlier versions of the self hosted integration runtime if the issue occurs again?

User's image

Anders Schou 10 Reputation points

2026-03-06T03:35:39.83+00:00

We are having issues again since our SHIR version expired the 1st of March 2026.

Answer 4

Anders Schou 10

Title: SHIR v5.61.9481.1 - Severe performance regression after upgrade - anyone else experiencing this?

Hi all,

We recently upgraded our Self-Hosted Integration Runtime to version 5.61.9481.1 and have experienced a severe performance regression that we cannot explain by hardware alone.

Before upgrade:

SHIR version: previous (now expired, cannot rollback)
Server: 4 cores / 16 GB RAM
Total pipeline runtime: ~23 minutes
Everything running smoothly

After upgrade to 5.61.9481.1:

Server upgraded to: 8 cores / 32 GB RAM
Total pipeline runtime: 46-59 minutes
diawp.exe worker processes consume 100% CPU
Queue time per copy activity: ~1 minute 9 seconds
Actual data transfer per activity: ~3 seconds
93% of activity time is spent waiting in queue
RAM utilization remains low — bottleneck is clearly CPU-bound in diawp.exe

So we doubled the hardware and got more than double the runtime. The workload, pipelines, and data sources are completely identical.

What we have tried:

Reduced concurrent jobs from 16 to 8 — CPU dropped to 60% but runtime increased to 59 min
Upgraded server from 4 cores / 16 GB to 8 cores / 32 GB
Tested concurrent jobs at 8, 12, 16, and 20
Attempted rollback to previous SHIR version — expired and cannot be installed

Our theory is that something changed in v5.61 regarding how diawp.exe handles serialization, TLS, or worker process spawning that significantly increased CPU overhead per job.

Has anyone else experienced similar performance degradation after upgrading to SHIR 5.61? Any workarounds or configuration tweaks that helped?

We have opened a Microsoft support case but would appreciate any community insights.

Thanks in advance.

Jasper Batterink 15 Reputation points

2026-03-06T07:27:52.34+00:00
Hi Anders,

We went through exactly the same painful experience after upgrading, so hopefully our journey can save some of you time.

Like many of you, our first step was opening a support ticket with Microsoft. After a lot of back and forth and showing them exact copies of pipeline runs comparing version 5.54 (good performance) against 5.56 and the then just released 5.60, they kept not acknowledging anything had changed. After what felt like endless investigation cycles, we finally got this response:

"After investigating the incident thoroughly we discovered that SHIR after version 5.55 is now more sensitive to high resource utilization (CPU/Memory) which would explain why we have degradation in performance after upgrade. However, as we mentioned previously we wouldn't have noticed any degradation if we kept the CPU consumption around 80% as recommended in the best practices."

So there you have it. Not exactly a straight admission of a regression, but at least a confirmation that something fundamentally changed after 5.55. Their practical advice was to keep CPU below 80% to guarantee good queuing. For our production environment that meant adding 2 extra VM nodes, since we already knew from previous testing that scale-out works better than scale-up for SHIR.

But then came the real game changer.

Microsoft also suggested enabling ParquetV2, after spotting a specific difference in Parquet copy performance compared to previous versions. Enabling it is simple — just append "useParquetV2": true at the same level as compressionCodec in your Parquet dataset JSON:

"compressionCodec":

Since our pipelines are purely focused on extracting data and loading it to the lake as Parquet — with Spark handling the rest — this was a perfect fit for us. The result? A 30-40% runtime improvement, which partially offsets the ~50% regression we saw after the upgrade.

We are currently monitoring the load across our 3 SHIR nodes to see if we can scale back down, but honestly we are not confident a single VM will ever perform like it did pre-5.55. Hopefully Microsoft addresses the underlying CPU efficiency in a future release rather than just pointing us toward more infrastructure.

Share via

Issues with Synapse Workflows After Updating Self-hosted Integration Runtime

3 additional answers

Your answer