Understanding VDI_CLIENT_WORKER Sessions in Azure SQL Database and Their Performance Impact

What changed

Azure SQL Database now surfaces a larger number of sessions whose command text is VDI_CLIENT_WORKER. These sessions often show up after a service‑objective change, a geo‑replication setup, or any operation that requires database seeding. The visibility increase has led many teams to suspect that these workers are the root cause of latency spikes.

Provider comparison – internal workers vs. user workload

Aspect	VDI_CLIENT_WORKER sessions	Typical user sessions
Origin	Platform‑initiated copy/seeding processes.	Application‑initiated queries, stored procedures, etc.
Killability	KILL command usually fails or is ignored.	Can be terminated safely with KILL.
Resource profile	Low CPU, modest I/O, minimal log writes unless a large copy is in progress.	Varies widely; may consume significant CPU, I/O, or log bandwidth.
Lifecycle	Appear when scaling, replica creation, or backup‑restore‑like activities start; disappear once the operation completes or after a failover.	Follow the lifespan of the client transaction or batch.
Monitoring focus	Correlate with recent platform actions; watch wait stats like VDI_CLIENT_*.	Look at wait_type, blocking_session_id, log_write_percent.

Why the sessions appear

1. Scaling operations – When you change the service tier (e.g., from S3 to S4), Azure copies the underlying storage to a new tier. The copy is performed by a set of background workers that register as VDI_CLIENT_WORKER.
2. Geo‑replication and copy workflows – Creating a secondary or performing a database copy triggers a seeding routine. The routine uses the same worker pool.
3. Internal seeding for failover – During a planned failover, Azure prepares a fresh copy of the primary to become the new primary; workers again surface with this command text.

These sessions are not tied to a specific user login; they run under the internal service principal and are designed to be invisible to most performance tools.

Business impact – when to act and when to ignore

Validate the context

1. Check recent platform actions – Review the audit log or the Azure portal activity feed. If a scaling event, replica creation, or copy operation occurred within the last few minutes, the workers are expected.
2. Measure resource consumption – Query sys.dm_exec_sessions and sys.dm_os_wait_stats for the worker PIDs. Typical output shows CPU usage under 2 % and I/O waits near zero.
3. Correlate with user‑visible symptoms – If end‑users report latency, compare the timing of the complaints with spikes in log_write_percent or blocking chains. If those metrics are stable, the workers are unlikely to be the cause.

What not to do

• Do not kill the sessions – The platform will reject the request or silently restart the worker, potentially extending the seeding window.
• Do not treat their presence as a performance alert – Alerting on the count of VDI_CLIENT_WORKER sessions alone generates noise and can distract from genuine issues.

When removal is justified

If a worker persists long after the associated operation has completed (for example, a scaling event finished 30 minutes ago but the session is still active), you can consider a controlled failover or a short maintenance‑window restart of the database. This action forces the platform to clean up stale internal state. Always schedule such actions during a low‑traffic window and communicate the expected brief outage.

Focus on the real bottlenecks

When you encounter slowness, prioritize the following diagnostics:

1. Blocking and deadlocks – Query sys.dm_tran_locks and sys.dm_exec_requests for blocking_session_id. Resolve by tuning indexes, breaking long‑running transactions, or implementing retry logic.
2. Transaction‑log throttling – Monitor log_write_percent and the wait type LOG_RATE_GOVERNOR. Heavy DML workloads that exceed the allocated log throughput will be throttled, leading to latency spikes.
3. Hot query contention – Identify queries with high cpu_time and total_elapsed_time that hit the same tables or indexes. Consider query refactoring, index adjustments, or read‑scale replicas.

Key takeaways

• VDI_CLIENT_WORKER sessions are internal background workers triggered by scaling, replica seeding, or copy operations.
• Their mere presence does not indicate a performance problem; they usually consume minimal resources.
• Avoid killing them; instead, verify whether a recent platform operation explains their existence.
• Direct troubleshooting effort toward blocking chains, log‑rate throttling, and hot queries—these are the typical sources of user‑visible slowness.

For a deeper dive, see the official Azure SQL Database documentation on service‑objective scaling and the geo‑replication guide.