Tổng số bộ nhớ máy chủ SQL của SQL Server bị trì trệ trong nhiều tháng với 64GB trở lên

Tôi đã gặp phải một vấn đề kỳ lạ khi SQL Server 2016 Standard Edition 64-bit dường như đã tự giới hạn ở một nửa tổng bộ nhớ được phân bổ cho nó (64GB 128GB).

Đầu ra của @@VERSIONlà:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22/12/2017 11:25:00 Bản quyền (c) Microsoft Corporation Standard Edition (64-bit) trên Windows Server 2012 R2 Datacenter 6.3 ( Xây dựng 9600 :) (Hypervisor)

Đầu ra của sys.dm_os_process_memorylà:

Khi tôi truy vấn sys.dm_os_performance_counters, tôi thấy rằng Target Server Memory (KB)là tại 131072000và Total Server Memory (KB)là chỉ dưới một nửa trong số đó tại 65308016. Trong hầu hết các kịch bản, tôi sẽ hiểu đây là hành vi bình thường vì SQL Server chưa xác định rằng nó cần phân bổ thêm bất kỳ bộ nhớ nào cho chính nó.

Tuy nhiên, nó đã bị "kẹt" ở mức ~ 64GB trong hơn 2 tháng nay. Trong khung thời gian này, chúng tôi đã thực hiện một số lượng đáng kể các hoạt động cần nhiều bộ nhớ trên một số cơ sở dữ liệu và đã thêm gần 40 cơ sở dữ liệu khác vào ví dụ. Chúng tôi đang ngồi ở tổng số cơ sở dữ liệu 292, mỗi cơ sở có các tệp dữ liệu được phân bổ trước ở mức 4GB với tốc độ tự động 256 MB và các tệp nhật ký 2 GB với tốc độ tự động 128 MB. Tôi thực hiện sao lưu toàn bộ mỗi đêm một lần vào lúc 12:00 sáng và bắt đầu sao lưu nhật ký giao dịch từ thứ Hai đến thứ Sáu bắt đầu từ 6:00 sáng đến 8:00 tối trong khoảng thời gian 15 phút một lần. Các cơ sở dữ liệu này tương đối thấp trên thông lượng tổng thể của chúng, nhưng tôi nghi ngờ rằng có điều gì đó không ổn khi SQL Server không len lỏi vàoTarget Server Memory tự nhiên thông qua các bổ sung cơ sở dữ liệu mới, thực thi truy vấn thông thường, cũng như các đường ống ETL sử dụng nhiều bộ nhớ đã được chạy.

Bản thân máy chủ SQL đang ngồi trên máy chủ Windows Server 2012R2 được ảo hóa (VMware) với 12 CPU, bộ nhớ 144GB (128GB cho SQL Server, 16GB dành riêng cho Windows) và 4 đĩa ảo nằm trên một vSAN với các ổ đĩa 15K SAS . Windows nằm tự nhiên trên đĩa 64 GB C: với tệp trang là 32 GB. Các tệp dữ liệu nằm trên đĩa D: 2TB, các tệp nhật ký nằm trên đĩa L: 2TB và tempdb nằm trên đĩa T: 256GB với các tệp 8x16GB không có tự động phát.

Tôi đã xác minh rằng không có phiên bản SQL Server nào khác đang chạy trên máy chủ bên cạnh MSSQLSERVER.

Máy chủ này hoàn toàn dành riêng cho phiên bản SQL Server, vì vậy chúng tôi không có ứng dụng hoặc dịch vụ nào khác chạy trên nó có thể tiêu thụ bộ nhớ.

Tôi sử dụng RedGate SQL Monitor để phân tích và dưới đây là lịch sử của 18 ngày qua Total Server Memory. Như bạn có thể thấy, việc sử dụng bộ nhớ vẫn hoàn toàn trì trệ ngoài một mức tăng duy nhất ~ 300MB vào đầu tháng Tư.

Điều gì có thể là nguyên nhân của điều này? Tôi có thể xem xét kỹ hơn để xác định lý do tại sao SQL Server không muốn sử dụng thêm 64GB + bộ nhớ được phân bổ cho nó?

Đầu ra của việc chạy sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

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

• Bộ lập lịch CPU ngoại tuyến - Một số lõi CPU không thể truy cập được đối với SQL Server do sự cố về mặt nạ hoặc vấn đề cấp phép.

• Nút bộ nhớ ngoại tuyến - Do vấn đề về mặt nạ hoặc cấp phép, một số bộ nhớ có thể không khả dụng.

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

