Việc sử dụng CPU có ảnh hưởng đến chi phí truy cập NUMA nước ngoài không?

Kịch bản

Giả sử tôi có Máy chủ SQL có 4 ổ cắm với mỗi nút 1 NUMA. Mỗi ổ cắm có 4 lõi vật lý. Có tổng dung lượng bộ nhớ 512 GB nên mỗi nút NUMA có 128 GB RAM.

Một bảng chính được tải vào nút NUMA đầu tiên.

Câu hỏi

Giả sử chúng ta có rất nhiều lưu lượng đọc từ bảng đó. Nếu tất cả các lõi vật lý của ổ cắm sở hữu nút NUMA có mức sử dụng CPU 100 phần trăm, điều đó có ảnh hưởng tiêu cực đến chi phí truy cập NUMA không cục bộ đến từ các ổ cắm khác không? Hoặc mặt khác, chi phí của việc truy cập NUMA không cục bộ không phụ thuộc vào mức độ bận rộn của ổ cắm đó?

Tôi hy vọng câu hỏi của tôi có ý nghĩa. Xin vui lòng cho tôi biết nếu nó không tôi sẽ cố gắng làm rõ.

Lý lịch

Chúng tôi đã có một vấn đề cơ sở dữ liệu trong máy chủ sản xuất của chúng tôi vào tuần trước và một số hoạt động kinh doanh của chúng tôi có vẻ bị ảnh hưởng nhiều hơn những người khác. Chúng tôi đã có các truy vấn với vài lần đọc logic mất hơn 1 phút. Chúng tôi đã xem xét việc sử dụng CPU tổng thể là khoảng 60 phần trăm. Chúng tôi đã không nhìn vào số liệu CPU cụ thể của socket. Số liệu I / O ở mức trung bình.

Một câu hỏi lớn :-) Tôi sẽ phác thảo một số yếu tố liên quan. Trong bất kỳ bối cảnh nhất định, các yếu tố này và các yếu tố khác có thể thay đổi và tạo ra một kết quả thú vị.

Xin lỗi tôi đã không thể làm điều này ngắn hơn nhiều ...

1. CPU tích lũy ms so với IO logic
2. Căn chỉnh nút bộ nhớ logic của SQL Server với các nút NUMA vật lý
3. Sự tranh chấp spinlock trong phân bổ bộ nhớ không gian làm việc
4. Phân công nhiệm vụ lên lịch
5. Vị trí dữ liệu có liên quan trong vùng đệm
6. Vị trí bộ nhớ vật lý

1. CPU tích lũy ms so với IO logic

   Tôi sử dụng các biểu đồ của IO logic (hoặc theo thuật ngữ perfmonology "tra cứu trang nhóm bộ đệm") chống lại việc sử dụng CPU rất thường xuyên, để đánh giá hiệu quả cpu của khối lượng công việc và tìm kiếm các trường hợp dễ bị spinlock.

   Nhưng SQL Server tích lũy thời gian CPU với nhiều hoạt động khác ngoài tra cứu trang và spinlocks:

   • Kế hoạch được biên soạn và biên soạn lại.
   • Mã CLR được thực thi.
   • Các chức năng được thực hiện.

   Rất nhiều hoạt động khác sẽ nhai thời gian cpu đáng kể mà không được phản ánh trong phần tra cứu trang.

   Trong khối lượng công việc tôi quan sát được, chủ yếu trong số các hoạt động "không logic logic nhưng ngấu nghiến CPU" này là hoạt động sắp xếp / băm.

   Đó là lý do: xem xét một ví dụ giả định về hai truy vấn đối với hàm băm không có chỉ mục không bao gồm. Hai truy vấn có kết quả giống hệt nhau, nhưng một trong các kết quả hoàn toàn không được sắp xếp và tập kết quả thứ hai được sắp xếp theo nhiều hơn một trong các cột được chọn. Truy vấn thứ hai dự kiến ​​sẽ tiêu tốn nhiều thời gian CPU hơn, mặc dù nó sẽ tham chiếu cùng số trang trong nhóm bộ đệm.

   Tìm hiểu thêm về bộ nhớ không gian làm việc và bao nhiêu không gian làm việc được cấp đã được sử dụng, trong các bài đăng này:

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-grantedreservedstolen_4.html

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-workspace-memory-with-twist.html

   • http://sql-sasquatch.blogspot.com/2015/03/resource-gocateor-to-restrict-max-query.html

