TokenAndPermUserStore Clear giảm mức sử dụng CPU trong một khoảng thời gian ngắn

Giới thiệu

Nói tóm lại, có rất nhiều truy vấn ad hoc xuất hiện trên máy chủ của tôi, từ một ứng dụng mà tôi không kiểm soát và không thể thay đổi (Ngay cả việc đẩy các chỉ mục cũng khó khăn và chúng sử dụng nhiều đống ...).

Thông số kỹ thuật

Hệ điều hành - Windows Server 2012 R2 (Nút chính) Máy chủ SQL 2014 - 12.0.5546

Luôn bật AG Với nút đồng bộ thứ cấp có cùng phần cứng + Build.

Chúng tôi chỉ có thể sử dụng 12 trong số 24 lõi cho máy chủ sql do cấp phép (tôi đã không làm điều này). Nó khá dễ dàng để phát hiện 12 lõi;).

Vấn đề

Bây giờ là vấn đề của tôi. Hiện tại, cứ sau 30 phút chúng tôi lại xóa "TokenAndPermUserStore". Điều này đã xảy ra trên máy chủ ngay cả trước khi nó đến trong tay tôi. Chúng tôi đã làm điều này với lệnh:

DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Tôi sử dụng truy vấn này để kiểm tra bộ đệm:

SELECT SUM(pages_kb) / 1024  AS 
   "CurrentSizeOfTokenCache(mb)" 
   FROM sys.dm_os_memory_clerks 
   WHERE name = 'TokenAndPermUserStore'

Ngay sau khi xóa, đây là kích thước bộ đệm:

CurrentSizeOfTokenCache(mb)
1602

Tại một thời điểm nhất định, ví dụ 15 phút sau khi rõ ràng đây là kích thước bộ đệm:

CurrentSizeOfTokenCache(mb)
1976

Cập nhật: Bây giờ, khi CPU được sử dụng ổn định trở lại (40% được sử dụng (20% khi theo dõi), bộ đệm sẽ thấp hơn điểm thấp nhất khi mức sử dụng CPU cao.

CurrentSizeOfTokenCache(mb)
1281

Một ví dụ của ngày hôm qua:

Những giọt rất hiện diện trên bức ảnh của ngày hôm qua: (Lưu ý vì chúng ta có thể sử dụng 12 trong số 24 lõi, 50% có nghĩa là 100% trong phần mềm giám sát, nói cách khác, việc sử dụng cpu có thể sẽ không vượt quá 50% vì nó được dành riêng cho chỉ máy chủ sql)

Một điều quan trọng cần lưu ý là, chúng tôi đã thêm hai chỉ mục quan trọng vào các truy vấn hàng đầu vào ngày hôm qua, vì CPU gần như phẳng, giúp trong một thời gian ngắn, nhưng cpu đã tăng trở lại mức tương tự, không có truy vấn đáng chú ý nào nên hệ thống của chúng tôi khó khăn này.

Câu hỏi

Bây giờ, với câu hỏi của tôi, hôm nay, tôi đã cố gắng xóa bộ nhớ cache thường xuyên hơn, bằng cách thực hiện

DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

một vài lần thủ công Nhưng dường như, sau khoảng 20 giây, việc sử dụng cpu đã quay trở lại với một sự báo thù.

Bạn có thể thấy rõ ba dấu chấm sau khi thực hiện lệnh, nhưng nó quay lại khá nhanh trong hình dưới đây.

Tôi có nên lên lịch cho lệnh nhiều hơn, tôi có nên xem xét các thay đổi khác không?

Tôi biết rằng vấn đề này đã phổ biến trong SQL Server 2005, nhưng đây là SQL Server 2014. Các truy vấn là các truy vấn loại sp_executesql.

Nếu bạn cần thêm thông tin hoặc làm rõ, đừng ngần ngại cho tôi biết.

Cập nhật kể từ ngày 05/12/2018

Gói truy vấn: https://www.brentozar.com/pastetheplan/?id=BkUKKVByV

-> Dán gói đang tạo cùng một liên kết cho ba gói được tìm thấy. Tôi đã thử thêm cả ba gói XML được tìm thấy trong bộ đệm cho cùng một truy vấn, mỗi truy vấn có 10 lần thực hiện và có cùng một liên kết cho mỗi kế hoạch.

Truy vấn được sử dụng

    SELECT 
  text, execution_count,
dm_exec_query_stats.creation_time, dm_exec_query_plan.query_plan
FROM sys.dm_exec_query_stats 
CROSS APPLY sys.dm_exec_sql_text(dm_exec_query_stats.plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)

kết quả cho ba trong số các truy vấn giống nhau:

Tôi muốn lưu ý, các truy vấn đang sử dụng SNAPSHOT ISOLATION, bằng cách đặt nó trước khi thực hiện truy vấn và sử dụng gợi ý TÙY CHỌN (KEEP PLAN, KEEPFIXED PLAN, LOOP THAM GIA)

Truy vấn 1

(@SV1 nvarchar(8),@SV2 nvarchar(8),@SV3 nvarchar(8),@SV4 nvarchar(8),@SV5 nvarchar(8),@SV6 nvarchar(8),@SV7 nvarchar(8),@SV8 nvarchar(8),@SV9 nvarchar(8),@SV10 nvarchar(8),@SV11 nvarchar(8),@SV12 nvarchar(8),@SV13 nvarchar(8),@SV14 nvarchar(8),@SV15 nvarchar(8),@SV16 nvarchar(8),@SV17 nvarchar(8),@SV18 nvarchar(8),@SV19 nvarchar(8))  IF @@TRANCOUNT = 0 SET TRANSACTION ISOLATION LEVEL SNAPSHOT  SELECT AA.[SourceCode],AA.[DOUBLEMEDICATIONSVALIDATED],AA.[BSTNUM],AA.[MUTKOD],AA.[VERVALLEN],AA.[BACKUPID],AA.[LAATSTE],AA.[ExterneCode],AA.[PRKODE],AA.[NMMEMO],AA.[NMETIK],AA.[NMNM40],AA.[NMNAAM],AA.[PRNMNR],AA.[PRKBST],AA.[GPKODE],AA.[DRMLGEN],AA.[Anticoagulant],AA.[HPKSubstancesDiff],AA.[HPKCIsDiff],AA.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AA  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AA.[PRKODE] = A.[DMPRKA])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT AB.[SourceCode],AB.[DOUBLEMEDICATIONSVALIDATED],AB.[BSTNUM],AB.[MUTKOD],AB.[VERVALLEN],AB.[BACKUPID],AB.[LAATSTE],AB.[ExterneCode],AB.[PRKODE],AB.[NMMEMO],AB.[NMETIK],AB.[NMNM40],AB.[NMNAAM],AB.[PRNMNR],AB.[PRKBST],AB.[GPKODE],AB.[DRMLGEN],AB.[Anticoagulant],AB.[HPKSubstancesDiff],AB.[HPKCIsDiff],AB.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AB  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AB.[PRKODE] = A.[DMPRKB])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ORDER BY A.[DMPRKA] ASC,A.[DMPRKB] ASC  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)

