Các vấn đề hiệu suất lớn trên SQL Server sản xuất của chúng tôi, làm cách nào để khắc phục sự cố này?

Câu hỏi này về cơ bản là câu hỏi tiếp theo cho câu hỏi này:
Vấn đề hiệu năng kỳ lạ với SQL Server 2016

Bây giờ chúng tôi đã làm việc hiệu quả với hệ thống này. Mặc dù một cơ sở dữ liệu ứng dụng khác đã được thêm vào Máy chủ SQL này kể từ bài đăng cuối cùng của tôi.

đây là số liệu thống kê hệ thống:

• RAM 128 GB (Bộ nhớ tối đa 110 GB cho Máy chủ SQL)
• 4 lõi @ 2,6 GHz
• Kết nối mạng 10 GB
• Tất cả các lưu trữ là dựa trên SSD
• Tệp chương trình, tệp nhật ký, tệp cơ sở dữ liệu và tempdb nằm trên các phân vùng riêng biệt của máy chủ
• Máy chủ Windows 2012 R2
• Phiên bản VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools phiên bản 10.0.9, bản dựng 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 tháng 10 năm 2016 18:17:30 Bản quyền (c) Microsoft Corporation Standard Edition (64-bit) trên Windows Server 2012 R2 Standard 6.3 (Build 9600 :) (Hypervisor)

Hệ thống của chúng tôi hiện có vấn đề hiệu suất lớn. Sử dụng CPU rất cao và số lượng luồng:

Chờ số liệu thống kê của giám sát hoạt động (tôi biết nó không đáng tin cậy lắm)

Kết quả của sp_blitzfirst:

Kết quả của sp_cool:

Cài đặt máy chủ nâng cao (không may chỉ bằng tiếng Đức)

Cài đặt MAXDOP đã được tôi thay đổi.

Tôi biết rằng điều này có thể không phải là vấn đề với chính SQL Server . Đây có thể là một vấn đề với ảo hóa (vmware), liên quan đến mạng (tôi đã thử nghiệm điều này) hoặc chính ứng dụng. Tôi chỉ muốn đóng đinh nó xuống hơn nữa.

ASYNC_NETWORK_IO cao sẽ dẫn đến số lượng luồng cao cho quy trình máy chủ sqls? Tôi tưởng tượng nó kéo dài nhiều công nhân vì các chủ đề không thể được đóng lại. Có đúng không?

Tôi sẽ cung cấp bất kỳ thông tin bổ sung nào bạn cần. Cảm ơn trước sự ủng hộ của bạn!

BIÊN TẬP:

Kết quả của sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Ưu tiên 1: Sao lưu :

• Sao lưu vào cùng một ổ đĩa Nơi cơ sở dữ liệu cư trú - 5 bản sao lưu được thực hiện trên ổ E: \ trong hai tuần qua, nơi các tệp cơ sở dữ liệu cũng sống. Điều này thể hiện một rủi ro nghiêm trọng nếu mảng đó thất bại.

Ưu tiên 1: Độ tin cậy :

• DBCC CHECKDB cuối cùng tốt hơn 2 tuần tuổi

  • babtec_prod - CHECKDB thành công cuối cùng: 2017-08-20 00: 01: 01.513

  • D3PR - CHECKDB thành công cuối cùng: không bao giờ.

  • DEMO77 - CHECKDB thành công cuối cùng: 2016-02-23 20: 31: 38.590

  • FINP - CHECKDB thành công lần cuối: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - CHECKDB thành công cuối cùng: 2017-05-18 22: 10: 48.120

  • bậc thầy - CHECKDB thành công cuối cùng: không bao giờ.

  • mô hình

  • msdb

  • PROD77 - KIỂM TRA thành công lần cuối: 2016 / 02-23 21: 33: 24.343

Ưu tiên 10: Hiệu suất :

• Cửa hàng truy vấn bị vô hiệu hóa - Tính năng Cửa hàng truy vấn SQL Server 2016 mới chưa được bật trên cơ sở dữ liệu này.

  • babtec_prod

  • D3PR

  • DEMO77

  • CUỐI

  • GridVis_EnMs

Ưu tiên 50: Sự kiện DBCC :