2. Căn chỉnh nút bộ nhớ logic của SQL Server với các nút NUMA vật lý

   SQL Server (kể từ khi kết hợp các chiến lược nhận biết NUMA của nó) theo mặc định sẽ tạo một nút bộ nhớ SQLOS cho mỗi nút NUMA trên máy chủ. Khi phân bổ bộ nhớ tăng lên, mỗi phân bổ được kiểm soát bởi một trong các nút bộ nhớ SQLOS.

   Lý tưởng nhất là các nút bộ nhớ SQLOS được căn chỉnh hoàn toàn với các nút NUMA vật lý. Điều đó có nghĩa là, mỗi nút bộ nhớ SQLOS chứa bộ nhớ từ một nút NUMA duy nhất, không có nút bộ nhớ SQLOS nào khác cũng chứa bộ nhớ từ cùng một nút NUMA đó.

   Tuy nhiên, tình huống lý tưởng đó không phải lúc nào cũng đúng.

   Bài đăng trên blog của CSS SQL Server Engineers (cũng được bao gồm trong phản hồi của Kin) có thể dẫn đến việc phân bổ bộ nhớ nút chéo NUMA cho các nút bộ nhớ SQLOS. Khi điều này xảy ra, tác động hiệu suất có thể bị tàn phá.

   • http://bloss.msdn.com/b/psssql/archive/2012/12/13/how-it-works-sql-server-numa-local-forign-and-away-memory-blocks.aspx

   Đã có một vài bản sửa lỗi cho trường hợp đặc biệt đau đớn về tham chiếu nút chéo NUMA liên tục. Có lẽ những người khác ngoài hai người này, là tốt:

   • CỐ ĐỊNH: Các sự cố về hiệu suất xảy ra trong môi trường NUMA khi xử lý trang nước ngoài trong SQL Server 2012 hoặc SQL Server 2014

   • CỐ ĐỊNH: Các vấn đề về hiệu suất của SQL Server trong môi trường NUMA

3. Sự tranh chấp spinlock trong khi phân bổ bộ nhớ không gian làm việc

   Đây là nơi nó bắt đầu để có được niềm vui. Tôi đã mô tả rằng công việc sắp xếp và băm trong bộ nhớ không gian làm việc tiêu tốn CPU nhưng không được phản ánh trong các số tra cứu bpool.

   Sự tranh giành Spinlock là một lớp khác cho niềm vui đặc biệt này. Khi bộ nhớ bị đánh cắp từ nhóm bộ đệm và được phân bổ để sử dụng cho cấp bộ nhớ truy vấn, quyền truy cập bộ nhớ được tuần tự hóa với một spinlock. Theo mặc định, điều này diễn ra với một tài nguyên được phân vùng ở cấp nút NUMA. Vì vậy, mọi truy vấn trên cùng một nút NUMA sử dụng bộ nhớ vùng làm việc có thể có khả năng gặp phải sự tranh chấp spinlock khi đánh cắp bộ nhớ chống lại các khoản trợ cấp. Rất quan trọng cần lưu ý: đây không phải là rủi ro tranh chấp "một lần cho mỗi truy vấn", vì sẽ xảy ra nếu thời điểm tranh chấp là tại thời điểm cấp thực tế. Thay vào đó, khi bộ nhớ bị đánh cắp so với cấp - do đó, một truy vấn có cấp bộ nhớ rất lớn sẽ có nhiều cơ hội để tranh chấp spinlock nếu nó sử dụng hầu hết các cấp của nó.

   Trace flag 8048 thực hiện một công việc tuyệt vời để giải tỏa sự tranh chấp này bằng cách phân vùng tiếp theo tài nguyên ở cấp độ cốt lõi.

   Microsoft cho biết "xem xét cờ theo dõi 8048 nếu 8 lõi trở lên trên mỗi ổ cắm". Nhưng ... thực sự không có bao nhiêu lõi trên mỗi ổ cắm (miễn là có nhiều lõi), mà là có bao nhiêu cơ hội để tranh chấp trong công việc được thực hiện trên một nút NUMA.

   Trên các bộ xử lý AMD được dán (12 lõi cho mỗi ổ cắm, 2 nút NUMA trên mỗi ổ cắm) có 6 lõi cho mỗi nút NUMA. Tôi thấy một hệ thống có 4 trong số các CPU đó (vì vậy tám nút NUMA, mỗi lõi 6 lõi) đã bị kẹt trong đoàn xe spinlock cho đến khi cờ theo dõi 8048 được bật.

   Tôi đã thấy sự tranh chấp spinlock này kéo xuống hiệu suất trên các máy ảo nhỏ tới 4 vCPU. Cờ Trace 8048 đã làm những gì nó được cho là khi được bật trên các hệ thống đó.

   Xem xét rằng vẫn còn một số CPU được tối ưu hóa tần số 4 lõi ngoài kia, với khối lượng công việc phù hợp, họ cũng được hưởng lợi từ cờ theo dõi 8048.

   CMEMTHREAD chờ đợi đi kèm với kiểu tranh chấp spinlock mà cờ theo dõi 8048 giải tỏa. Nhưng một lời cảnh báo: CMEMTHREAD chờ đợi là một triệu chứng chứng thực, không phải là nguyên nhân gốc rễ cho vấn đề đặc biệt này. Tôi đã thấy các hệ thống có CMEMTHREAD cao "bắt đầu chờ" trong đó cờ theo dõi 8048 và / hoặc 9024 bị trì hoãn triển khai vì thời gian chờ CMEMTHREAD tích lũy khá thấp. Với spinlocks, thời gian chờ tích lũy thường là điều sai lầm khi xem xét. Thay vào đó, bạn muốn xem xét thời gian CPU bị lãng phí - được thể hiện chủ yếu bằng chính các spin, thứ hai là các chờ đợi liên quan đại diện cho các chuyển đổi ngữ cảnh có thể không cần thiết.

   • Cách thức hoạt động: CMemThread và gỡ lỗi chúng