• Vô hiệu hóa từ xa DAC - Không thể truy cập từ xa vào Kết nối quản trị viên chuyên dụng (DAC). Bộ xử lý có thể giúp xử lý sự cố từ xa dễ dàng hơn nhiều khi SQL Server không phản hồi.

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

• Nhiều kế hoạch cho một truy vấn - 300 gói có mặt cho một truy vấn 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.

• Kích hoạt máy chủ

  • Kích hoạt máy chủ [RG_SQLLighthouse_DDLTrigger] được bật. Hãy chắc chắn rằng bạn hiểu những gì kích hoạt đang làm - công việc càng ít thì càng tốt.

  • Kích hoạt máy chủ [SSMSRemoteBlock] được bật. Hãy chắc chắn rằng bạn hiểu những gì kích hoạt đang làm - công việc càng ít thì càng tốt.

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

• Truy vấn Buộc tham gia gợi ý - 1480 trường hợp gợi ý tham gia đã được ghi lại kể từ khi khởi động lại. Điều này có nghĩa là các truy vấn đang chiếm lĩnh trình tối ưu hóa Máy chủ SQL và nếu họ không biết họ đang làm gì, điều này có thể gây hại nhiều hơn là tốt. Điều này cũng có thể giải thích tại sao những nỗ lực điều chỉnh DBA không hoạt động.

• Truy vấn Buộc gợi ý đơn hàng - 2153 trường hợp gợi ý đơn hàng đã được ghi lại kể từ khi khởi động lại. Điều này có nghĩa là các truy vấn đang chiếm lĩnh trình tối ưu hóa Máy chủ SQL và nếu họ không biết họ đang làm gì, điều này có thể gây hại nhiều hơn là tốt. Điều này cũng có thể giải thích tại sao những nỗ lực điều chỉnh DBA không hoạt động.

Ư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 200: Thông tin :

• Công việc Tác nhân Bắt đầu Đồng thời - Nhiều công việc Máy chủ SQL được định cấu hình để bắt đầu đồng thời. Để biết danh sách lịch trình chi tiết, xem truy vấn trong URL.

• Các bảng trong tổng thể cơ sở dữ liệu chủ - Bảng CommandLog trong cơ sở dữ liệu chủ được tạo bởi người dùng cuối vào ngày 30 tháng 7 năm 2017 5:22 chiều. Các bảng trong cơ sở dữ liệu chủ có thể không được khôi phục trong trường hợp xảy ra thảm họa.

• TraceFlag On

  • Cờ dấu vết 1118 được kích hoạt trên toàn cầu.

  • Cờ dấu vết 1222 được kích hoạt trên toàn cầu.

  • Cờ dấu vết 2371 được kích hoạt trên toàn cầu.

Ư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.

• sao lưu tổng kiểm tra dự phòng - 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.

• sao lưu nén 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.

• ngưỡng chi phí cho tính song song - Tùy chọn sp_cool này đã được thay đổi. Giá trị mặc định của nó là 5 và nó đã được đặt thành 48.

• 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 12.

• 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 128000.

• tối ưu hóa cho khối lượng công việc ad hoc - 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.

• hiển thị các tùy chọn nâng cao - 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.

• xp_cmdshell - 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: Độ tin cậy :

• Thủ tục lưu trữ mở rộng trong Master

• master - Thủ tục lưu trữ mở rộng [sqbdata] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbdir] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbmemory] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbstatus] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbtest] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / khôi phục của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbtestcelon] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbteststatus] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqbutility] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

  • master - Thủ tục lưu trữ mở rộng [sqlbackup] nằm trong cơ sở dữ liệu chủ. CLR có thể đang được sử dụng và cơ sở dữ liệu chủ bây giờ cần phải là một phần của kế hoạch sao lưu / phục hồi của bạn.

Ư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.

  • Làm lại

  • RedGateMonitor

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

  • Làm lại

  • RedGateMonitor

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

• 1 - SOS_SCHEDULER_YIELD - 1770,8 giờ chờ đợi, thời gian chờ trung bình 115,9 phút mỗi giờ, chờ tín hiệu 100,0%, nhiệm vụ chờ 1419212079, thời gian chờ trung bình 4,5 ms.

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

• SQL Server đang chạy trong tài khoản Dịch vụ NT - Tôi đang chạy dưới dạng Dịch vụ NT \ MSSQLSERVER. 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 lưu giữ 36 giờ dữ liệu trong khoảng thời gian từ 14 tháng 4 năm 2018 11:21 PM đến 16 tháng 4 năm 2018 11:13 sáng. Các tệp theo dõi mặc định được đặt trong: C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSQuerySERVER \ MSSQL \ Log

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

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

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

