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.