• DBCC DROPCLEANBUFFERS - Schorsch người dùng đã chạy DBCC DROPCLEANBUFFERS 1 lần trong khoảng thời gian từ ngày 21 tháng 9 năm 2017 11:57 sáng đến ngày 21 tháng 9 năm 2017 11:57 sáng. Nếu đây là hộp sản xuất, hãy biết rằng bạn đang xóa tất cả dữ liệu khỏi bộ nhớ khi điều này xảy ra. Loại quái vật nào sẽ làm điều đó?

• DBCC SHRINK% - schorsch người dùng đã chạy tệp co lại 6 lần trong khoảng thời gian từ ngày 21 tháng 9 năm 2017 11:51 PM và Okt 4 2017 9:02 AM. Vì vậy, uh, họ đang cố gắng sửa chữa tham nhũng, hoặc gây ra tham nhũng?

• Sự kiện tổng thể - 287 sự kiện DBCC đã diễn ra trong khoảng thời gian từ ngày 19 tháng 9 năm 2017 1:40 PM và Okt 4 2017 3:20 PM. Điều này không bao gồm CHECKDB và các sự kiện DBCC thường lành tính khác.

Ưu tiên 50: Hiệu suất :

• Tăng trưởng tệp chậm PROD77 - 2 lần tăng trưởng mất hơn 15 giây mỗi lần. Xem xét thiết lập tự động phát triển tệp để tăng nhỏ hơn.

Ưu tiên 50: Độ tin cậy :

• Xác minh trang không tối ưu babtec_prod - Cơ sở dữ liệu [babtec_prod] có TORN_PAGE_DETMENT để xác minh trang. SQL Server có thể khó nhận biết và phục hồi hơn từ tham nhũng lưu trữ. Thay vào đó hãy xem xét sử dụng CHECKSUM.

Ưu tiên 100: Hiệu suất :

• Nhiều kế hoạch cho một truy vấn - 3576 kế hoạch có mặt cho một truy vấn duy nhất trong bộ đệm của kế hoạch - có nghĩa là chúng tôi có thể có vấn đề về tham số hóa.

Ưu tiên 110: Hiệu suất :

• Bảng hoạt động không có chỉ mục cụm

  • babtec_prod - Cơ sở dữ liệu [babtec_prod] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • D3PR - Cơ sở dữ liệu [D3PR] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • DEMO77 - Cơ sở dữ liệu [DEMO77] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • FINP - Cơ sở dữ liệu [FINP] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • GridVis_EnMs - Cơ sở dữ liệu [GridVis_EnMs] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

  • PROD77 - Cơ sở dữ liệu [PROD77] có nhiều đống - các bảng không có chỉ mục được nhóm - đang được truy vấn tích cực.

Ưu tiên 150: Hiệu suất :

• Khóa ngoại không đáng tin cậy

  • babtec_prod - Cơ sở dữ liệu [babtec_prod] có các khóa ngoại có thể bị vô hiệu hóa, dữ liệu đã được thay đổi và sau đó khóa được bật lại. Đơn giản chỉ cần bật khóa là không đủ để trình tối ưu hóa sử dụng khóa này - chúng ta phải thay đổi bảng bằng tham số VỚI KIỂM TRA KIỂM TRA CONSTRAINT.

  • D3PR - Cơ sở dữ liệu [D3PR] có các khóa ngoại có thể đã bị vô hiệu hóa, dữ liệu đã được thay đổi và sau đó khóa được bật lại. Đơn giản chỉ cần bật khóa là không đủ để trình tối ưu hóa sử dụng khóa này - chúng ta phải thay đổi bảng bằng tham số VỚI KIỂM TRA KIỂM TRA CONSTRAINT.

• Bảng không hoạt động mà không có chỉ mục cụm

  • D3PR - Cơ sở dữ liệu [D3PR] có nhiều đống - các bảng không có chỉ mục được nhóm - chưa được truy vấn kể từ lần khởi động lại cuối cùng. Đây có thể là các bảng sao lưu bất cẩn để lại phía sau.

  • GridVis_EnMs - Cơ sở dữ liệu [GridVis_EnMs] có nhiều đống - các bảng không có chỉ mục được nhóm - chưa được truy vấn kể từ lần khởi động lại cuối cùng. Đây có thể là các bảng sao lưu bất cẩn để lại phía sau.

