Friday, April 17, 2020

SQL Server 2017 cu17 Columnstore Workload OOMs Part 2: Whoever Smelt It, Dealt It?

This blog post is under construction...

This blog post is part of a series started yesterday with the post linked immediately below.

SQL Server 2017 cu17 ColumnStore Workload OOMs Part 1
https://sql-sasquatch.blogspot.com/2020/04/sql-server-2017-cu17-columnstore.html



Error investigation can be informed by one of two paradigms:
I think of the first paradigm as "whoever smelt it, dealt it."
The second paradigm is "the bearer of bad news."
Sometimes to reach the correct conclusion, the events and surrounding timeline must be examined from both viewpoints.

Whoever Smelt It, Dealt It

This article provided some needed laughter yesterday when I read it.  Its not directly relevant to the matter at hand... but its worth a chuckle.


We Asked Scientists Whether He Who Smelt It Really Dealt It

https://www.vice.com/en_us/article/ypa5x5/we-asked-scientists-whether-he-who-smelt-it-really-dealt-it

What the heck does this sophomoric idea have to do with OOMs, or any error type?

Consider this simplistic example.  The error is a direct result of the action by this session.  This session's action alone was sufficient to warrant the "divide by zero" error message.
This session smelt the error message, because this session dealt the divide by zero.


As it relates to OOMs, consider the OOM described in this blog post.
SQL Server 2019 Scalar UDF inlining - OOM in some cases
https://sql-sasquatch.blogspot.com/2019/11/sql-server-2019-udf-inlining-oom-in.html

A single session in isolation executing a query with an ugly UDF that triggers UDF inlining is sufficient to consume enough [Optimizer Memory] to result in the OOMs described in the post.  Yes, its a (fixed in CU2) bug, but the activity by that individual session realizes the risk presented by the bug.  That session  smelt it by way of the OOM, after that session dealt it by using an ugly inlined UDF.

OK.  Now let's focus on the OOMs I'm currently dealing with.  In SQL Server, if an OOM can be properly described as "whoever smelt it, dealt it" the memory activity must be attributable to the session that received the error and only that session.

One way for that to be the case is for that session to be running in isolation - no other user sessions on the instance.  That's not the case in observations of the OOMs I'm concerned with.  Each occurrence of these OOMs happens to be when there are multiple concurrent user sessions.

Another way for the memory activity to be attributable to the specific session that received the error is if the memory type is specifically and solely allocated to the session.  Connection memory works like that.  Connection memory is within [Total Server Memory] but individual sessions have private access to small chunks of it.  Optimizer memory works that way, too.  So, too, does the used portion of query memory grants.  All of the memory in [Total Server Memory] that can be individually attributed to sessions is within [Stolen Server Memory].  But not all [Stolen Server Memory] can be individually attributed to sessions.  (For example, consider the plan cache within [Stolen Server Memory].  Although an individual session inserts a plan into cache, while the plan is cached other sessions can use it.  And a cached plan can stay in cache after the session that originally inserted it has ended.)

It just so happens I have some graphs. Each of the red vertical lines below is an OOM.  Usually in a graph like this I have [Stolen Server Memory] at the top of the stacked graph, with [Free Memory] and [Database Cache Memory] below it.  Like this...



But since I want to focus on [Stolen Server Memory] I want it at the bottom of the stack for now, like this...



In the workloads I am concerned with, the largest portion of individually attributable [Stolen Server Memory] is the amount of granted query memory that is used for sort/hash/columnstore compression at any given time.  If all user workload groups are associated with the Default Resource Pool, that amount is [\SQLServer:Memory Manager\Granted Workspace Memory (KB)] - [\SQLServer:Memory Manager\Reserved Server Memory (KB)].  If user Resource Pools other than Default during the timeperiod of concern, the information should be gathered from sys.dm_exec_query_memory_grants and/or sys.dm_exec_query_resource_semaphores to account for the total granted and total reserved memory.

Fortunately for me, on this day the only resource pools present were Default and Internal.  A little bit easier path.