Truy vấn 2

(@SV1 nvarchar(8),@SV2 nvarchar(8),@SV3 nvarchar(8),@SV4 nvarchar(8),@SV5 nvarchar(8),@SV6 nvarchar(8),@SV7 nvarchar(8),@SV8 nvarchar(8),@SV9 nvarchar(8),@SV10 nvarchar(8),@SV11 nvarchar(8),@SV12 nvarchar(8),@SV13 nvarchar(8),@SV14 nvarchar(8),@SV15 nvarchar(8),@SV16 nvarchar(8),@SV17 nvarchar(8),@SV18 nvarchar(8),@SV19 nvarchar(8))  IF @@TRANCOUNT = 0 SET TRANSACTION ISOLATION LEVEL SNAPSHOT  SELECT AA.[SourceCode],AA.[DOUBLEMEDICATIONSVALIDATED],AA.[BSTNUM],AA.[MUTKOD],AA.[VERVALLEN],AA.[BACKUPID],AA.[LAATSTE],AA.[ExterneCode],AA.[PRKODE],AA.[NMMEMO],AA.[NMETIK],AA.[NMNM40],AA.[NMNAAM],AA.[PRNMNR],AA.[PRKBST],AA.[GPKODE],AA.[DRMLGEN],AA.[Anticoagulant],AA.[HPKSubstancesDiff],AA.[HPKCIsDiff],AA.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AA  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AA.[PRKODE] = A.[DMPRKA])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT AB.[SourceCode],AB.[DOUBLEMEDICATIONSVALIDATED],AB.[BSTNUM],AB.[MUTKOD],AB.[VERVALLEN],AB.[BACKUPID],AB.[LAATSTE],AB.[ExterneCode],AB.[PRKODE],AB.[NMMEMO],AB.[NMETIK],AB.[NMNM40],AB.[NMNAAM],AB.[PRNMNR],AB.[PRKBST],AB.[GPKODE],AB.[DRMLGEN],AB.[Anticoagulant],AB.[HPKSubstancesDiff],AB.[HPKCIsDiff],AB.[HPKUndesiredGroupsDiff]  FROM [dbo].[ZINDEX_050] AB  WHERE EXISTS (SELECT NULL  FROM (SELECT TOP 100 PERCENT  A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ) A  WHERE AB.[PRKODE] = A.[DMPRKB])  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)    SELECT A.[BSTNUM],A.[MUTKOD],A.[VERVALLEN],A.[BACKUPID],A.[DMPRKA],A.[DMPRKB],A.[DMCODE],A.[DMGRDCODE]  FROM [dbo].[ZINDEX_671] A  WHERE ((A.[VERVALLEN] = 0 OR A.[VERVALLEN] IS NULL) AND ((A.[DMPRKA] = @SV1 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV4) OR  (A.[DMPRKA] = @SV5 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV6 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV7) OR  (A.[DMPRKA] = @SV8 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV9 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV10) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV11) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV12) OR  (A.[DMPRKA] = @SV13 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV14) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV15) OR  (A.[DMPRKA] = @SV16 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV17 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV18 AND A.[DMPRKB] = @SV2) OR  (A.[DMPRKA] = @SV3 AND A.[DMPRKB] = @SV19)))  ORDER BY A.[DMPRKA] ASC,A.[DMPRKB] ASC  OPTION (KEEP PLAN, KEEPFIXED PLAN, LOOP JOIN)