• Kích hoạt trên Bảng babtec_prod - Cơ sở dữ liệu [babtec_prod] có 26 kích hoạt.

Ưu tiên 170: Cấu hình tệp :

• Cơ sở dữ liệu hệ thống trên ổ C

  • master - Cơ sở dữ liệu chủ có một tệp trên ổ C. Đưa cơ sở dữ liệu hệ thống vào ổ C sẽ có nguy cơ bị sập máy chủ khi hết dung lượng.

  • model - Cơ sở dữ liệu mô hình có một tệp trên ổ C. Đưa cơ sở dữ liệu hệ thống vào ổ C sẽ có nguy cơ bị sập máy chủ khi hết dung lượng.

  • msdb - Cơ sở dữ liệu msdb có một tệp trên ổ C. Đưa cơ sở dữ liệu hệ thống vào ổ C sẽ có nguy cơ bị sập máy chủ khi hết dung lượng.

Ưu tiên 170: Độ tin cậy :

• Kích thước tệp tối đa được đặt

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_data_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_data_idx_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_firm_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_firm_idx_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_log_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_phys_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_phys_idx_01 có kích thước tệp tối đa được đặt thành 61440MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_sys_01 có kích thước tệp tối đa được đặt thành 20480MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_usr_01 có kích thước tệp tối đa được đặt thành 20480MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_wort_01 có kích thước tệp tối đa được đặt thành 20480MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

  • D3PR - Tệp cơ sở dữ liệu [D3PR] d3_wort_idx_01 có kích thước tệp tối đa được đặt thành 20480MB. Nếu hết dung lượng, cơ sở dữ liệu sẽ ngừng hoạt động mặc dù có thể có sẵn dung lượng ổ đĩa.

Ưu tiên 200: Thông tin :

• Nén sao lưu dự phòng Tắt - Sao lưu toàn bộ không nén đã xảy ra gần đây và nén sao lưu không được bật ở cấp máy chủ. Nén sao lưu được bao gồm trong SQL Server 2008R2 và mới hơn, ngay cả trong Phiên bản tiêu chuẩn. Chúng tôi khuyên bạn nên bật nén sao lưu theo mặc định để sao lưu ad-hoc sẽ được nén.

• Đối chiếu là Latin1_General_CS_AS FINP - Sự khác biệt đối chiếu giữa cơ sở dữ liệu người dùng và tempdb có thể gây ra xung đột, đặc biệt là khi so sánh các giá trị chuỗi

• Đối chiếu là SQL_Latin1_General_CP1_CI_AS - Sự khác biệt đối chiếu giữa cơ sở dữ liệu người dùng và tempdb có thể gây ra xung đột, đặc biệt là khi so sánh các giá trị chuỗi

  • DEMO77

  • SẢN XUẤT77

• Cấu hình máy chủ được liên kết - BWIN2 \ INFOR được định cấu hình như một máy chủ được liên kết. Kiểm tra cấu hình bảo mật của nó vì nó đang kết nối với sa, bởi vì bất kỳ người dùng nào truy vấn nó đều sẽ nhận được quyền cấp quản trị viên.

Ưu tiên 200: Giám sát :

• Tác nhân đại lý không có email thất bại

  • Công việc syspolicy_purge_history chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc upd_durchpreis_monatl chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc upd_fertmengen_woche chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc upd_liegezeit_monatl chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc upd_vertreter_diff chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc UPDATE_CONNECT_IK chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Wartung.Cleanup chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Wartung.DBCC Kiểm tra DB chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Wartung.Index neu erstellen chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Wartung.Statistiken aktualisieren chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Sao lưu Wartung.Transactionlog chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Wartung.Vollbackup SystemDB chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

  • Công việc Wartung.Vollbackup UserDB chưa được thiết lập để thông báo cho người vận hành nếu thất bại.

