Article ID: 328551 - View products that this article applies to.
This article was previously published under Q328551
BUG #: 362099 (SHILOH_BUGS)
When the tempdb database is heavily used, SQL Server may experience contention when it tries to allocate pages.
From the sysprocesses system table output, the waitresource may show up as "2:1:1" (PFS Page) or "2:1:3" (SGAM Page). Depending on the degree of contention, this may also lead to SQL Server appearing unresponsive for short periods.
These operations heavily use tempdb:
During object creation, two (2) pages must be allocated from a mixed extent and assigned to the new object. One page is for the Index Allocation Map (IAM), and the second is for the first page for the object. SQL Server tracks mixed extents by using the Shared Global Allocation Map (SGAM) page. Each SGAM page tracks about 4 gigabytes of data.
As part of allocating a page from the mixed extent, SQL Server must scan the Page Free Space (PFS) page to find out which mixed page is free to be allocated. The PFS page keeps track of free space available on every page, and each PFS page tracks about 8000 pages. Appropriate synchronization is maintained to make changes to the PFS and SGAM pages; and that can stall other modifiers for short periods.
When SQL Server searches for a mixed page to allocate, it always starts the scan on the same file and SGAM page. This results in intense contention on the SGAM page when several mixed page allocations are underway, which can cause the problems documented in the "Symptoms" section of this article.
Note De-allocation activities must also modify the pages, which can contribute to the increased contention.
To learn more about the different allocation mechanisms used by SQL Server (SGAM, GAM, PFS, IAM), see the "References" section of this article.
Microsoft SQL Server 2000
To reduce the allocation resource contention for a tempdb that is experiencing heavy usage, follow all these steps:
With regard to step 2, the use of trace flag -T1118 for Microsoft SQL Server 7.0, before you use the trace flag, see the following article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/813492/ )FIX: Create index fails on SQL Server 7.0 when trace flag 1118 is enabled
Microsoft SQL Server 2005 and later versionsTo reduce the allocation resource contention for a tempdb that is experiencing heavy usage, follow these steps:
How the fix in SQL 2000 SP4 and later versions reduces contentionSQL Server 2000 Sp4 and later versions have a fix that introduces a round-robin algorithm for mixed page allocations. With the fix, the starting file will now be different for each consecutive mixed page allocation (if more than one file exists). This avoids the contention problem by breaking up the train that went through the SGAMs in the same order every time with the same starting point. The new allocation algorithm for SGAM is pure round-robin, and does not honor the proportional fill to maintain speed. Microsoft recommends that you create the tempdb data files with the same size.
How implementing trace flag -T1118 reduces contentionHere is list of how use of -T1118 reduces contention:
Increase the number of tempdb data files with equal sizingIf the data file size of tempdb is 5 GB, and the Log file size is 5 GB, the recommendation is to increase the single datafile to 10 (each of 500 MB to maintain equal sizing), and leave the log file as is. Having the different data files on separate disks would be good. However, this is not required and they can co-exist on the same disk.
The optimal number of tempdb data files depends on the degree of contention seen in tempdb. As a starting point, you can configure the tempdb to be at least equal to the number of processors assigned for SQL Server. For higher end systems (for example, 16 or 32 proc), the starting number could be 10. If the contention is not reduced, you may have to increase the number of data files more.
Note A dual-core processor is considered to be two processors.
The equal sizing of data files is critical because the proportional fill algorithm is based on the size of the files. If data files are created with unequal sizes, the proportional fill algorithm tries to use the largest file more for GAM allocations instead of spreading the allocations between all the files, thereby defeating the purpose of creating multiple data files.
The auto-grow of tempdb data files can also interfere with the proportional fill algorithm. Therefore, it may be a good idea to turn off the auto-grow feature for the tempdb data files. If the auto-grow option is turned off, you must make sure to create the data files so that they are large enough to prevent the server from experiencing a lack of disk space with tempdb.
How increasing the number of tempdb data files with equal sizing reduces contentionHere is a list of how increasing the number of tempdb data files with equal sizing reduces contention:
DisadvantagesThe only downside to the recommendations mentioned earlier is that you may see the size of the databases increase when the following conditions are true:
For more information about GAM, SGAM, PFS, and IAM, see the following SQL Server 2000 Books Online topics:
For more information about the tempdb database in SQL Server 2005, visit the following MSDN website:
For more information about tempdb database files and Trace Tlag 1118, visit the following MSDN website:
For more information about how to use Trace Flag 1118 in SQL Server 2005 and SQL Server 2008, visit the following MSDN website:
For more information about how to monitor and troubleshoot allocation bottlenecks in the tempdb database, visit the following MSDN website:
Article ID: 328551 - Last Review: January 10, 2013 - Revision: 14.0