Thật đau lòng khi nhìn vào, tôi biết.

Biên dịch ngay cả với tham số bắt buộc

Các biên dịch / giây khớp với các đợt / Giây gần như 1 trên 1, ngay cả khi cho phép tham số hóa bắt buộc. Đó là lý do tại sao dòng lô / giây bị ẩn (nó nằm sau dòng biên dịch / giây).

Số liệu thống kê nước hoa:

Truy vấn, CPU, I / O khi cpu khoảng 80% và khi đó là khoảng 40%

Các aggreggates của các truy vấn được thực hiện trong khung thời gian 1u05 PM - 1u25 PM ngày hôm nay (sử dụng 80% Cpu):

Sử dụng CPU:

Có một sự khác biệt khi sử dụng cpu thấp hơn 2u05 PM - 2u25PM ngày hôm nay (mức sử dụng cpu 40%)

Sử dụng CPU:

Cái đầu tiên là cái mà chúng tôi đã thêm một chỉ mục khi chúng tôi thấy có vấn đề và làm cho việc sử dụng cpu ít hơn.

Truy vấn thêm với kiểm tra và thêm thông tin:

   select count(*) as amount_of_USERSTORE_TOKENPERM from sys.dm_os_memory_clerks
   where type = 'USERSTORE_TOKENPERM'

amount_of_USERSTORE_TOKENPERM
15190



     select count(*)  as amount_of_connections from sys.dm_exec_connections 
amount_of_connections
10004


       select  value_in_use from sys.configurations
       where name like '%access check cache bucket count%'

value_in_use
0
          select value_in_use from sys.configurations
       where name like '%access check cache quota%'
value_in_use
0

sql-server sql-server-2014

— Randi Vertongen
nguồn

Bạn đã thử kích hoạt tham số bắt buộc trên cơ sở dữ liệu liên quan chưa? Có một số nhược điểm - ví dụ, khó sử dụng các chỉ mục được lọc hơn - nhưng khi nó phù hợp, bạn ngay lập tức bắt đầu sử dụng lại kế hoạch, điều đó có nghĩa là tổng hợp ít hơn mỗi giây và CPU giảm xuống. (Nó dường như cũng làm giảm bộ nhớ cache TokenAndPermUserStore.)

— Brent Ozar

Bạn đã xác định chính xác điều gì gây ra việc sử dụng CPU cao chưa? Bạn chỉ nói "không có truy vấn đáng chú ý" nhưng sau đó thì sao? Tôi tự hỏi bao nhiêu TokenAndPermUserStore có tương quan so với quan hệ nhân quả.

— Aaron Bertrand

@sp_BlitzErik bạn không thể cấp phép ít hơn số lượng lõi trên máy chủ (hoặc vCores trên máy ảo). Xem download.microsoft.com/d

— David Browne - Microsoft

Máy chủ đó có 12 lõi, siêu phân luồng đến 24. Vì vậy, nó yêu cầu 12 giấy phép cốt lõi. Không có lý do cấp phép để đặt ái lực CPU, ngoài ra, nếu đặt ái lực CPU, họ nên chạy SQL trên 0,2,4, ... để tránh lập lịch hai tác vụ trên một lõi vật lý.

— David Browne - Microsoft

Nếu bạn tắt một ổ cắm trong BIOS thì nó không hiển thị trong Windows và bạn không thể truy cập một nửa bộ nhớ.

— David Browne - Microsoft

Hơn tất cả các bạn cho thời gian và nỗ lực của bạn trong việc tìm kiếm một giải pháp. Đặc biệt là @David Browne - Microsoft kể từ khi anh ấy đúng bằng cách cho tôi biết rằng chúng tôi nên vá.

Chúng tôi đã có một cuộc họp với các dba, chủ sở hữu ứng dụng và nhóm kỹ thuật của nhà cung cấp ứng dụng.