• Không có Cảnh báo cho Tham nhũng - Cảnh báo Tác nhân Máy chủ SQL không tồn tại đối với các lỗi 823, 824 và 825. Ba lỗi này có thể cho bạn thông báo về lỗi phần cứng sớm. Kích hoạt chúng có thể ngăn bạn rất nhiều đau lòng.

• Không có Cảnh báo cho Sev 19-25 - Cảnh báo Đại lý SQL Server không tồn tại ở mức độ nghiêm trọng 19 đến 25. Đây là một số lỗi SQL Server rất nghiêm trọng. Biết rằng những điều này đang xảy ra có thể cho phép bạn phục hồi từ các lỗi nhanh hơn.

• Không phải tất cả các cảnh báo được định cấu hình - Không phải tất cả các cảnh báo Tác nhân máy chủ SQL đã được định cấu hình. Đây là một cách miễn phí, dễ dàng để nhận được thông báo về tham nhũng, thất bại trong công việc hoặc mất điện lớn ngay cả trước khi các hệ thống giám sát nhận nó.

Ưu tiên 200: Cấu hình máy chủ không mặc định :

• Tác nhân XP - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 1.

• Cơ sở dữ liệu XP XP - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 1.

• ngôn ngữ toàn văn mặc định - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 1033 và nó đã được đặt thành 1031.

• ngôn ngữ mặc định - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 1.

• cấp độ truy cập filestream - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 1.

• mức độ song song tối đa - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 4.

• bộ nhớ máy chủ tối đa (MB) - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 2147483647 và nó đã được đặt thành 115000.

• bộ nhớ máy chủ tối thiểu (MB) - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 10000.

• kết nối quản trị viên từ xa - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 0 và nó đã được đặt thành 1.

Ưu tiên 200: Hiệu suất :

• ngưỡng chi phí cho tính song song - Đặt thành 5, giá trị mặc định của nó. Thay đổi cài đặt sp_cool này có thể làm giảm sự chờ đợi CXPACKET.

• Sao lưu ảnh chụp nhanh xảy ra - 9 bản sao lưu trông giống ảnh chụp nhanh đã xảy ra trong hai tuần qua, cho thấy IO có thể bị đóng băng.

Ưu tiên 210: Cấu hình cơ sở dữ liệu không mặc định :

• Đọc kích hoạt cách ly ảnh chụp nhanh được cam kết - Cài đặt cơ sở dữ liệu này không phải là mặc định.

  • D3PR

  • CUỐI

• Kích hoạt đệ quy được kích hoạt - Cài đặt cơ sở dữ liệu này không phải là mặc định.

  • DEMO77

  • SẢN XUẤT77

• FINP Isolation đã bật FINP - Cài đặt cơ sở dữ liệu này không phải là mặc định.

Ưu tiên 240: Chỉ số chờ :

• 1 - ASYNC_NETWORK_IO - 225,9 giờ chờ đợi, thời gian chờ trung bình 143,5 phút mỗi giờ, chờ tín hiệu 0,2%, chờ đợi 2146022, thời gian chờ trung bình 378,9 ms.

• 2 - CXPACKET - 43,1 giờ chờ, thời gian chờ trung bình 27,4 phút mỗi giờ, chờ tín hiệu 1,5%, nhiệm vụ chờ 32608391, thời gian chờ trung bình 4,8 ms.

Ưu tiên 250: Thông tin :

• SQL Server đang chạy trong tài khoản NT Service

  • Tôi đang hoạt động với tư cách là Dịch vụ NT \ MSSQL $ INFOR. Tôi ước tôi có một tài khoản dịch vụ Active Directory thay thế.

  • Tôi đang chạy với tư cách là Dịch vụ NT \ SQLAgent $ INFOR. Tôi ước tôi có một tài khoản dịch vụ Active Directory thay thế.

Ưu tiên 250: Thông tin máy chủ :

• Nội dung theo dõi mặc định - Theo dõi mặc định giữ 760 giờ dữ liệu trong khoảng thời gian từ ngày 3 tháng 9 năm 2017 8:34 PM và Okt 5 2017 12:50 PM. Các tệp theo dõi mặc định được đặt trong: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Ổ đĩa C Space - 21308.00MB miễn phí trên ổ C

• Ổ đĩa D Space - 280008.00MB miễn phí trên ổ D
• Ổ đĩa E Space - 281618.00MB miễn phí trên ổ E