4. Phân công nhiệm vụ lên lịch

   Trên các hệ thống NUMA, các kết nối được phân phối cho các nút NUMA (thực tế là các nhóm lập lịch SQLOS được liên kết với chúng), giả sử không có điểm cuối kết nối được liên kết với các nút NUMA cụ thể. Nếu một phiên thực hiện một truy vấn song song, có một ưu tiên mạnh mẽ là sử dụng các công nhân từ một nút NUMA duy nhất. Hmmm ... hãy xem xét một máy chủ nút 4 NUMA với một truy vấn phức tạp được chia thành 4 đường dẫn và mặc định 0 MAXDOP. Ngay cả khi truy vấn chỉ sử dụng các luồng công nhân MAXDOP, sẽ có 4 luồng công nhân cho mỗi CPU logic trên nút NUMA. Nhưng có 4 đường dẫn trong kế hoạch phức tạp - vì vậy mỗi CPU logic trên nút NUMA có thể có 16 công nhân trên đó - tất cả chỉ cho một truy vấn!

   Đây là lý do tại sao đôi khi bạn sẽ thấy một nút NUMA hoạt động mạnh trong khi các nút khác đang loaf.

   Có một vài sắc thái khác để phân công nhiệm vụ. Nhưng điều đáng nói chính là CPU bận rộn sẽ không nhất thiết phải được phân bổ đều trên các nút NUMA. (Cũng tốt để nhận ra rằng các trang chèn bpool (đọc hoặc ghi trang đầu tiên) sẽ đi vào bpool trong nút bộ nhớ SQLOS được liên kết với bộ lập lịch mà công nhân đang bật. Và các trang bị đánh cắp sẽ ưu tiên đến từ bộ nhớ SQLOS "cục bộ" nút, quá.

   Tôi thấy rằng việc mang maxdop từ 0 đến không quá 8 là hữu ích. Tùy thuộc vào hồ sơ khối lượng công việc (chủ yếu là imo về số lượng truy vấn có khả năng kéo dài dự kiến ​​đồng thời), tất cả các cách để MAXDOP = 2 có thể được bảo hành.

   Điều chỉnh ngưỡng chi phí cho song song cũng có thể hữu ích. Các hệ thống tôi làm việc có xu hướng được sử dụng với các truy vấn chi phí cao và hiếm khi gặp kế hoạch dưới 50 hoặc 100, vì vậy tôi đã có nhiều lực kéo bằng cách điều chỉnh maxdop (oten ở cấp nhóm khối lượng công việc) hơn là điều chỉnh ngưỡng chi phí.

   • SQL Server PLE với 8 nút NUMA

     Trong bài đăng này, một sự kết hợp của sự tranh chấp spinlock xung quanh bộ nhớ không gian làm việc và phân phối tác vụ không đồng đều được thảo luận. Xem - những điều này thực sự làm tất cả cùng dệt :-)

   • 40 truy vấn song song SQL Server + (2 ổ cắm * 10 lõi trên mỗi ổ cắm) = đoàn xe spinlock