The next graph is the amount of granted memory (not necessarily already used), with [\SQLServer:Memory Manger\Total Server memory (KB)] included on the same graph for scale.

First of all, I'll point out that the total granted memory is not very high compared to the target server memory. Also, the yellow box indicates high points for granted memory that occurred without errors, while errors occurred later with lower levels of granted memory.


Let's zoom in a little for better visibility.  This graph is granted memory - but it doesn't indicate how much of the granted memory is used.



Because on the Default resource pool was in play, layering the reserved memory in front of granted memory gives an idea of the used query memory.  In the graph below, the exposed dark green is the portion of [\SQLServer:Memory Manager\Granted Workspace Memory (KB)] which is used. 



well, well...



well, well....






Date,Source,Severity,Message
12/21/2019 03:15:35,spid83,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670319<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:17:51,spid79,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670319<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:24:14,spid51,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670319<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:36:41,spid73,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670319<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:43:01,spid89,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670319<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:47:00,spid55,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670319<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:50:43,spid57,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34670740<nl/>Simulated                                    166692<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                    0
12/21/2019 03:54:08,spid73,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639426<nl/>Simulated                                    250762<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 03:56:07,spid73,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639426<nl/>Simulated                                    250762<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 03:58:37,spid73,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639426<nl/>Simulated                                    250762<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 04:00:43,spid52,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639426<nl/>Simulated                                    250762<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 04:03:27,spid70,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639437<nl/>Simulated                                    250718<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 04:05:45,spid74,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639437<nl/>Simulated                                    250718<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 04:09:38,spid70,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      34639440<nl/>Simulated                                    250706<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 04:15:57,spid107,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      21670985<nl/>Simulated                                   2875695<nl/>Simulation Benefit                                0<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070
12/21/2019 04:23:20,spid94,Unknown,Memory Broker Clerk (Column store object pool)      Pages<nl/>---------------------------------------- ----------<nl/>Total                                      21660293<nl/>Simulated                                   2892211<nl/>Simulation Benefit                       0.0000000000<nl/>Internal Benefit                                  0<nl/>External Benefit                                  0<nl/>Value Of Memory                                   0<nl/>Periodic Freed                                    0<nl/>Internal Freed                                84070

well, well...


Memory Broker Clerk (Column store object pool)
Time               Pages            kb
03:15:35           34670319         277362552
03:17:51           34670319         277362552
03:24:14           34670319         277362552
03:36:41           34670319         277362552
03:43:01           34670319         277362552
03:47:00           34670319         277362552
03:50:43           34670740         277365920
03:54:08           34639426         277115408
03:56:07           34639426         277115408
03:58:37           34639426         277115408
04:00:43           34639426         277115408
04:03:27           34639437         277115496
04:05:45           34639437         277115496
04:09:38           34639440         277115520
04:15:57           21670985         173367880
04:23:20           21660293         173282344

a haw haw haw...

Thursday, April 16, 2020

SQL Server 2017 cu17 ColumnStore Workload OOMs Part 1

A support ticket concerning this behavior is open with Microsoft.  SQL Server 2017 CU20 has not been evaluated for this behavior.  Although no published fix included in CU20 appears to address this behavior, it's possible additional affects of the documented fixes address the behavior.  Its also possible an undocumented CU20 fix addresses this behavior.  However, as CU20 has never been brought up in the context of the support ticket, and - as can be seen at the end of this blog post - Microsoft has previously documented fixes to similar behavior, I currently believe this behavior is likely to exist in SQL Server 2017 CU20 as well as CU17, CU18, and CU19.

Let's start the story with a SQL Server 2017 CU17 service restart on December 20, 2019.

All of the graphs below unless otherwise noted are from perfmon, captured in 30 second increments.

It's a VMware VM, with Windows Server 2016 as the operating system. Global startup trace flags 4199 (optimizer hotfixes), 4139 (quickstats histogram amendments), 3226 (no errorlog messages for successful t-log backups). Nothing too surprising there.

This vm has 56 vcpu and 620 GB vRAM.

