Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

Hello @nikopieper,

Thank you for your feedback.

I moved your comment to a new thread in the PowerShell Universal - Support section.

We found no SQL, Git, or schema-migration changes in 2026.2.5 that would explain Git Settings queries taking 25–35 seconds. The release did update the bundled .NET runtime build and PowerShell SDK, so we would like to collect data if it recurs.

Before reproducing, please take a backup. Set Data:SlowQueryLimit to 1 temporarily and restart PSU. The system log will then record Slow Query Detected entries with the SQL command and duration; please send the relevant log section from %ProgramData%\PowerShellUniversal\Logs\System\systemLog.txt (or your configured SystemLogPath), with credentials, tokens, and connection strings redacted.

At the same time, please have the DBA capture the SQL Server wait type, blocking session, execution plan, and active Availability Group replica/listener for the slow requests. Since restoring the database resolved the problem, this evidence will help distinguish blocking, failover/routing, plan-cache, or storage latency from an application regression.

I'll send you a link for you to upload the logs to our safe space.

Thank you for your collaboration.

Best regards,

Hello,

the DB "crashed" again and PSU is not working anymore. i uploaded the files

Hello nikopieper,

Thank you for the update.

I currently do not have access to the files you mentioned uploading. However, given that the issue has now recurred and PSU is currently not operational, we consider the situation critical enough to escalate it directly through our internal channels for further review.

If any additional information is required after the escalation review begins, I will follow up here with the specific details needed.

Best regards,
Ruben Tapia

I asked for the Data from the DBA which is pending, the DB is ~8GB on a 2022 SQL Cluster

Hello nikopieper,

Thank you for the update.

I currently do not have access to the files you mentioned uploading. However, given that the issue has now recurred and PSU is currently not operational, we consider the situation critical enough to escalate it directly through our internal channels for further review.

If any additional information is required after the escalation review begins, I will follow up here with the specific details needed.

Best regards,
Ruben Tapia

@rubentapia
i sent you a mail with the log attached

2026-08-21 17:43:45.270 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SET IMPLICIT_TRANSACTIONS OFF;
SET NOCOUNT ON;
UPDATE [Job] SET [CreatedTime] = @p0, [Environment] = @p1, [StartTime] = @p2
OUTPUT 1
WHERE [Id] = @p3;
| Parameters: @p3=297424, @p0=8/21/2026 3:43:44 PM, @p1=PowerShell 7.4.12
, @p2=8/21/2026 3:43:44 PM, took 542.2779 ms
2026-08-21 17:43:45.274 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SET IMPLICIT_TRANSACTIONS OFF;
SET NOCOUNT ON;
UPDATE [Job] SET [MemoryBytes] = @p0
OUTPUT 1
WHERE [Id] = @p1;
| Parameters: @p1=297422, @p0=94598485, took 545.0694 ms
2026-08-21 17:43:45.613 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT TOP(1) [j].[Status]
FROM [Job] AS [j]
WHERE [j].[Id] = @job_Id | Parameters: @job_Id=297426, took 344.598 ms
2026-08-21 17:43:45.614 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT [g].[Id], [g].[Branch], [g].[Bundle], [g].[BundlePath], [g].[BundleTimestamp], [g].[ExternalGit], [g].[GitEnvironmentVariable], [g].[GitSshKey], [g].[InitBehavior], [g].[Interval], [g].[ManualMode], [g].[Mode], [g].[Name], [g].[Password], [g].[Paused], [g].[ProxyUrl], [g].[Remote], [g].[SyncBehavior], [g].[UpdateSubmodules], [g].[UserName]
FROM [GitSettings] AS [g] took 339.9386 ms

2026-08-21 17:43:45.614 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT TOP(1) [j].[Status]
FROM [Job] AS [j]
WHERE [j].[Id] = @job_Id | Parameters: @job_Id=297422, took 338.966 ms
2026-08-21 17:43:45.614 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SET IMPLICIT_TRANSACTIONS OFF;
SET NOCOUNT ON;
UPDATE [Job] SET [MemoryBytes] = @p0
OUTPUT 1
WHERE [Id] = @p1;
| Parameters: @p1=297430, @p0=54439253, took 567.5672 ms