• Ổ đĩa T Space - 114441.00MB miễn phí trên ổ G

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

• Phần cứng - Cấu hình NUMA

  • 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: 2 Nhóm bộ xử lý: 0 Nút bộ nhớ: 0 Bộ nhớ VAS Dành riêng GB: 186

  • Nút: 1 Trạng thái: OFFLINE Bộ lập lịch trực tuyến: 0 Bộ lập lịch ngoại tuyến: 6 Nhóm bộ xử lý: 0 Nút bộ nhớ: 0 Bộ nhớ VAS Dành riêng GB: 186

• Đã bật Khởi tạo tệp tức thì - Tài khoản dịch vụ có quyền Thực hiện nhiệm vụ bảo trì khối lượng.

• Gói điện - Máy chủ của bạn có CPU 2,60 GHz và ở chế độ năng lượng cân bằng - Uh ... bạn muốn CPU của mình chạy ở tốc độ tối đa, phải không?

• Máy chủ khởi động lại lần cuối - ngày 9 tháng 3 năm 2018 7:27 sáng

• Tên máy chủ - [đã xử lý lại]

• Dịch vụ

  • Dịch vụ: Máy chủ SQL (MSSQLSERVER) chạy trong tài khoản dịch vụ NT Service \ MSSQLSERVER. Thời gian khởi động lần cuối: ngày 9 tháng 3 năm 2018 7:27 sáng. Loại khởi động: Tự động, hiện đang chạy.

  • Dịch vụ: Đại lý máy chủ SQL (MSSQLSERVER) chạy trong tài khoản dịch vụ LocalSystem. 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 - ngày 9 tháng 3 năm 2018 6:27 sáng

• Dịch vụ máy chủ SQL - Phiên bản: 13.0.4466.4. Cấp độ bản vá: SP1. Cập nhật tích lũy: CU7. Phiên bản: Phiên bản tiêu chuẩn (64-bit). Các nhóm khả dụng Đã bật: 0. Các nhóm quản lý sẵn có 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ì đó ...

Tôi cá là bạn đã cấu hình CPU ảo theo cách một số nút CPU và / hoặc nút bộ nhớ ngoại tuyến.

Tải xuống sp_Blitz (từ chối trách nhiệm: Tôi là một trong những tác giả của tập lệnh nguồn mở miễn phí đó) và chạy nó:

sp_Blitz @CheckServerInfo = 1;

Tìm kiếm các cảnh báo về CPU và / hoặc các nút bộ nhớ đang ngoại tuyến. SQL Server Standard Edition chỉ nhìn thấy 4 ổ cắm CPU đầu tiên và bạn có thể đã cấu hình VM giống như 6 CPU lõi kép. Cuối cùng, nó sẽ gặp phải một vấn đề tương tự như cách giới hạn 20 lõi của Phiên bản doanh nghiệp giới hạn dung lượng bộ nhớ bạn có thể thấy .

Nếu bạn muốn chia sẻ đầu ra của sp_Blitz tại đây, bạn có thể chạy nó như thế này để xuất ra Markdown, sau đó bạn có thể sao chép / dán vào câu hỏi của mình:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Cập nhật 2018/04/16 - đã được xác nhận. Bạn đã đính kèm đầu ra sp_Blitz (cảm ơn vì điều đó!) Và thực sự nó cho thấy rằng bạn có các nút CPU và bộ nhớ ngoại tuyến. Bất cứ ai xây dựng VM đều cấu hình nó thành 12 CPU đơn lõi, do đó, SQL Server Standard Edition chỉ nhìn thấy 4 ổ cắm (lõi) đầu tiên và bộ nhớ được gắn vào chúng.

Để khắc phục, hãy tắt VM, định cấu hình nó như một VM 2 ổ cắm, 6 lõi và sau đó SQL Server Standard Edition sẽ thấy tất cả các lõi và bộ nhớ. Điều này cũng sẽ làm giảm SOS_SCHEDULER_YIELD của bạn chờ đợi - ngay bây giờ, Máy chủ SQL của bạn đang đập 4 lõi đầu tiên, nhưng đó là nó. Sau khi sửa lỗi này, nó sẽ có thể hoạt động trên tất cả 12 lõi.

