• It enabled us to bring other SQL Server products like SSIS to Linux
• It enabled majority of the SQL Server team to continue focusing  on core  features;  operating with cloud first mentality; delivering  SQL Azure and SQL DW m0nthly. At the same time a team that has been responsible for brining SQL Server to Linux remained small and focused on system level work rather than porting other teams changes.
• It helped us to bring SQL Server scalability and performance to Linux. Over the years we have tuned SQL Server to run efficiently on enterprise grade hardware. With only few changes in SQLPAL and no changes to the core engine, we have unleashed SQL Server's beast mode on Linux.
• It simplified investments around supportability.  Few people know that while running on Linux, SQL Server generates the same supportability artifacts as on Windows. The approach significantly simplifies supportability story on multiple platforms.  And magically, SQL Server engineers continue leveraging the same tools for debugging even if core-dumps come from Linux.

Well, I think we might want to remember this day…

See attached picture

I can connect and run queries.

1> select * from sys.dm_os_schedulers 2> go scheduler_address parent_node_id scheduler_id cpu_id status ------------------ -------------- ------------ ----------- ----------------------------------- 0x00000000DC190040 0 0 0 VISIBLE ONLINE 0x00000000DC1A0040 0 1 1 VISIBLE ONLINE 0x00000000DC1B0040 0 2 2 VISIBLE ONLINE 0x00000000DC1C0040 0 3 3 VISIBLE ONLINE 0x00000000DC1D0040 0 4 4 VISIBLE ONLINE 0x00000000DC1E0040 0 5 5 VISIBLE ONLINE 0x00000000DC1F0040 0 6 6 VISIBLE ONLINE 0x00000000DC580040 0 7 7 VISIBLE ONLINE 0x00000000DC590040 0 1048578 0 HIDDEN ONLINE 0x00000000DCC10040 64 1048576 0 VISIBLE ONLINE (DAC) 0x00000000DCC60040 0 1048579 1 HIDDEN ONLINE 0x00000000DCC70040 0 1048580 2 HIDDEN ONLINE 0x00000000D6460040 0 1048581 3 HIDDEN ONLINE

(13 rows affected) 1> select @@ver 2> go Msg 137, Level 15, State 2, Server CLIENT, Line 1 Must declare the scalar variable "@@ver". 1> SELECT @@VERSION 2> go

---------------------------------------------------------------------------------------------- Microsoft SQL Server 2014 - 12.0.2000.8 (X64) Feb 20 2014 20:04:26 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.2 (Build 9200: ) (Hypervisor)

(1 rows affected)

SqlServer thinks it is running on HV ;-) but it really runs on L!

Have a great weekend

-Slava

It was sad for me to move out of SQL Server. I just love the team and product. However I couldn't let go such great opportunity :-).  In the future expect my posts to become more operating system related - Yes I will try to continue blogging as I gain more knowledge and experience.  At the same time please don't hesitate to ask questions about SQL Server, if I don't have answers I will forward them to people that do. To some of you I owe email replies. I am sorry for being slow in that regard but I will try to catch up in the next week or so.

By the way if you have passion in operating system area, consider yourself hard working and fun person, feel free to contact me, we might need you :-).

 Change is always good and I really enjoy it :-).

As usual if you have questions don't hesitate to ask. 

Q: What kind of ratio should you expect to see between AWE Allocated and VM Committed/Reserved?  We are running 8GB with a cap of 7GB in the max server memory and yet the VM Committed is around 100MB.  I was first shocked to see that the sqlservice in task manager only shows that SQL is using around 100MB and now that I have used MEMORYSTATUS I'm even more troubled.Does this mean that our server is starved for memory even though AWE can see almost all of the 7GB?  On a side note we are seeing very high CPU utilization and my trail has come to a potential memory issue.

Memory Manager                  KB

------------------------------ --------------------

VM Reserved                    1674140

VM Committed                   104384

AWE Allocated                  6747704

Reserved Memory                1024

Reserved Memory In Use         0

A. Actually these two values are independent. VM Committed shows amount of physical memory SQL Server allocated using VirtualAlloc's MEM_COMMIT parameter. AWE allocated shows amount of memory allocated using AllocateUserPhysicalPages. Sum of these two counters gives an approximate amount of physical memory SQL Server uses. The reason it is an approximate amount is because some external components loaded in SQL Server address space allocate memory outside of SQL Server memory manager framework. Consequently it is impossible to output exact amount. 

