RAM tăng, hiệu suất tệ hơn

Thiết lập:

Máy chủ Windows 2008 R2
Máy chủ SQL 2008 R2 SP1
RAM 240GB
TempDB là các tệp dữ liệu 8x16GB không phát triển tự động (tổng cộng 128 GB)
Máy chủ vật lý / độc lập

Máy chủ này được sử dụng để xử lý ETL. Chúng tôi vừa cài đặt thêm RAM trong máy chủ này với tổng số 240GB RAM. Dịch vụ SQL Server là những thứ thực sự duy nhất đang chạy.

Bộ nhớ hiển thị tốt trong BIOS, OpenManage và Windows.

Nếu tôi định cấu hình Máy chủ SQL để sử dụng bộ nhớ Tối thiểu / Tối đa 70/100 GB, chúng tôi không gặp vấn đề gì. Tuy nhiên, khi tôi tăng mức đó lên 120/150 GB, tôi sẽ gặp lỗi sau khi chạy một trong các quy trình ETL của chúng tôi:

Không thể phân bổ không gian cho đối tượng '<đối tượng hệ thống tạm thời: 422234507706368>' trong cơ sở dữ liệu 'tempdb' vì nhóm tệp 'PRIMARY' đã đầy. Tạo không gian đĩa bằng cách xóa các tệp không cần thiết, thả các đối tượng trong nhóm fileg, thêm các tệp bổ sung vào filegroup hoặc cài đặt tự động bật cho các tệp hiện có trong filegroup. (Msg 1105, Bang 2, Quy trình không xác định, Dòng 1)

Chúng tôi chưa bao giờ gặp phải vấn đề này trước khi thay đổi cấu hình bộ nhớ. Sau khi định cấu hình lại về 70 / 100GB ban đầu, chúng tôi không nhận được lỗi này.

Những điều tôi đã thử:

Đặt các tệp dữ liệu TempDB để tự động phát triển. Điều này chỉ đơn giản dẫn đến các tệp tự động phát triển cho đến khi đạt được dung lượng đĩa và sau đó không thành công.
Thêm nhiều tệp dữ liệu TempDB. Lỗi tương tự như hình.
Tăng kích thước TempDB lên 8x32GB (tổng cộng 256GB)

Tôi không biết điều gì có thể gây ra vấn đề này.

sql-server sql-server-2008-r2 memory

— Derek Kromm
nguồn

Bộ nhớ của bạn có được cân bằng trên các nút NUMA không? Làm thế nào về bộ xử lý của bạn? Nhật ký máy chủ SQL có hiển thị bao nhiêu CPU đang được sử dụng trong quá trình khởi động không?

— Aaron Bertrand

Bạn đang sử dụng gì cho các quy trình ETL? SSIS hoặc một số công cụ tương tự? Nếu nó là một công cụ bên ngoài SQL Server, bạn có đang chạy nó trên cùng một máy chủ với phiên bản SQL Server của bạn không?

— Mike Fal

Đó là một điểm tốt @Mike, nếu quy trình ETL không thể lấy đủ bộ nhớ để thực hiện công việc của mình, vì SQL Server đang sử dụng quá nhiều, thì có thể phải đẩy công việc lên tempdb.

— Aaron Bertrand

Đây là một khởi đầu tốt để theo dõi việc sử dụng tempdb: msdn.microsoft.com/en-us/l Library / ms176029 (v = MySQL.105).aspx . Điều này sẽ cho bạn một ý tưởng về những gì đang xảy ra.

— Thomas Stringer

Bạn đã thực hiện bất kỳ phân tích về những gì thực sự chạy khi TempDB thực sự đang mở rộng? Một sp_who2 / sp_whoisactive đơn giản? Nghe có vẻ như bạn đã có một số giao dịch chạy dài có thể được quản lý tốt hơn, nhưng rất khó để nói. Cá nhân, tôi sẽ không gắn liền với thay đổi bộ nhớ mà trước tiên hãy nhìn vào mã và xem liệu nó có chạy đúng không.

— Mike Fal

Nhờ mọi người giúp đỡ của bạn.

Sau khi rót qua một số kế hoạch thực hiện, hóa ra có một THAM GIA đang được xử lý khác nhau dựa trên dung lượng RAM có sẵn. Với ít RAM hơn, nó đánh giá nó bằng Hash; với nhiều RAM hơn, nó sử dụng một loạt Merge Joins.

Vì vậy, về cơ bản, nó đã được chuyển sang T-SQL được viết kém, mà tôi hiện đang tái cấu trúc.

— Derek Kromm
nguồn

Điều đó khá phản cảm vì một phép nối băm yêu cầu cấp bộ nhớ trong khi hợp nhất thì không. Có một hoạt động sắp xếp bổ sung để hỗ trợ tham gia hợp nhất?

— Martin Smith

Đây không phải là một câu trả lời cho câu hỏi, chỉ là một số mã tôi không muốn đăng trong một bình luận. Để xem sự cân bằng của bộ lập lịch và bộ nhớ của bạn trên các nút NUMA (và cũng để xem nếu có bất kỳ nút nào không hiển thị trực tuyến):

SELECT 
  parent_node_id, 
  [status],
  AVG(current_tasks_count) AS avg_tasks_count, 
  AVG(load_factor) AS avg_load_factor,
  scheduler_count = COUNT(*)
FROM sys.dm_os_schedulers
GROUP BY parent_node_id, [status];

SELECT 
  memory_node_id, 
  name, 
  SUM(single_pages_kb + multi_pages_kb) AS memory_kb
FROM sys.dm_os_memory_clerks
GROUP BY memory_node_id, name;

(Trong SQL Server 2012, cuối cùng SUMlà SUM(pages_kb)do không còn phân bổ đơn và đa trang riêng biệt nữa.)

— Aaron Bertrand
nguồn