Trong cuộc họp này, người ta biết rằng vấn đề tương tự cũng xảy ra đối với các khách hàng khác mà nhà cung cấp gặp phải, do bản chất của ứng dụng và mã của nó.

Tương tự như thế này.

Giải pháp đã giúp các khách hàng khác của họ trong vấn đề này, là nâng cấp lên SQL Server 2014 CU7 hoặc SP3, mà chúng tôi sẽ thực hiện sớm nhất có thể (tốt nhất là SP3), điều này sẽ chấm dứt các vấn đề của 'tokenandpermuserstore'.

— Randi Vertongen
nguồn

Ý bạn là SQL Server 2014 SP2 CU7? Chúng tôi đang thấy một số hành vi kỳ lạ với bộ đệm cache USERSTORE_TOKENPERM (bản ghi 168k, lập kế hoạch xóa bộ nhớ cache thường xuyên) và tôi hy vọng đây có thể là một sửa chữa.

— Jacob H

Xin lỗi để tiếp tục bình luận nhưng tôi nghĩ bạn là người duy nhất trên hành tinh nhìn thấy vấn đề này. Nó dường như đến từ một trong những ứng dụng bên thứ 3 của chúng tôi sử dụng cách tiếp cận "thú vị" để xác thực với mạo danh và cũng tạo ra rất nhiều kết nối cho mỗi người dùng. Như bạn nói, việc xóa bộ đệm mã thông báo thường xuyên ổn định bộ đệm của gói tạm thời. Chúng tôi đang ở 2014 SP2 và nhà cung cấp chưa phê duyệt SP3 cụ thể. Tôi hy vọng 2014 SP2 CU7 có bản sửa lỗi.

— Jacob H

@JacobH Không có vấn đề, vấn đề của chúng tôi là sự kết hợp của hai. Cái đầu tiên vá ví dụ, cái thứ hai là bản cập nhật BIOS xảy ra trên máy phải gỡ bỏ. Cả hai điều này đã được nói với tôi bởi những người khác và tôi đã không tự mình thực hiện những thay đổi này vì tôi đang ở trong một dự án ngắn hạn với khách hàng vào thời điểm đó.

— Randi Vertongen

Bạn đã chạy bất cứ điều gì để xác định truy vấn nào đang đóng góp nhiều thời gian nhất cho nhân viên cpu hay chưa? Có lẽ một cái gì đó như dưới đây (thời gian là tính bằng micro giây)? Trong bài đăng ban đầu của bạn, tôi thấy bạn đã xác định được một số truy vấn - làm thế nào bạn xác định được những truy vấn đó có khả năng gây ra vấn đề.

select top 100 SUBSTRING(b.text,statement_start_offset / 2+1 ,   
  ( (CASE WHEN statement_end_offset = -1   
     THEN (LEN(CONVERT(nvarchar(max),b.text)) * 2)   
     ELSE statement_end_offset END)  - statement_start_offset) / 2+1), 
     convert(xml, c.query_plan), a.execution_count, 
a.total_worker_time, a.total_elapsed_time 
from sys.dm_exec_query_stats a 
cross apply sys.dm_exec_sql_text(a.sql_handle) b 
cross apply sys.dm_exec_text_query_plan(a.plan_handle, 
a.statement_start_offset, a.statement_end_offset) c
order by a.total_worker_time desc

Bạn có thấy rằng bạn có rất nhiều gói sử dụng một lần (thông qua dmv) hoặc bạn cho rằng do tốc độ biên dịch bạn đã hiển thị trong biểu đồ. Truy vấn dưới đây sẽ không tính đến các kế hoạch sử dụng một lần; tuy nhiên, nếu điều này không xảy ra, tôi có thể gửi cho bạn.

— Sqlgreas
nguồn

Kế hoạch sử dụng một lần là cao, không giả định. Kiểm tra với một truy vấn, nó là khoảng 50% tổng số kế hoạch. Tuy nhiên, điều đó không giải thích tại sao tôi có ba kế hoạch cho cùng một truy vấn, XML hoàn toàn khớp, nhưng các kế hoạch không được sử dụng lại. Tôi nghĩ rằng việc đọc từ bộ đệm cho đến bây giờ sẽ không có ích gì, vì CPU Flatlining chỉ xảy ra vào những thời điểm cụ thể. Đến bây giờ đã được vài tuần.

— Randi Vertongen

Bạn đã xem sys.dm_exec_plan_attribut chưa? Điều đó có thể cho bạn thấy lý do tại sao bạn có 3 kế hoạch cho cùng một truy vấn. Nếu bạn nhìn vào cột is_cache_key, nó sẽ cho bạn biết nếu thuộc tính được xem xét khi xác định liệu một kế hoạch được lưu trong bộ nhớ cache có thể được sử dụng hay nếu một cái mới cần được tạo.

— Sqlgreas