Skip to main content
added 101 characters in body
Source Link
Shanky
  • 19.1k
  • 4
  • 36
  • 58

Please dont treat this as answer, just trying to highlight few things. As per the Output of sys.dm_os_memory_nodes

I can see on both nodes VAS committed virtual_address_space_committed_kb is almost same 40 GB. But the reservation is significantly less on Node 1 which means SQL Server is not utilizing that node to its potential. Most of the workload is handled by Node 0. I have seen this in many NUMA nodes system but this is something either a bug or something relevant to how NUMA is configured. You have SP2 could you please move to SP3 CU 4 so that you are at least extended supported. may be, just may be this might resolve this behaviour.

Also note from output of sys.dm_os_nodes the active_worker_count is almost same. So SQL Server is reserving and committing more from Node 0. Really dont have idea why so may be a behaviour, may be a bug.

In such scenario since Node 1 is not loaded at all I would ignore PLE.

NOTE: Currently SQL Server does not have Locked pages in memory enabled, please enable it, it would require restart and then see if the behavior changes.

EDIT: Update from OP. Applying SQL Server 2014 to SP3 CU 4 seems to have resolved the issue.

Please dont treat this as answer, just trying to highlight few things. As per the Output of sys.dm_os_memory_nodes

I can see on both nodes VAS committed virtual_address_space_committed_kb is almost same 40 GB. But the reservation is significantly less on Node 1 which means SQL Server is not utilizing that node to its potential. Most of the workload is handled by Node 0. I have seen this in many NUMA nodes system but this is something either a bug or something relevant to how NUMA is configured. You have SP2 could you please move to SP3 CU 4 so that you are at least extended supported. may be, just may be this might resolve this behaviour.

Also note from output of sys.dm_os_nodes the active_worker_count is almost same. So SQL Server is reserving and committing more from Node 0. Really dont have idea why so may be a behaviour, may be a bug.

In such scenario since Node 1 is not loaded at all I would ignore PLE.

NOTE: Currently SQL Server does not have Locked pages in memory enabled, please enable it, it would require restart and then see if the behavior changes.

Please dont treat this as answer, just trying to highlight few things. As per the Output of sys.dm_os_memory_nodes

I can see on both nodes VAS committed virtual_address_space_committed_kb is almost same 40 GB. But the reservation is significantly less on Node 1 which means SQL Server is not utilizing that node to its potential. Most of the workload is handled by Node 0. I have seen this in many NUMA nodes system but this is something either a bug or something relevant to how NUMA is configured. You have SP2 could you please move to SP3 CU 4 so that you are at least extended supported. may be, just may be this might resolve this behaviour.

Also note from output of sys.dm_os_nodes the active_worker_count is almost same. So SQL Server is reserving and committing more from Node 0. Really dont have idea why so may be a behaviour, may be a bug.

In such scenario since Node 1 is not loaded at all I would ignore PLE.

NOTE: Currently SQL Server does not have Locked pages in memory enabled, please enable it, it would require restart and then see if the behavior changes.

EDIT: Update from OP. Applying SQL Server 2014 to SP3 CU 4 seems to have resolved the issue.

Source Link
Shanky
  • 19.1k
  • 4
  • 36
  • 58

Please dont treat this as answer, just trying to highlight few things. As per the Output of sys.dm_os_memory_nodes

I can see on both nodes VAS committed virtual_address_space_committed_kb is almost same 40 GB. But the reservation is significantly less on Node 1 which means SQL Server is not utilizing that node to its potential. Most of the workload is handled by Node 0. I have seen this in many NUMA nodes system but this is something either a bug or something relevant to how NUMA is configured. You have SP2 could you please move to SP3 CU 4 so that you are at least extended supported. may be, just may be this might resolve this behaviour.

Also note from output of sys.dm_os_nodes the active_worker_count is almost same. So SQL Server is reserving and committing more from Node 0. Really dont have idea why so may be a behaviour, may be a bug.

In such scenario since Node 1 is not loaded at all I would ignore PLE.

NOTE: Currently SQL Server does not have Locked pages in memory enabled, please enable it, it would require restart and then see if the behavior changes.