• Ổ đĩa F Space - 60193.00MB miễn phí trên ổ F

• Phần cứng - Bộ xử lý logic: 4. Bộ nhớ vật lý: 128GB.

• Phần cứng - NUMA Cấu hình - Nút: 0 Trạng thái: ONLINE Bộ lập lịch trực tuyến: 4 Bộ lập lịch ngoại tuyến: 0 Nhóm bộ xử lý: 0 Nút bộ nhớ: 0 Bộ nhớ VAS Dành riêng GB: 281

• Máy chủ khởi động lại lần cuối - Okt 1 2017 2:21 PM

• Tên máy chủ - BWINPDB \ INFOR

• Dịch vụ

  • Dịch vụ: Máy chủ SQL (INFOR) chạy trong tài khoản dịch vụ NT Service \ MSSQL $ INFOR. Thời gian khởi động lần cuối: Okt 1 2017 2:22 PM. Loại khởi động: Tự động, hiện đang chạy.

  • Dịch vụ: SQL Server-Agent (INFOR) chạy trong tài khoản dịch vụ NT Service \ SQLAgent $ INFOR. Thời gian khởi động lần cuối: không hiển thị .. Loại khởi động: Tự động, hiện đang chạy.

• Máy chủ SQL khởi động lại lần cuối - Okt 1 2017 2:22 PM

• Dịch vụ máy chủ SQL - Phiên bản: 13.0.4001.0. Cấp độ bản vá: SP1. Phiên bản: Phiên bản tiêu chuẩn (64-bit). Luôn bật Kích hoạt: 0. Luôn luôn Mgr Trạng thái: 2

• Máy chủ ảo - Loại: (HYPERVISOR)

• Phiên bản Windows - Bạn đang chạy phiên bản Windows khá hiện đại: Thời đại máy chủ 2012R2, phiên bản 6.3

Ưu tiên 254: Hoàn trả :

• Nhật ký của thuyền trưởng: sắp xếp thứ gì đó và thứ gì đó ...

BIÊN TẬP:

Tôi đã nghiên cứu hướng dẫn thực hành tốt nhất về việc thiết lập máy chủ sql với vmware và chúng tôi đã thiết lập hầu hết trong số đó theo bài viết này. Mặc dù vậy, siêu phân luồng không được kích hoạt và NUMA không hoạt động trên máy chủ vmware. SQL Server được đặt thành NUMA mặc dù.

BIÊN TẬP:

Tôi đã ban hành RECONFIGURE sau khi cài đặt mức độ song song thành 50, cũng như cài đặt MAXDOP của tôi không được định cấu hình.

Tôi cũng đã kiểm tra với quản trị viên vmware của chúng tôi, có vẻ như tôi đã bị thông tin sai. CPU của chúng tôi được đặt thành 2,6 GHz chứ không phải 4,6 GHz. Tôi đã sửa thông tin đó ở trên.

BIÊN TẬP:

Chúng tôi đã cố gắng thiết lập một số mạng liên quan theo hướng dẫn và vmwarekb này . Chúng tôi cũng đã thêm 4 lõi vào VM. Việc sử dụng CPU vẫn giữ nguyên.

Như đã thảo luận lần cuối cùng bạn hỏi câu hỏi này , sự chờ đợi hàng đầu của bạn là ASYNC_NETWORK_IO. SQL Server đang ngồi chờ máy ở đầu kia của ống để tiêu hóa hàng kết quả truy vấn tiếp theo.

Tôi đã nhận được thông tin này từ kết quả thống kê chờ đợi của sp_Blitz (cảm ơn vì đã dán nó vào):

1 - ASYNC_NETWORK_IO - 225,9 giờ chờ đợi, thời gian chờ trung bình 143,5 phút mỗi giờ, chờ tín hiệu 0,2%, chờ đợi 2146022, thời gian chờ trung bình 378,9 ms.

Đừng tắt xử lý sự cố CPU - điều đó không liên quan. Tập trung vào loại chờ chính của bạn và những thứ sẽ gây ra loại chờ đó.