Là một phụ lục cho kế hoạch hành động của Brent Ozar , tôi muốn chia sẻ kết quả. Như Brent đã lưu ý, trong VMware, chúng tôi đã cấu hình Máy ảo không đúng cách với 12 CPU lõi đơn. Điều này dẫn đến 8 lõi còn lại không thể truy cập được bởi SQL Server và kết quả là dẫn đến vấn đề bộ nhớ được mô tả trong câu hỏi ban đầu của tôi. Chúng tôi đã đặt các dịch vụ của mình ở chế độ bảo trì tối qua để cấu hình lại VM một cách thích hợp. Không chỉ chúng ta thấy bộ nhớ tăng lên một cách bình thường, mà như Brent cũng gợi ý, số lượng chờ đợi giảm theo cấp số nhân và hiệu suất SQL Server tổng thể của chúng tôi đã tăng vọt. Các cấu hình vNUMA hiện là các thành phần nhỏ hạnh phúc đang cắt giảm khối lượng công việc của chúng tôi.

Đối với những người có thể đang sử dụng VMware vSphere 6.5, các bước ngắn gọn để hoàn thành mục hành động được mô tả bởi Brent như sau.

1. Đăng nhập vào vSphere Web Client cho cụm VMware của bạn và duyệt đến Máy ảo lưu trữ SQL Server. VM của bạn phải ngoại tuyến để điều chỉnh cấu hình CPU và bộ nhớ.

2. Trong khung chính, đi đến Configure > VM hardware, nhấp vào Editnút ở góc trên cùng bên phải. Bạn sẽ mở ra một menu ngữ cảnh có Edit Settings. Để tham khảo, hình ảnh dưới đây là cấu hình không chính xác . Lưu ý rằng tôi đã Cores per Socketđặt thành 1. Với những hạn chế của SQL Server Standard Edition, đây là một cấu hình tồi.

   

3. Việc sửa chữa đơn giản như điều chỉnh Cores per Socketgiá trị. Trong trường hợp của chúng tôi, chúng tôi đặt nó để 6chúng tôi có 2 Sockets. Điều này cho phép SQL Server sử dụng tất cả 12 bộ xử lý.

   

Một lưu ý quan trọng: Không đặt giá trị ở vị trí Number of Coreshoặc số Socketssẽ là số lẻ. NUMA thích sự cân bằng và theo quy tắc ngón tay cái, cần chia hết cho 2. Chẳng hạn, cấu hình từ 4 lõi đến 3 ổ cắm sẽ bị mất cân bằng. Trong thực tế, nếu bạn chạy sp_Blitzvới loại cấu hình này, nó sẽ đưa ra cảnh báo về điều này.

Phần 3.3 trong Kiến trúc Microsoft SQL Server trên VMware vSphere (cảnh báo PDF) phác thảo chi tiết này. Các thực tiễn được nêu trong whitepaper có thể áp dụng cho hầu hết tất cả các ảo hóa tại chỗ của SQL Server.

Dưới đây là một vài tài nguyên tôi đã tổng hợp qua nghiên cứu của mình sau bài đăng của Brent:

• Ảo hóa cơ sở dữ liệu lớn - Lập kế hoạch dung lượng CPU VMware

• Máy ảo vCPU và Quyền vNUMA - Quy tắc của ngón tay cái

• Phân tách lõi trên mỗi ổ cắm từ cấu trúc liên kết ảo ảo trong vSphere 6.5

Tôi sẽ kết thúc việc thu thập từ RedGate SQL Monitor trong 24 giờ qua. Điểm lưu ý chính là việc sử dụng CPU và số lượng chờ - trong giờ cao điểm của chúng tôi ngày hôm qua, chúng tôi đã gặp phải tình trạng sử dụng CPU nặng và tranh chấp chờ đợi. Sau sửa chữa đơn giản này, chúng tôi đã cải thiện hiệu suất của chúng tôi gấp mười lần. Ngay cả I / O đĩa của chúng tôi đã giảm đáng kể. Đây là một thiết lập dường như dễ bị bỏ qua có thể cải thiện hiệu suất ảo theo một mức độ lớn. Ít nhất, nó đã bị bỏ qua bởi các kỹ sư của chúng tôi và hoàn toàn d'oh chốc lát.

Ngoài ra, theo MSDN , tiêu chuẩn SQL Server được giới hạn ở 64GB RAM. Chúng tôi đã 'giải quyết' điều này bằng cách chia cơ sở dữ liệu thành nhiều trường hợp, nhưng tình huống của bạn có thể không cho phép điều đó.

Hmm 2016 dường như có giới hạn 128GB, nhưng phân chia thể hiện có thể vẫn là một tùy chọn.