SQL Server 2012 x64 - không thể phân bổ an toàn hơn 50% RAM

Chúng tôi đang chạy SQL Server 2012 SP1 CU4 trên máy chủ 2 lõi 64 bit, sử dụng máy chủ kiến ​​trúc NUMA. HĐH là Windows Server 2008 R2 x64.

Bất cứ khi nào chúng tôi phân bổ hơn 50% RAM vật lý cho máy chủ SQL, máy sẽ không ổn định hoặc không phản hồi.

Các triệu chứng là điển hình của tình trạng đói bộ nhớ hệ điều hành - tức là quá trình không khởi động, đối tượng GUI không hiển thị, các ứng dụng hoạt động sai, các phiên máy tính từ xa trở nên không phản hồi, v.v.

Chúng tôi đã thấy điều này trên 2 máy khác nhau - một máy có RAM 192 GB, máy còn lại có RAM 256 GB ngay khi SQL được cung cấp hơn 50% tổng số vật lý tương ứng, các triệu chứng xuất hiện.

Có ai khác nhìn thấy hành vi này?

--- BIÊN TẬP ---

Dịch vụ SQL chạy trong một tài khoản có đặc quyền LPIM (Khóa trang trong bộ nhớ).

Đáng buồn là phần mềm diệt virus McAfee được áp đặt trên máy chủ, mặc dù ít nhất nó cũng được thiết lập với các loại trừ cho tất cả các tệp SQL.

Khi mức sử dụng RAM được phép vượt quá 50%, hành vi phổ biến chúng ta thấy là:

• Thời gian chờ đợi RESOURCE_SEMAPHORE cao.
• Không có khả năng kết nối với máy chủ SQL hoặc chạy truy vấn.
• Tất cả các CPU đạt tối đa với I / O đĩa thấp khi chạy khối lượng công việc truy vấn.

- CHỈNH SỬA 2 ---

Chúng tôi đã thử cài đặt lại SQL (SP1 CU4) và đã kiểm tra xem không có gì khác đang kiểm tra RAM. Nói chung, có ít nhất 100 GB trong tổng số 256 GB miễn phí bất cứ lúc nào. Khi chúng tôi tắt LPIM, chúng tôi sẽ thấy vấn đề "hệ điều hành đã hoán đổi ở một phần đáng kể của bộ nhớ SQL", đó là lý do tại sao chúng tôi bật nó lên.

Tôi sẽ kiểm tra số liệu perfmon cho CPU trên mỗi cpu đang bận, cũng như số liệu toàn bộ perfmon và mỗi nút NUMA cho PLE, trang cơ sở dữ liệu, v.v. Hai KB Server SQL gần đây

• CỐ ĐỊNH: Các vấn đề về hiệu suất của SQL Server trong môi trường NUMA
• CỐ ĐỊNH: Bạn có thể gặp sự cố về hiệu suất trong SQL Server 2012

Tuy nhiên, đối với một số khối lượng công việc, đặc biệt là với số lượng lõi cao hơn, số lượng truy vấn đồng thời cao và rất nhiều đĩa cơ sở dữ liệu IO, sử dụng cờ theo dõi 8015 (vô hiệu hóa hỗ trợ NUMA ở cấp SQL Server) và 8048 (xóa botlleneck cấp phát bộ nhớ truy vấn trên ổ cắm) cung cấp kết quả thậm chí tốt hơn các bản sửa lỗi có trong SQL Server 2012 SP1 CU4. (Tôi đã xác nhận điều này trên thiết bị thử nghiệm của chúng tôi bằng các mô phỏng khối lượng công việc của chúng tôi - YMMV)

Cờ dấu vết 8015 xứng đáng được đánh giá kỹ lưỡng trước khi triển khai. Ái lực bộ nhớ và tham dự độ trễ bộ nhớ thấp hơn được hy sinh để quản lý một bpool lớn duy nhất. Nó cũng dẫn đến một trình soạn thảo lười biếng thay vì một nút trên mỗi nút NUMA và ý tưởng xác nhận lại điểm cuối kết nối trong một phiên bản SQL Server duy nhất cho mỗi nút NUMA cũng biến mất. Nhưng đối với một số khối lượng công việc thì lợi ích là không thể phủ nhận. Đừng sử dụng 8015 mà không có 8048.

Tôi chưa bao giờ thấy hoặc nghe về bất kỳ chi phí có thể đo lường nào khi thêm cờ theo dõi 8048 và nếu CMEMTHREADchờ đợi và các spinlocks liên quan được kích hoạt bằng phân bổ bộ nhớ truy vấn - đó là cách đáng tin cậy duy nhất để loại bỏ chúng.