[Max Server Memory] is set to 590000 mb.


12/20/2019 11:03:24,spid8s,Unknown,SQL Server shutdown has been initiated      
12/20/2019 11:03:24,spid8s,Unknown,SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.      
12/20/2019 11:03:25,Server,Unknown,Microsoft SQL Server 2017 (RTM-CU17) (KB4515579) - 14.0.3238.1 (X64) <nl/> Sep 13 2019 15:49:57 <nl/> Copyright (C) 2017 Microsoft Corporation<nl/> Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: ) (Hypervisor)   
12/20/2019 11:03:25,Server,Unknown,UTC adjustment: -6:00      
12/20/2019 11:03:25,Server,Unknown,(c) Microsoft Corporation.      
12/20/2019 11:03:25,Server,Unknown,All rights reserved.      
12/20/2019 11:03:25,Server,Unknown,Server process ID is 12764.      
12/20/2019 11:03:25,Server,Unknown,System Manufacturer: 'VMware<c/> Inc.'<c/> System Model: 'VMware Virtual Platform'.      
12/20/2019 11:03:25,Server,Unknown,Authentication mode is MIXED.      
12/20/2019 11:03:25,Server,Unknown,Logging SQL Server messages in file 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Log\ERRORLOG'.      
12/20/2019 11:03:25,Server,Unknown,The service account is '***redacted***'. This is an informational message; no user action is required.      
12/20/2019 11:03:25,Server,Unknown,Registry startup parameters: <nl/>  -d C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\master.mdf<nl/>  -e C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Log\ERRORLOG<nl/>  -l C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\mastlog.ldf<nl/>  -T 4199<nl/>  -T 4139<nl/>  -T 3226
12/20/2019 11:03:25,Server,Unknown,Command Line Startup Parameters:<nl/>  -s "MSSQLSERVER"
12/20/2019 11:03:25,Server,Unknown,SQL Server detected 28 sockets with 2 cores per socket and 2 logical processors per socket<c/> 56 total logical processors; using 56 logical processors based on SQL Server licensing. This is an informational message; no user action is required.

When [Max Server Memory] can be attained by SQL Server, [Target Server Memory] will be equal to [Max Server Memory].  If memory conditions external to SQL Server make [Max Server Memory] unattainable, [Target Server Memory] will be adjusted downward to an attainable value. As workload is placed on the system, [Total  Server Memory] grows toward [Target Server Memory].  That's typical, expected behavior.

In this case, the story stays boring until after the following midnight.  There wasn't enough workload to drive much growth of [Total Server Memory] until about 2:15 am, after which [Total Server Memory] grew fairly rapidly.  [Total Server Memory] reached a plateau between 3:00 am and 3:15 am, and then stepped slightly down later.  [Target Server Memory] was never attained.  That's curious.


[Total Server Memory] is the sum of [Database Cache Memory], [Free Memory], and [Stolen Memory] for the instance.  Here's a graph of those three memory categories over the same timeperiod.


It really is quite curious that [Total Server Memory] never reached [Target Server Memory] and in fact eventually backed *farther off* from [Target Server Memory].  If external factors made [Target Server Memory] unattainable, I expect [Target Server Memory] to be adjusted downward.  But that didn't happen.

I'm a very curious guy, but I don't spend days worth of time creating and staring at graphs of the same short timeperiod simply out of curiosity.  This morning timeperiod encompassed 16 SQL Server out-of-memory errors.  I want to be able to diagnose them, and find out when the contributing behavior was introduced, in order to advise organizations that are planning SQL Server upgrades - or that fall prey to the type of OOMs experienced in this instance.

I'm going to tighten the timeframe for the remaining graphs to 2:30 am to 5:00 am, in order for the individual errors to be discernable on the graphs.

There are the 16 OOMs, each marked with a vertical red line in the graph below.  Interestingly, they occur during the plateau of [Total Server Memory].  But... SQL Server is still a long way off from reaching [Target Server Memory]... why not just grow SQL Server's memory share?