In your case you shouldn't worry - SQL Server does use physical memory you configured it to use. High CPU utilization that your system experience might be due to memory pressure or to other reasons. You need to find out if SQL Server hits memory pressure and if it does classify it and fix it appropriately.  You can find more on memory pressure in my previous posts related to memory: http://blogs.msdn.com/slavao/archive/tags/SQL+Server+Memory+Management/default.aspx or in recently published book on SQL Server 2005 troubleshooting http://www.amazon.com/o/ASIN/0321447743/ref=s9_asin_image_1/002-4273860-1748002. The book contains a chapter on how SQL Server memory manager works as well as how to recognize and fix different types of memory related issues.

One can run lots of interesting queries using this view.  You can even use this view to perform deadlock detection that is not resolvable by deadlock monitor, DM. For example if you have tasks waiting on external resources such as extended stored procedures and blocking others from running. This type of deadlock DM can’t detect but you can!

1. Q. How many tasks are currently waiting?

select

count(*)

from

sys.dm_os_waiting_tasks

This query will give you an idea of how many tasks are waiting in the system. You can use this information to understand blocking characteristics of your load

2. Q. How many tasks that assigned to a worker (thread/fiber) are waiting?

select

      count(*)

from

      sys.dm_os_waiting_tasks

where

      wait_type <> 'THREADPOOL’

This query shows how many threads are actively running in the system. Latter on I will show how to find out if number of threads can be increased

3. What are the tasks waiting on?

select

      wait_type,

      count (*)

from

      sys.dm_os_waiting_tasks

group by

      wait_type

order by

      count (*) desc

One can use this query to investigate possible bottlenceks of an active load. This query groups tasks by wait type – it can’t be directly use to identify the actual bottlenecks on the system. The query gives you an idea about the wait characteristics of your load

4. Q. Does my load have an active resource bottleneck?

You can answer this question by looking at the resource address that tasks are blocked on.  Keep in mind that not all wait types have resource associated with them.

select

      resource_address,

      count (*)

from

      sys.dm_os_waiting_tasks

WHERE

      resource_address <> 0

group by

      resource_address

order by

      count (*) desc

5. Q: Is my system can be possibly bottlenecked on I/O?

You can answer this question by looking at the wait type of tasks waiting on specifically you are interested in IO waits

select

      *

from

      sys.dm_os_waiting_tasks

where

      wait_duration_ms > 20 AND

      wait_type LIKE '%PAGEIOLATCH%'

You might want to change 20ms base on your I/O subsystem

6. Q: Does my load have long waiting chains?

This information is particular interesting to understand if a single tasks, for example one that generated long I/O, blocks others. If this happens you will have a way to improve your scalability by figuring how to remove or minimize chain length.

WITH TaskChain (

waiting_task_address,

blocking_task_address,

ChainId,

Level)

AS

(

-- Anchor member definition: use self join so that we output

-- Only tasks that blocking others and remove dupliates

 SELECT DISTINCT

      A.waiting_task_address,

      A.blocking_task_address,

      A.waiting_task_address As ChainId,

    0 AS Level

FROM

      sys.dm_os_waiting_tasks as A

JOIN

      sys.dm_os_waiting_tasks as B

ON

      A.waiting_task_address = B.blocking_task_address

WHERE

      A.blocking_task_address IS NULL

UNION ALL

-- Recursive member definition: Get to the next level waiting

-- tasks

SELECT

      A.waiting_task_address,

      A.blocking_task_address,

      B.ChainId,

      Level + 1

from

      sys.dm_os_waiting_tasks AS A

JOIN

      TaskChain AS B

ON

      B.waiting_task_address = A.blocking_task_address

)

select

      waiting_task_address,

      blocking_task_address,

      ChainId,

      Level 

from

      TaskChain

order by

      ChainId

If there are no chains, your load is not CPU bound and you see long waits on THREADPOOL, you might improve your throughput by increasing a number of threads in the system.

Keep in mind that you can extend this query to perform your own deadlock detection.

You can also find out more information about each individual wait_type here

http://msdn2.microsoft.com/en-us/library/ms179984.aspx

1. Q. Do I need to by more CPUs?

In order to answer this question you have to find out if your load is really CPU bounded.  Your load is really CPU bounded if a number of runnable tasks per each scheduler always greater than 1 and all of your queries have correct plan.  The latter statement is very important, your load can be CPU bounded due to the fact that somehow optimizer generated bad plan – it can happen if your statistics out of date or you tried to perform handcrafted optimization. In this case you don’t want to run to Circuit City to buy more CPUs right a way – you want to fix the plan. Here is the query to find out average length of a runable queue on the system:

select

AVG (runnable_tasks_count)

from

sys.dm_os_schedulers

where

status = 'VISIBLE ONLINE'

