SQL Server Priority Boost: Why You Shouldn’t Enable It and How to Turn It Off

The Boost SQL Server priority box in the server properties looks tempting because of its name: giving SQL Server “priority” sounds like it should improve performance. In reality it’s an old option that Microsoft plans to remove, that Microsoft explicitly says isn’t needed for performance tuning, and that can destabilize the server under the wrong conditions.

This article explains what priority boost does, why it should stay off, how to turn it off safely if it’s on, and what to look at for performance instead.

What Does Priority Boost Do?

This setting, whose default is 0, sets the base priority of the SQL Server process in the Windows scheduler. At 0, SQL Server runs with a base priority of 7; at 1, with 13. In other words, SQL Server’s threads jump ahead of other processes on the server.

Why It Should Stay Off

• It’s deprecated: Microsoft has announced it will be removed in a future version; it shouldn’t be used in new configurations.
• It isn’t needed for performance: Microsoft’s own documentation states that priority boost isn’t needed for performance tuning and should only be used in exceptional circumstances, for example while Microsoft support investigates a performance issue.
• It can starve the operating system: while SQL Server runs at high priority, essential operating system and network functions may not get resources. The result can be sluggish remote desktop sessions, network timeouts and SQL Server failing to shut down cleanly.
• It’s risky on clusters: Microsoft explicitly says not to use priority boost on a failover cluster instance. If cluster heartbeats aren’t processed in time, unnecessary failovers can follow.

Is It On? How to Check and Turn It Off

-- Current value (on if value_in_use = 1)
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name = N'priority boost';

-- To turn it off
EXEC sys.sp_configure N'show advanced options', 1;
RECONFIGURE;
EXEC sys.sp_configure N'priority boost', 0;
RECONFIGURE;

The setting doesn’t take effect until the SQL Server service restarts. If value shows 0 but value_in_use still shows 1, the change has been made but the service hasn’t been restarted yet. Plan the restart in a maintenance window.

Check the Other Non-Default Settings Too

On a server where priority boost is on, other old “performance” settings may have been changed as well. You can list every server setting that differs from its default in one query. The list below includes the defaults of the settings reviewed most often:

SELECT c.name, c.value_in_use, d.default_value
FROM sys.configurations AS c
JOIN (VALUES (N'priority boost', 0), (N'lightweight pooling', 0),
             (N'affinity mask', 0), (N'affinity I/O mask', 0),
             (N'max worker threads', 0), (N'cost threshold for parallelism', 5),
             (N'max degree of parallelism', 0), (N'max server memory (MB)', 2147483647),
             (N'xp_cmdshell', 0), (N'clr enabled', 0)) AS d(name, default_value)
     ON d.name = c.name
WHERE CONVERT(int, c.value_in_use) <> d.default_value;

For settings such as max server memory, MAXDOP and cost threshold for parallelism, a non-default value is usually right; what matters is that the value was chosen deliberately. Settings such as priority boost, lightweight pooling and affinity mask, on the other hand, should stay at their defaults unless there’s a documented, specific reason.

Checklist

• priority boost is 0, and so is value_in_use.
• It’s definitely off on failover cluster nodes.
• Every non-default server setting has a documented reason.
• If there’s CPU pressure, the root cause is investigated at query and index level.