As I mentioned before, if external memory conditions made [Target Server Memory] unattainable, I expect [Target Server Memory] to be lowered.  That didn't happen, hinting that sufficient memory was still present for [Total Server Memory] to grow.

What does perfmon have to say about [Available Memory]?  Does it corroborate my conclusion that SQL Server *could have* continued to grow [Total Server Memory]?  Sure 'nuf.  At the time of *all 16* of the OOMs, there was over 100GB of [Available Memory], nicely divided across the 2 vNUMA nodes.

Those familiar with my memory graphs on this blog and in my twitter activity as @sqL_handLe may note that I'm usually much more preoccupied with [Free & Zero Page List Memory] than with [Available Memory].  Depending on the memory consumers and activity on a VM, there may be considerable memory accounted as [Available Memory] which is not [Free & Zero Page List Memory].  If a memory allocation for a consumer must be zeroed before handed over, it's gotta come from [Free & Zero Page List Memory] (which I often affectionately call FZPL).

Thankfully in this case, FZPL is nearly all of [Available Memory] and is similarly well-divided between the vNUMA nodes.



So [Available Memory] and [Free & Zero Page List Memory] are plentiful and balanced between the two vNUMA nodes.  Can we see how much of SQL Server [Total Server Memory] is on each of the SQLOS nodes?  Yup.  Meet my friend [Total Node Memory].  Equally balanced across the two SQLOS nodes.



In fact, the categories of [Database], [Stolen], and [Free] SQLOS memory can be tracked at SQLOS node level, too.  Pretty nice balance on nodes 000 and 001.



Extracted from the SQL Server errorlog, here are the 16 OOMs from that night.


12/21/2019 03:15:27,spid83,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:17:43,spid79,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 8
12/21/2019 03:24:02,spid51,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 8
12/21/2019 03:36:37,spid73,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:42:54,spid89,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:46:54,spid55,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:50:36,spid57,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:53:56,spid73,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:55:57,spid73,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 03:58:28,spid73,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 04:00:39,spid52,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 04:03:14,spid70,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 16
12/21/2019 04:05:34,spid74,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1
12/21/2019 04:09:26,spid70,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 24
12/21/2019 04:15:44,spid107,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 8
12/21/2019 04:23:14,spid94,Unknown,Failed to allocate BUFs: FAIL_BUFFER_ALLOCATION 1

So here's the summary of the story: 16 OOMs occurred in one night.  The instance hadn't reached [Target Server Memory], and there doesn't seem to be a good reason for [Total Server Memory] to *not* have grown rather than incur an OOM.  There was over 50GB of FZPL per vNUMA node, for goodness sake!  Memory use seems to have been quite evenly divided between the vNUMA nodes.

For the last two OOMs, at 4:15 am and 4:23 am, there was even a large amount of [Free] SQLOS memory within [Total Server Memory].  And there was plenty of [Free] SQLOS memory on either of the two SQLOS nodes!!  The possibility of SQLOS [Total] memory growth at the time of any of the 16 OOMs, and the additional presence of significant SQLOS [Free] memory on either SQLOS node during the last 2 OOMs fully convinces me that this is a bug.  (Well, that and not having seen this type of behavior in any of the SQL Server 2016 or 2019 versions I've worked with.)

When the dust clears from this, I think a bug similar to this one from SQL Server 2017 cu10 will be found.  I am upset at myself that in 5 months of staring down *this* behavior, I haven't been able to marshal the resources to get *this* bug properly identified so it can be corrected.

FIX: Out of memory error occurs even when there are many free pages in SQL Server
https://support.microsoft.com/en-us/help/4347088/fix-out-of-memory-error-when-there-are-free-pages-in-sql-server

The fix referenced above, kb4347088, is found in SQL Server 2017 cu10 and SQL Server 2016 sp2 cu3.  The problem described in this blog post shares some similarities, and has been observed on SQL Server 2017 cu17, cu18, and cu19.  As of 2020 April 16 this bug has not been identified and there is no fix imagined or planned.