2026-08-21 17:44:15.770 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT [c1].[Id], [c1].[Deleted], [c1].[DeploymentName], [c1].[DeploymentVersion], [c1].[EditMode], [c1].[FileSyncTimestamp], [c1].[GitBranch], [c1].[GitSettings], [c1].[GitSshKey], [c1].[GrpcPort], [c1].[HangfireServerId], [c1].[HangfireWorkerCounter], [c1].[HeartBeat], [c1].[LoadingInfo], [c1].[LoginErrorMessage], [c1].[Maintenance], [c1].[Name], [c1].[ReadOnly], [c1].[Status], [c1].[Type], [c1].[Version], [c0].[Id], [c0].[ComputerId], [c0].[Name], [c0].[Static], [c0].[Value]
FROM (
SELECT TOP(1) [c].[Id], [c].[Deleted], [c].[DeploymentName], [c].[DeploymentVersion], [c].[EditMode], [c].[FileSyncTimestamp], [c].[GitBranch], [c].[GitSettings], [c].[GitSshKey], [c].[GrpcPort], [c].[HangfireServerId], [c].[HangfireWorkerCounter], [c].[HeartBeat], [c].[LoadingInfo], [c].[LoginErrorMessage], [c].[Maintenance], [c].[Name], [c].[ReadOnly], [c].[Status], [c].[Type], [c].[Version]
FROM [Computer] AS [c]
WHERE [c].[Name] = @nodeName
) AS [c1]
LEFT JOIN [ComputerTag] AS [c0] ON [c1].[Id] = [c0].[ComputerId]
ORDER BY [c1].[Id] | Parameters: @nodeName=XX, took 30154.648 ms

2026-08-21 17:44:15.795 +02:00 [WRN][Microsoft.AspNetCore.Server.Kestrel] As of ""2026-08-21T15:44:15.7690789+00:00"", the heartbeat has been running for ""00:00:29.7110717"" which is longer than ""00:00:01"". This could be caused by thread pool starvation.

2026-08-21 17:44:15.832 +02:00 [WRN][PowerShellUniversal.Automation.GrpcExecutionService] Job process did not respond to handshake in time. Killing process in 5 seconds.

Hello nikopieper,

Thank you for the additional information.

We reviewed the logs you provided internally. At this stage, the evidence points more strongly toward a SQL Server / HA-path latency issue rather than a PSU application or schema regression.

The slow queries are not isolated to Git settings. We can see unrelated reads and writes against several PSU tables becoming slow during the same periods. In the latest sample, a query against the Computer/ComputerTag data took approximately 30 seconds. During nearly the same interval, Kestrel reported a heartbeat delay of about 30 seconds, followed immediately by a job-process handshake timeout.

For the DBA investigation, the most useful window to correlate is:

**2026-08-21 17:43:45 through 17:44:16 +02:00**

The earlier **09:10–09:35 +02:00** interval is also relevant, as multiple unrelated queries reached approximately 7–37 seconds.

If possible, please have the DBA review those periods for SQL wait types, blocking sessions or blocking chains, execution plans where applicable, storage latency, resource pressure, and SQL cluster/replica/listener health.

Additionally, if permitted by your organization's policies, it would be helpful if you could provide a **sanitized copy of the affected database** using the secure upload location that Erika previously provided. Please do not post the database publicly. Before uploading it, remove or anonymize customer data, credentials, tokens, connection information, and any other sensitive or identifying information.

Once the DBA information and, if available, the sanitized database are provided, we can continue correlating the SQL behavior with the PSU events we identified.

Best regards,
Ruben Tapia

Just to clarify, for now please prioritize the DBA findings for the identified time windows. There is no need to prepare or upload a sanitized database copy unless we specifically request it after reviewing those results.

Database show now errors or abnormal times.
I just restored the server to 2026.2.3 and Database before the update, for now it seems to work.

PSU has now been running for a while.
I suggest that there is something wrong with the version because:
2026.2.5 did not work with the restored database
After recovering to 2026.2.3 with the same restored database it works again

Hello nikopieper,

Thank you for the update.

Our Development team has already been reviewing this case, including the diagnostic information previously provided. I have also shared your latest finding that PSU 2026.2.5 exhibits the issue with the restored database, while PSU 2026.2.3 remains stable using that same restored database. This is an important comparison for the ongoing investigation.

Since we already reviewed the PSU logs you previously provided, there is no need to send those again.

If available, one additional piece of evidence that could help is the Windows Event Viewer information from the affected server around:

2026-08-21 17:43:45 through 17:44:16 +02:00