Để khắc phục sự cố này hơn nữa, hãy chạy sp_WhoIsActive hoặc sp_BlitzFirst (từ chối trách nhiệm: Tôi là một trong những tác giả của điều đó) - cả hai sẽ liệt kê các truy vấn hiện đang chạy. Nhìn vào cột thông tin chờ, tìm các truy vấn đang chờ ASYNC_NETWORK_IO và xem các ứng dụng và máy chủ mà chúng đang chạy.

Từ đó, bạn có thể thử:

• Kiểm tra xem các máy chủ ứng dụng đó có bị thiếu năng lượng không (như nếu chúng được tối đa hóa trên CPU hoặc phân trang vào đĩa) và điều chỉnh chúng
• Làm việc với các nhà phát triển ứng dụng để xem liệu họ có đang xử lý từng hàng trên kết quả hay không (như đối với mỗi hàng quay lại từ SQL Server, ứng dụng sẽ tắt và xử lý trước khi yêu cầu hàng kết quả tiếp theo)
• Làm việc với các nhà phát triển ứng dụng để chọn ít dữ liệu hơn (như ít hàng hơn hoặc ít cột hơn nếu họ không cần tất cả dữ liệu - đôi khi bạn thấy điều này khi mọi người vô tình thực hiện CHỌN * và mang lại nhiều dữ liệu hơn họ cần hoặc họ yêu cầu tất cả các hàng khi chúng chỉ thực sự cần 1000 đầu)

Cập nhật với sp_WhoIsActive - trong ảnh chụp màn hình sp_WhoIsActive bạn đã đăng, bạn đã có một vài truy vấn đang chờ trên ASYNC_NETWORK_IO. Đối với những người, tham khảo các hướng dẫn ở trên.

Trong phần còn lại của các truy vấn, hãy xem cột "trạng thái" của sp_WhoIsActive - phần lớn trong số chúng đang "ngủ". Điều đó có nghĩa là chúng hoàn toàn không hoạt động - họ đang chờ các ứng dụng ở đầu ống bên kia gửi lệnh tiếp theo. Họ có các giao dịch mở (xem cột "open_tran_count") nhưng SQL Server không thể làm gì để tăng tốc giao dịch ngủ. Các truy vấn này đã được mở trong hơn bốn mươi phút (cột đầu tiên trong sp_WhoIsActive. Họ không làm gì nữa. Bạn phải nhờ những người đó thực hiện giao dịch và đóng kết nối của họ. Đây không phải là vấn đề điều chỉnh hiệu suất.

Mọi thứ chúng ta đang thấy ở đây đều chỉ ra một kịch bản mà chúng ta đang chờ đợi trên ứng dụng.

Để anwer câu hỏi của riêng tôi. ASYNC_NETWORK_IO thực sự không phải là vấn đề thực sự. Chúng tôi đã khắc phục sự cố hiệu suất của mình bằng cách làm theo hướng dẫn này cho khối lượng công việc nhạy cảm độ trễ:

Thực tiễn tốt nhất để điều chỉnh hiệu suất của khối lượng công việc nhạy cảm với độ trễ trong vSphere VM

Tôi đã đánh dấu các cài đặt chúng tôi áp dụng cho hệ thống của mình bằng màu vàng ở đây:

Tôi nghĩ rằng các cài đặt có tác động mạnh nhất là cấu hình numa và cài đặt độ nhạy độ trễ ở mức cao . Cả hai đều cần thiết để phân bổ / dự trữ lõi CPU vật lý và RAM cho VM.

Chúng tôi cũng đã thêm nhiều lõi hơn vào VM bây giờ cần nâng cấp giấy phép SQL Server của chúng tôi từ Standard thành Enterprise.

Có vẻ như Windows đang báo cáo tốc độ xung nhịp của lõi CPU 4.6Ghz của bạn là 2.6Ghz ... Tôi sẽ chạy một công cụ như CPU-Z để kiểm tra tốc độ chúng thực sự đang chạy, và sau đó xem xét thay đổi cài đặt nguồn điện trong cả Windows và BIOS / Hệ điều hành quản lý để vô hiệu hóa mọi cài đặt tiết kiệm năng lượng có thể điều chỉnh các lõi ở tốc độ thấp hơn.