Buying more CPUs has also to do with capacity planning. You have to be very careful when performing capacity planning on hardware with HT enabled – remember you don’t have extra physical CPUs. Keep in mind that if your load runs at 60% CPU utilization - it doesn’t mean that you have 40% of extra CPU capacity. You will be very surprise how fast CPU load will jump from 60% to 80% and then even faster to 100% once you apply more and more load.

2. Q. What is affinity of my schedulers to CPUs?

select

      scheduler_id,

      CAST (cpu_id as varbinary) AS scheduler_affinity_mask

from

sys.dm_os_schedulers

3. Does my machine have either hard or soft NUMA configuration enabled?

select

      CASE count( DISTINCT parent_node_id)

      WHEN 1 THEN 'NUMA disabled'

      ELSE 'NUMA enabled'

      END

from

      sys.dm_os_schedulers

where parent_node_id <> 32

4. Q. Should I configure SQL Server to use more threads – sp_configure ‘max server threads’?

You can answer this question by looking at the work queue length for each scheduler. If on average such value is above 1 then you might benefit from adding more threads to the system but only if

A.  Your load currently is not CPU bounded (See info above on how to find out if your load is CPU bound)

B. Your load currently doesn’t experience any other heavy waits (If you add more threads in this case they will just end up waiting as everyone else)

select

AVG (work_queue_count)

from

sys.dm_os_schedulers

where

status = 'VISIBLE ONLINE'

5. Q: Is my system I/O bound?

You can answer this question by monitoring length of I/O queues.

select

      pending_disk_io_count

from

      sys.dm_os_schedulers

 If over time they keep on growing or you are seeing periodic jumps or numbers stay relatively high most likely your system is I/O bound. In order to identify the cause you will have to dive further.

So in order to make you life a bit easier, I would like to start series of posts dedicated to SQLOS DMVs with emphasis on actual problems.

Following set of DMVs is exposed by SQLOS or SQLOS related infrastructures.

sys.dm_os_sys_info

sys.dm_os_schedulers

sys.dm_os_waiting_tasks

sys.dm_os_wait_stats

sys.dm_os_systhrteads

sys.dm_os_virtual_address_dump

sys.dm_os_latch_stats

sys.dm_os_hosts

sys.dm_os_buffer_descriptors

sys.dm_os_perf_counters

sys.dm_os_ring_buffers

sys.dm_os_tasks

sys.dm_os_workers

vsys.dm_os_memory_clerks

sys.dm_os_memory_cache_counters

sys.dm_os_memory_cache_clock_hands

sys.dm_os_memory_cache_hash_tables

sys.dm_os_memory_cache_entries

dbcc memorystatus

I listed them in a random order J. You can find description for each one of them in BO so I won’t repeat the description here. The main point is figure out, understand, how to make use of them.

Once we are done with all posts you will be able to:

-         Find out if you need to buy more CPUs

-         Find out if you need to buy more memory

-         Find out if you running under memory pressure

-         Find out if you have problems with disks

-         Find out if you need to move to 64bit based solution

-         Find out if you need to change your application in order to take advantage of force parameterization

-         Find out what applications you loaded in SQL Server address space

-         Find out if SQL Server is paged out and if it affects performance of your application

-         Find out if your hardware is NUMA

-         And much more

So here it goes:

sys.dm_os_sys_info

1. Q. How many sockets does my machine have?

select

cpu_count/hyperthread_ratio AS sockets

from

sys.dm_os_sys_info

2. Q. Is my machine hyper threaded?

Well unfortunately you can’t derive this information using this DMV today though there is a column called hyperthread_ratio. On the other hand this column can tell you:

Q. How many either cores or logical CPU share the same socket?

select

hyperthread_ratio AS cores_or_logical_cpus_per_socket

from

sys.dm_os_sys_info

3. Q. Does my 32 bit system have /3GB or /Userva switch in boot.ini?

select

     CASE

           WHEN virtual_memory_in_bytes / 1024 / (2048*1024)

< 1 THEN 'No switch'

           ELSE '/3GB'

     END

from sys.dm_os_sys_info

4. Q. How much physical memory my machine has?

select

      physical_memory_in_bytes/1024 AS physical_memory_in_kb

from

      sys.dm_os_sys_info

5. Q. How many threads/workers SQL Server would use if the default value in sp_configure for max worker threads is zero:

select

      max_workers_count

from

      sys.dm_os_sys_info

6. Q. What is a size of AWE window or what is the max amount of memory right now that can be used by QO, QE and Caches simultaneously when SQL Server running in AWE mode?

select

      bpool_visible

from

      sys.dm_os_sys_info

I will be happy to answer your questions.