5. Vị trí dữ liệu có liên quan trong bpool

   Đây là điều kiện mà tôi nghĩ là trực quan nhất khi giao dịch với các máy chủ NUMA. Nó cũng, điển hình nhất, không cực kỳ quan trọng đối với hiệu suất khối lượng công việc.

   Điều gì xảy ra nếu bảng được đọc vào bpool trên NUMA nút 3 và sau đó, một truy vấn trên NUMA nút 4 sẽ quét bảng thực hiện tất cả các tra cứu bpool trên các nút NUMA?

   Linchi Shea có một bài viết tuyệt vời về tác động hiệu suất này:

   • http://sqlblog.com/bloss/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx

   Truy cập bộ nhớ qua các nút NUMA phát sinh một lượng nhỏ độ trễ bộ nhớ bổ sung. Tôi chắc chắn có một số khối lượng công việc cần loại bỏ độ trễ bộ nhớ cơ sở bổ sung đó để có hiệu suất tối ưu - đó không phải là vấn đề trên các hệ thống tôi làm việc cùng.

   Nhưng - truy cập nút chéo cũng mang đến một điểm chuyển giao khác có khả năng bão hòa. Nếu có quá nhiều hoạt động mà băng thông bộ nhớ giữa các nút NUMA bị bão hòa, độ trễ bộ nhớ giữa các nút sẽ tăng lên. Công việc tương tự sẽ yêu cầu các chu kỳ CPU bổ sung.

   Một lần nữa - tôi chắc chắn có khối lượng công việc sao cho băng thông bộ nhớ là một vấn đề quan trọng. Tuy nhiên, đối với các hệ thống của tôi, những cân nhắc khác mà tôi liệt kê có ý nghĩa hơn.

6. Vị trí bộ nhớ vật lý

   Điều này là hiếm nhưng khi nó quan trọng, nó thực sự quan trọng. Trên hầu hết các máy chủ, cài đặt bộ nhớ gần như tự nhiên sẽ cân bằng trên các nút NUMA. Nhưng trong một số trường hợp, cần chú ý đặc biệt để cân bằng bộ nhớ trên các nút. Hiệu năng trong một số hệ thống hoàn toàn có thể bị vứt bỏ nếu bộ nhớ bị trượt theo cách không cân bằng. Điều này được thiết lập-và-quên-nó, mặc dù. Khá hiếm khi phát hiện ra một vấn đề như thế này sau nhiều tháng phục vụ sản xuất trái ngược với sau ngày thực sự bận rộn đầu tiên :-)

CUỐI CÙNG LỚN!

Một số người khác đưa ra quan điểm rằng lựa chọn kế hoạch kém, có lẽ do số liệu thống kê lỗi thời, có thể dẫn đến các triệu chứng bạn đã thấy. Đó không phải là trường hợp trong kinh nghiệm của tôi. Các kế hoạch kém có thể dễ dàng khiến một truy vấn mất nhiều thời gian hơn dự kiến ​​- nhưng thường là do các IO logic hơn mức cần thiết đang được thực hiện. Hoặc do tràn sang tempdb. Sự cố tràn lớn đến tempdb nên được thể hiện rõ khi quan sát máy chủ - và thay vì CPU cao, người ta sẽ mong đợi thời gian chờ có thể đo lường được cho việc ghi đĩa liên quan đến sự cố tràn.

Thay vào đó, nếu tình huống bạn quan sát có liên quan đến NUMA, tôi hy vọng nó sẽ là sự kết hợp của các yếu tố được liệt kê ở trên, chủ yếu là:

1. sử dụng bộ nhớ không gian làm việc (sẽ không hiển thị theo số lượng logic logic)

