SQL Server - Bất cứ ai cũng sử dụng SUMA, cờ theo dõi 8048 hoặc cờ theo dõi 8015?

Gần đây đã bao gồm SQL Server khởi động Trace Flag 8048 để giải quyết vấn đề tranh chấp spinlock nghiêm trọng trong hệ thống SQL Server 2008 R2.

Quan tâm đến những người khác đã tìm thấy các trường hợp sử dụng trong đó giá trị hiệu suất được phân phối bằng cờ theo dõi 8048 (thúc đẩy chiến lược cấp bộ nhớ truy vấn từ nút per-NUMA cho mỗi lõi), cờ theo dõi 8015 (Máy chủ SQL bỏ qua NUMA vật lý) hoặc SUMA ( xen kẽ truy cập bộ nhớ đồng đều, tùy chọn BIOS trên một số máy NUMA).

Cờ theo dõi 8048 http://bloss.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presents-per-numa-node-may-need-track-flag-8048.aspx

Cờ dấu vết 8015 http://bloss.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Thông tin chi tiết về khối lượng công việc của hệ thống, thu thập các số liệu từ hệ thống gặp khó khăn và thu thập các số liệu từ hệ thống sau khi có sự can thiệp.

Cờ dấu vết 8048 là một 'sửa chữa', nhưng nó có phải là sửa chữa tốt nhất? Liệu SQL Server có bỏ qua NUMA vật lý do cờ theo dõi 8015 đã hoàn thành điều tương tự không? Còn về việc cài đặt BIOS để xen kẽ bộ nhớ, khiến máy chủ có hành vi SUMA bắt chước SMP thay vì hành vi NUMA thì sao?

Bình yên! tw: @sql_handle

Giới thiệu về hệ thống: - 4 lõi hex Xeon E7540 @ 2.00GHz, siêu phân luồng - RAM 128 GB - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

Về khối lượng công việc: - 1000 báo cáo theo lịch trình / hàng đợi theo lô được điều khiển từ 2 máy chủ ứng dụng báo cáo. - 3 hương vị của các đợt: hàng ngày, hàng tuần, hàng tháng - Tất cả các kết nối máy chủ ứng dụng báo cáo với SQL Server được thực hiện dưới dạng một tài khoản dịch vụ - Báo cáo đồng thời tối đa = 90

Những phát hiện chính trên hệ thống gặp rắc rối: - Từ Perfmon, khoảng thời gian 15 giây - - Hệ thống vẫn ở mức 95% -100% CPU bận rộn - - Tra cứu trang bộ đệm SQL Server <10000 mỗi / giây

• Từ DMV chờ đợi và spinlock, khoảng thời gian 5 phút
• • Người phục vụ và thời gian chờ CMEMTHREAD cao
• • Quay vòng và quay ngược cao SOS_SUSPEND_QUEUE

Bài viết trên Blog Kỹ sư CSS của Bob Dorr trên cờ theo dõi 8048 chỉ ra rằng các hệ thống có hơn 8 lõi trên mỗi nút NUMA có thể gặp phải các triệu chứng tương tự do tắc nghẽn trong cấp bộ nhớ truy vấn. Cờ theo dõi 8048 sẽ thay đổi chiến lược thành mỗi lõi thay vì nút per-NUMA.

Sự can thiệp

MSSQL đã được khởi động lại với -T8048 tại chỗ. Sự khác biệt đã được chứng minh ngay lập tức: tốc độ tra cứu trang đệm tăng hơn 1 triệu và tăng lên 8 triệu mỗi giây. Khối lượng công việc hàng loạt gặp rắc rối, trước đây không thể hoàn thành trong 24 giờ, hoàn thành trong vòng chưa đầy 4 giờ. Một khối lượng công việc hàng loạt khác không phải là trọng tâm của điều tra hoặc can thiệp đã được gửi như một phần của việc xác nhận giá trị khắc phục của cờ theo dõi 8048 (và đảm bảo rằng các tác dụng phụ không mong muốn của nó là tối thiểu). Báo cáo này đã hoàn thành trước đó trong 2 giờ; với cờ theo dõi 8048 tại chỗ, lô báo cáo hoàn thành trong khoảng 20 phút.

ETL hàng đêm cũng gặp phải một lợi ích. Thời gian ETL giảm từ khoảng 60 phút xuống còn 40 phút.

Kết hợp thông tin từ nhiều nơi, tôi suy đoán rằng mức độ cao của hàng đợi báo cáo, số lượng báo cáo đồng thời lớn hơn số lượng luồng phần cứng và tài khoản người dùng duy nhất cho tất cả các báo cáo được kết hợp để gây áp lực lên một nút NUMA cho đến khi áp lực luồng công nhân gây ra không hài lòng với yêu cầu kết nối đến tiếp theo cho cùng một tài khoản người dùng, tại thời điểm đó, nút NUMA tiếp theo sẽ nhận được một số lượng kết nối gần ngay lập tức. Mỗi nút NUMA sẽ kết thúc với xác suất cao gây căng thẳng cho nút cổ chai truy vấn cấp bộ nhớ truy vấn.

Mở thêm làn cho cấp bộ nhớ truy vấn đã loại bỏ nút cổ chai. Nhưng, tôi không chắc chi phí. Bài viết CSS của Bob Dorr cho thấy rõ rằng có thêm chi phí bộ nhớ với cờ theo dõi 8048. Có phải chi phí đó trong khu vực cấp phát một trang được điều chỉnh bởi bộ nhớ máy chủ tối đa MSSQL 2008 R2 không? Nếu vậy, tôi đoán hệ thống sẽ chỉ có một số trang cơ sở dữ liệu ít hơn trong bộ đệm của bộ đệm. Nếu không, bộ nhớ máy chủ tối đa có nên được hạ xuống để chứa?

Đây là một bài viết tuyệt vời.

Để trả lời câu hỏi cuối cùng của bạn, tôi đoán rằng câu trả lời của bạn là "có".

Điều đó nói rằng, tôi có thể đã theo đuổi con số mềm trước khi dùng đến cờ theo dõi. Tôi nghĩ bạn đã đúng về việc phân bổ nút numa và đó có thể là gốc rễ của vấn đề của bạn. Thông qua số mềm, bạn có thể chia tỷ lệ các yêu cầu, tùy thuộc vào số lượng nút numa của bạn (4?) - đến 4, nếu đó là số chính xác, sau đó gán, qua địa chỉ ip, mỗi máy chủ cho một nút numa cụ thể, ngoài ra do đó, tôi sẽ vô hiệu hóa siêu luồng. Kết hợp lại, vấn đề có thể sẽ giảm, tuy nhiên, nó sẽ làm như vậy với chi phí ít người lên lịch hơn.

Theo suy nghĩ riêng biệt, tôi sẽ xem xét tham số hóa bắt buộc - thực tế là tải của bạn đang điều khiển CPU của bạn quá cao rất thú vị và có thể đáng để xem xét điều đó.

Cuối cùng, trên các hệ thống nút nhiều chữ số, tôi thường có đầu ra của các truy vấn sau đây đổ vào bảng mỗi N giây. Làm cho một số phân tích thú vị khi thay đổi khối lượng công việc hoặc cờ theo dõi được thực hiện:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

và

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC