tại sao io_stall_writes_ms lại cao hơn nhiều cho tempdb?

Chúng tôi có các tệp dữ liệu người dùng và hệ thống trên cùng một ổ đĩa. (Io_stall_write_ms / (1.0 + num_of_writes)) dưới 2 cho các tệp người dùng nhưng các tệp tempdb thường trên 400. Tôi thấy rằng trên một vài máy chủ và tôi tò mò liệu có mất nhiều thời gian hơn để ghi vào tempdb không hơn một tệp dữ liệu cơ sở dữ liệu thông thường.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Cảm ơn bạn,

Trả lời ngắn: Nhìn thấy các quầy hàng IO cao hơn có thể hoặc không thể là một vấn đề trong chính nó. Bạn cần xem xét thêm thông tin để nói ra nếu bạn gặp vấn đề. Có vẻ hơi cao, vâng, nhưng bạn có đau khổ không? Nếu vậy, có thể là do hệ thống IO của bạn không xử lý đúng tải (vì không thể, vì bạn có mọi thứ trên một ổ đĩa hoặc một số lý do khác) hoặc bạn đang làm quá nhiều trong TempDB (thay đổi vấn đề đầu tiên - hiệu suất IO - có thể là một sửa chữa dễ dàng và hiệu quả hơn, nhưng trước tiên hãy xác định xem bạn có vấn đề gì không)

Các cuộc thảo luận / trả lời dài hơn:

Có hai câu hỏi đang chơi ở đây -

1.) Tôi phải làm gì khi thấy các quầy hàng IO cao?

Trước hết, "cao" là trong mắt của kẻ si tình. Nếu bạn hỏi 10 DBA thì "quá cao" là gì đối với các quầy hàng IO, bạn có thể nhận được 2-3 câu trả lời khác nhau với các số trong đó, 5-6 câu trả lời "Nó phụ thuộc" và một cái nhìn chằm chằm. Giả định của tôi là trung bình 400ms có khả năng quá cao ở đây, đặc biệt là khi các DB khác là 2ms hoặc thấp hơn trong thời gian gian hàng trung bình.

Bất kể cơ sở dữ liệu nào đang nhìn thấy các quầy hàng cao, bạn nên tiếp cận nó theo cùng một cách. Một gian hàng IO là những gì nó nghe giống như ... Một yêu cầu IO mất nhiều thời gian hơn dự kiến ​​.. Ngừng. Những điều này xảy ra. Chúng xảy ra mọi lúc trong một hệ thống với các tài nguyên được chia sẻ và tài nguyên hữu hạn (thực sự là tất cả các hệ thống của chúng tôi). Chúng trở thành một vấn đề khi các quầy hàng trở thành vấn đề hiệu suất hoặc dẫn đến chúng. Vì vậy, tôi tin tưởng rằng bạn đang xem đây là một phần chủ động của giám sát hoặc bởi vì bạn đang gặp vấn đề về hiệu suất mà bạn đang khắc phục sự cố. Chúng tôi cũng không muốn bị lạc trong các quầy hàng IO. Chúng tôi đang xem xét một mảnh của câu đố và không phải là bức tranh lớn. Có thể thật rắc rối khi chỉ nhìn vào số liệu thống kê chờ hoặc số liệu thống kê tệp vì SQL được khởi động lại lần cuối bởi vì bạn đang xem mọi lúc và một số cửa sổ bảo trì hoặc cửa sổ tải nặng có thể làm lệch các bộ đếm. Vì vậy, hãy chắc chắn rằng bạn nhìn vào bức tranh đầy đủ.

Nhưng khi tôi nghi ngờ mình gặp vấn đề về hiệu năng đĩa hoặc gặp vấn đề gì đó trong truy vấn như thế này, tôi thường làm theo quy trình như sau:

1. Nhìn vào số liệu thống kê chờ trên máy chủ. @swasheck đã chia sẻ một liên kết tuyệt vời như một bình luận trong câu trả lời dưới đây. Điều này đưa bạn đến bài viết của Paul Randal về việc xem xét và phân tích số liệu thống kê chờ trong SQL Server. Đến đó Những loại chờ đợi bạn đang nhìn thấy? Bạn có thấy chờ đợi liên quan đến IO hiệu suất ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, vv?). Nếu bạn làm điều này là một dấu hiệu khác cho thấy bạn có một số vấn đề về hiệu suất liên quan đến IO, giống như các quầy hàng IO. Nhưng nó cung cấp cho bạn một hình thức thỏa thuận khác ở đây.
2. Nhìn vào hiệu suất IO. Đặc biệt, nhìn vào bên trong perfmon tại Physical Disk:Avg Disk Sec/Readvà Avg Sec Disk Sec/Writequầy. Chúng đo độ trễ của bạn. Xem các bộ đếm này trong một khoảng thời gian được lưu vào tệp nhật ký hiệu suất. Bạn đã thấy gì cho trung bình? Nếu bạn thấy số trên 0,020 giây (20ms) thì đây có thể là một vấn đề. Nếu bạn thấy các con số trên 40-50ms avg hoặc cao hơn là dấu hiệu rõ ràng hơn cho vấn đề. Cũng nhìn vào gai của bạn? Họ đi cao bao nhiêu và kéo dài bao lâu? Nếu bạn thấy tăng đột biến vào hàng trăm ms và chúng kéo dài hàng chục hoặc vài giây trở lên và / hoặc xảy ra thường xuyên, bạn có nhiều khả năng gặp vấn đề với hiệu suất IO của bạn cho khối lượng công việc của bạn.
3. Nhìn vào thiết lập IO của bạn. Nó là gì? Đĩa cục bộ? SAN? Mảng lưu trữ? Loại nào trong suốt và IOP bạn nên thấy trong số này? Có đủ cho những gì bạn đang cố gắng làm? Bạn có thể đã nhấn mạnh IO của bạn cho khối lượng công việc của bạn. Đừng chỉ nhìn vào các trục chính vật lý, cài đặt RAID, v.v. Hãy nhìn vào đường dẫn đến các đĩa của bạn. Bạn có đang đẩy mọi thứ thông qua một liên kết 1GB duy nhất mà bạn đang chia sẻ với rất nhiều lưu lượng truy cập khác không? Bạn có thể xem các số liệu hiệu suất đĩa từ quan điểm của bộ lưu trữ.

( Lưu ý: đối với phân tích thống kê chờ này và phân tích perfmon - xem xét các giai đoạn và loại sử dụng khác nhau. Bạn có số liệu thống kê sử dụng khác nhau vào ban đêm so với ban ngày không? Cửa sổ xử lý hàng loạt? Bảo trì các cửa sổ nơi bạn xây dựng lại nhiều chỉ mục? Nhìn vào các công cụ này trong mỗi giai đoạn này và hiểu những gì bạn đang thấy cho mỗi giai đoạn)

Một xem xét hiệu suất IO khác ở đây -

• Bạn đã nói DB hệ thống và DB người dùng được chia sẻ. Đây có phải là sản xuất? Nếu vậy, đó không phải luôn luôn là kịch bản tốt nhất. Bạn cũng đang chia sẻ tệp nhật ký và tệp dữ liệu trên cùng một ổ đĩa? Đó cũng không phải là kịch bản tốt nhất. Những gì khác chia sẻ lưu trữ này? Trong một thế giới mà bạn lo lắng về các trục chính và các nhóm đột kích và đĩa và phải đưa ra quyết định ai là người có đĩa hoạt động tốt nhất, tôi có xu hướng (như một quy tắc chung .. không có gì tuyệt vời trong thế giới DB nhưng điều này có xu hướng đúng) đi với tốc độ nhanh nhất và tận tâm nhất của tôi đối với TempDB (nhiều hơn ở bên dưới), sau đó là tệp nhật ký, sau đó là tệp dữ liệu. Trong một thế giới nơi bạn có một đống đĩa lớn trên một thiết bị như NetApp, Dell Equal Logic hoặc EMC VNX, v.v. bạn không '

2.) một số lý do TempDB có thể cao hơn là gì?

Vì vậy, TempDB là một cơ sở dữ liệu và nó có thể có các quầy IO giống như bất kỳ cơ sở dữ liệu nào khác như tôi vừa thảo luận. Nhưng một số lý do TempDB có thể có số lần đọc cao hơn là gì? (không đầy đủ, tôi hoan nghênh các bổ sung hoặc suy nghĩ trong các chỉnh sửa, các câu trả lời hoặc nhận xét khác) -

1. Do mã của bạn - Bạn có đang sử dụng TempDB rất nhiều trong mã của mình không? Rất nhiều bảng tạm thời và các biến bảng được tạo và hủy? Làm nhiều thứ trong TempDB như thế này? Điều đó không nhất thiết là xấu hoặc tốt, nhưng bạn có thể nhìn vào đó và hiểu mô hình sử dụng TempDB có chủ ý của bạn.
2. TempDB là một công việc được chia sẻ - TempDB là một cơ sở dữ liệu được sử dụng làm không gian tạm thời cho các đối tượng tạm thời do người dùng xác định và các bảng và hoạt động khác nhau được sử dụng bởi toàn bộ thể hiện SQL của bạn. Có bao nhiêu DB người dùng? Những loại khối lượng công việc bạn nhìn thấy nói chung? TempDB là một tài nguyên cho tất cả mọi thứ để chia sẻ.
3. Truy vấn không hiệu quả và bộ nhớ không đủ - Có lẽ có những truy vấn không sử dụng chỉ mục đủ chặt hoặc đang thực hiện các hoạt động quét và sắp xếp lớn. Các thao tác băm lớn và bộ nhớ trên máy chủ không đủ cho các hoạt động này. Các hoạt động này sẽ "tràn" sang TempDB dưới dạng bàn làm việc phía sau hậu trường. Đôi khi điều này có thể tránh được bằng cách xem xét các kế hoạch truy vấn của bạn và lập chỉ mục hoặc điều chỉnh truy vấn. Đôi khi nó xảy ra (nhiều hơn về khối lượng công việc kho, tôi tìm thấy). Nếu bạn có đủ bộ nhớ, điều này có thể giúp ích, nhưng những truy vấn này vẫn có thể bị tràn ra nhiều lần. Nhìn cái này cũng được.
4. Bạn có đang sử dụng cấp độ Cách ly Ảnh chụp đã đọc với số lượng cập nhật hợp lý trong hệ thống của mình không? Điều này cũng có thể dẫn đến tăng hoạt động TempDB.

Vấn đề là - TempDB được sử dụng theo nhiều cách và hoàn toàn không làm tôi ngạc nhiên khi thấy nó là một trong những cơ sở dữ liệu bận rộn nhất của bạn, nếu không phải là bận rộn nhất. Nó cũng không làm tôi ngạc nhiên khi tôi thấy nó có số lượng lớn nhất và trung bình cao nhất trong tất cả các cơ sở dữ liệu tại trang web của khách hàng. Đó là bản chất của khối lượng công việc của nó đôi khi. Nhìn vào một số điều tôi đã đề cập ở đây chắc chắn có thể giúp bạn xác định xem những con số này có phải là vấn đề hay không và nếu có, làm thế nào để đi sâu hơn vào việc giải quyết nó.

TempDB được chia sẻ giữa tất cả các cơ sở dữ liệu trên ví dụ. Vì vậy, đôi khi có thể có sự tranh chấp trong TempDB cho một số trang nhất định: SGAM , GAM và PFS . Tóm lại, các trang này theo dõi những gì đã được sử dụng trong TempDB cho đến nay và nơi có không gian để sử dụng mới.

Thông thường, điều này được xử lý bằng cách thêm nhiều tệp dữ liệu vào TempDB. Có một vài triết lý khác nhau về con số chính xác, nhưng tất cả đều đồng ý bạn nên có nhiều hơn một.

Dưới đây là một vài truy vấn để chạy ...

Cái này sẽ cho bạn thấy TempDB có bao nhiêu tệp và vị trí của chúng.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Điều này sẽ cho bạn thấy bạn có bao nhiêu CPU và lõi.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Cái này sẽ cho bạn thấy có bao nhiêu nút NUMA và lõi trên mỗi nút NUMA mà bạn có.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Cái này sẽ cho bạn thấy những trang nào đang gặp phải sự chờ đợi trong TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Đây là một bài viết đi sâu hơn một chút về vấn đề tranh chấp trang.

OK, vậy bây giờ là phần triết lý ... :-)

Đối với bản thân tôi, nếu tôi ở trên một hệ thống SMP , tôi chỉ muốn có bao nhiêu tệp bằng một nửa tổng số lõi .

Nếu tôi đang sử dụng hệ thống NUMA , thì tôi chỉ muốn có nhiều tệp như lõi trên mỗi nút NUMA .

Tuy nhiên, tôi hiếm khi thấy bất kỳ cải thiện nào khi có nhiều hơn bốn tệp cho TempDB. Vì vậy, tôi thường bắt đầu với bốn và theo dõi sự tranh chấp như được giải thích trong bài viết tôi liên kết đến.

Nếu tôi tiếp tục thấy vấn đề, thì tôi sẽ thêm hai vấn đề nữa. Kiểm tra lại, thêm nhiều hơn và lặp lại cho đến khi sự tranh chấp biến mất.