2. có thể là nút NUMA chéo do tình trạng bộ nhớ nước ngoài liên tục (nếu đây là trường hợp, hãy tìm các bản sửa lỗi có liên quan)

3. và có thể xảy ra tranh chấp spinlock trong nút NUMA mỗi lần phân bổ được thực hiện đối với khoản trợ cấp (khắc phục bằng T8048)

4. và có thể được thực hiện bởi các công nhân trên các CPU logic bị quá tải bởi các nhân viên truy vấn song song khác (điều chỉnh maxdop và / hoặc ngưỡng chi phí song song khi cần thiết)

( vui lòng cập nhật câu hỏi của bạn với đầu ra coreinfo -v(tiện ích hệ thống) để có ngữ cảnh tốt hơn về CPU / ổ cắm và phân phối NUMA của bạn )

Chúng tôi đã xem xét việc sử dụng CPU tổng thể là khoảng 60 phần trăm. Chúng tôi đã không nhìn vào số liệu CPU cụ thể của socket. Số liệu I / O ở mức trung bình.

Dường như với tôi rằng bạn đang sủa sai cây. SQL Server NUMAnhận thức được. Có hình phạt hiệu suất nhỏ hơn nhiều khi thực hiện truy cập bộ nhớ NUMA chéo . Bạn cũng có thể sử dụng truy vấn này để xem NUMAbạn có bao nhiêu nút và CPU và lõi được gán cho NUMA:

SELECT parent_node_id, scheduler_id, cpu_id
FROM sys.dm_os_schedulers WITH (NOLOCK) 
WHERE [status] = N'VISIBLE ONLINE';

Hoặc chỉ có bao nhiêu NUMA:

select COUNT(distinct Parent_node_id)
from sys.dm_os_schedulers
where [STATUS] = 'VISIBLE ONLINE'
    and Parent_node_ID < 64

Chúng tôi đã có các truy vấn với vài lần đọc logic mất hơn 1 phút.

Điều này thường xảy ra khi bạn có các gói truy vấn xấu được tạo do thống kê lỗi thời. Hãy chắc chắn rằng bạn đã cập nhật số liệu thống kê và các chỉ mục của bạn được phân mảnh đúng cách .

Ngoài ra, bạn cần đặt MAXDOP thành một giá trị hợp lý hơn để tránh chết đói luồng công nhân .

Đặt cost threshold of parallelismmặc định của bạn từ mặc định là 5 thành giá trị khởi đầu tốt như 45 và sau đó theo dõi giá trị đó và điều chỉnh giá trị đó theo môi trường của bạn.

Nếu bạn đang chạy nhiều truy vấn adhoc, hãy bật (đặt thành 1) optimize for ad hoc workloadsđể ngăn chặn tình trạng đầy bộ nhớ cache của gói.

Hãy thận trọng: Bạn có thể sử dụng T8048 nếu bạn đang chạy SQL Server 2008/2008 R2 trên các máy mới hơn với hơn 8 CPU được trình bày trên mỗi nút NUMA và có một hotfix nếu bạn đang ở trên máy chủ SQL 2012 hoặc 2014 .

Rất khuyến khích bạn bắt đầu thu thập thông tin thống kê Chờ về trường hợp máy chủ cơ sở dữ liệu của bạn.

Tham khảo: Cách thức hoạt động: Máy chủ SQL (NUMA Khối bộ nhớ cục bộ, nước ngoài và khối nhớ)

Hoàn toàn từ góc độ phần cứng, việc quản lý bộ nhớ chính hình thành kiến ​​trúc Nehalem trở đi được quản lý bởi bộ điều khiển bộ nhớ tích hợp, đây là phần "Un-core" của CPU chết, tách biệt với phần mà lõi thực sự sống. do bộ nhớ có hiệu quả 'Có dây' với mỗi CPU, truy cập bộ nhớ nước ngoài AFAIK thông qua kết nối đường dẫn nhanh (một lần nữa từ Nehalem trở đi), do đó tôi sẽ nói rằng độ bão hòa lõi CPU trên nút NUMA cục bộ sẽ không ảnh hưởng đến truy cập từ xa vào bộ nhớ đó.

Bạn có thể thấy liên kết này hữu ích:

http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf

Chris