Please check the Application and System logs for any SQL Server, Failover Clustering, storage, network, service, or resource-related warnings or errors during that interval. Any corresponding SQL Server or cluster events collected by your DBA would also be useful.

To keep environment information private, please provide this evidence through the secure upload location previously provided by Erika rather than posting it publicly.

For now, please keep the currently stable 2026.2.3 environment as-is while the investigation continues.

Best regards,
Ruben Tapia

Hello nikopieper,

Thank you for your patience while we continue reviewing this with Development.

We have identified one specific area we would like to confirm with you.

Do you use `Set-PSUCache -Persist` anywhere in your PSU configuration, Apps, APIs, or scripts?

If yes, approximately how many persistent cache items do you normally maintain?

This will help us determine whether a cache-related change introduced between 2026.2.3 and 2026.2.4 could be relevant to the behavior you observed.

Best regards,
Ruben Tapia

Hello Ruben,

we have 12 persistant and 20 non persistant caches

Hello nikopieper,

Thank you for confirming the cache usage details.

Our Development team has identified the issue and has a fix tracked internally. Based on the current Development plan, the correction is expected to be included in PSU 2026.3.0.

For now, since your environment has remained stable after returning to PSU 2026.2.3, I recommend keeping that version in place rather than moving back to 2026.2.5.

At this stage, we do not need any additional SQL Server, Event Viewer, or DBA diagnostics unless Development requests something specific.

We will continue tracking the fix and update this thread once we can confirm that the corrected version is available.

Best regards,
Ruben Tapia

Hello nikopieper,

Thank you for confirming the cache usage details.

Our Development team has identified the issue and has a fix tracked internally. Based on the current Development plan, the correction is expected to be included in PSU 2026.3.0.

For now, since your environment has remained stable after returning to PSU 2026.2.3, I recommend keeping that version in place rather than moving back to 2026.2.5.

At this stage, we do not need any additional SQL Server, Event Viewer, or DBA diagnostics unless Development requests something specific.

We will continue tracking the fix and update this thread once we can confirm that the corrected version is available.

Best regards,
Ruben Tapia

@rubentapia
Hi Ruben, can you be a bit more specific on the root cause? I've been keeping an eye on this thread and holding off upgrading, is this something I'm also expected to encounter in my HA setup or is it specific to the users environment with their cache usage (something I dont really do much of, but have 2 persistant cached objects that are relatively small in size).

Hello @insomniacc,

What we know so far is that Development identified an issue related to persistent-cache handling introduced in PSU 2026.2.4, specifically around `Get-PSUCache -List`. A fix has already been identified and is currently planned for PSU 2026.3.0.

In nikopieper’s environment, persistent cache is in use, which matches the condition Development was investigating.

What we have not confirmed yet is whether HA is required to trigger the issue, whether any number of persistent cache items is enough, or whether the impact depends on the number or size of those items. Because you only have two relatively small persistent cached objects, I do not want to assume that your environment would necessarily experience the same behavior.

I’ll clarify those specific points with Adam, including whether HA, cache count/size, or explicit use of `Get-PSUCache -List` materially affects exposure to the issue, and I’ll update the thread once I have that confirmation.

Best regards,
Ruben Tapia

Thanks, I've got 2026.2.4 in my HA prod environment, havent noticed any issues as of yet.
I have 2 persistant cache object but do not use Get-PSUCache -List.
Will hold off upgrading it to 2026.2.5 until it's been confirmed.

Hello @nikopieper and @insomniacc,

Just a quick update to let you know that this case remains under active review with our Development team.

We are currently validating the latest findings, including whether the persistent-cache behavior previously identified fully explains the issue or whether another factor is involved.

No additional action or diagnostics are needed from your side at this time. We will update the thread as soon as we have a clearer technical direction.

Best regards,
Ruben Tapia

Hello @nikopieper and @insomniacc

A quick update from Development: we are still investigating the root cause, and at this point the persistent-cache behavior has not been confirmed as the cause of the issue.

If it is operationally safe in your environment, the next useful test would be:

* Pause all schedules and make sure no jobs are running.
* Start PSU 2026.2.5 once and note the exact timestamp if the slowdown occurs.
* Capture the PSU system log covering approximately five minutes before and after that timestamp.
* If possible, have the DBA capture the SQL activity/blocking during the same period, including SQL text, wait type, and blocking session.

Please do not perform this test if it would put a currently stable environment at risk.

Best regards,
Ruben Tapia