Yêu cầu I / O mất hơn 15 giây

Thông thường các bản sao lưu đầy đủ hàng tuần của chúng tôi kết thúc sau khoảng 35 phút, với các bản sao lưu khác nhau hàng ngày hoàn thành trong ~ 5 phút. Kể từ thứ ba, các tờ nhật báo đã mất gần 4 giờ để hoàn thành, nên cần nhiều hơn thế. Thật trùng hợp, điều này bắt đầu xảy ra ngay sau khi chúng tôi có cấu hình SAN / đĩa mới.

Lưu ý rằng máy chủ đang chạy trong sản xuất và chúng tôi không có vấn đề gì chung, nó hoạt động trơn tru - ngoại trừ vấn đề IO chủ yếu thể hiện ở hiệu suất sao lưu.

Nhìn vào dm_exec numquests trong quá trình sao lưu, bản sao lưu liên tục chờ đợi trên ASYNC_IO_COMPLETION. Aha, vì vậy chúng tôi có tranh chấp đĩa!

Tuy nhiên, cả MDF (nhật ký được lưu trữ trên đĩa cục bộ) cũng như ổ đĩa sao lưu không có bất kỳ hoạt động nào (IOPS ~ = 0 - chúng tôi có rất nhiều bộ nhớ). Chiều dài hàng đợi đĩa ~ = 0 là tốt. CPU dao động khoảng 2-3%, cũng không có vấn đề gì.

SAN là Dell MD3220i, LUN bao gồm các ổ đĩa 6x10k SAS. Máy chủ được kết nối với SAN thông qua hai đường dẫn vật lý, mỗi đường đi qua một công tắc riêng biệt với các kết nối dự phòng đến SAN - tổng cộng có bốn đường dẫn, hai trong số chúng hoạt động bất cứ lúc nào. Tôi có thể xác minh rằng cả hai kết nối đang hoạt động thông qua trình quản lý tác vụ - phân chia tải hoàn toàn đồng đều. Cả hai kết nối đang chạy song công hoàn toàn 1G.

Chúng tôi đã từng sử dụng các khung hình khổng lồ, nhưng tôi đã vô hiệu hóa chúng để loại trừ bất kỳ vấn đề nào ở đây - không thay đổi. Chúng tôi có một máy chủ khác (cùng OS + config, 2008 R2) được kết nối với các LUN khác và nó không có vấn đề gì. Tuy nhiên, nó không chạy SQL Server mà chỉ chia sẻ CIFS trên đầu chúng. Tuy nhiên, một trong những đường dẫn ưa thích LUN của nó nằm trên cùng bộ điều khiển SAN với các LUN rắc rối - vì vậy tôi cũng loại trừ điều đó.

Chạy một vài thử nghiệm SQLIO (tệp thử nghiệm 10G) dường như cho thấy IO là tốt, mặc dù có vấn đề:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Tôi nhận ra rằng đây không phải là những bài kiểm tra toàn diện, nhưng chúng khiến tôi thoải mái khi biết rằng đó không phải là rác hoàn toàn. Lưu ý rằng hiệu suất ghi cao hơn được gây ra bởi hai đường dẫn MPIO hoạt động, trong khi đọc sẽ chỉ sử dụng một trong số chúng.

Kiểm tra nhật ký sự kiện Ứng dụng cho thấy các sự kiện như thế này nằm rải rác xung quanh:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

Chúng không phải là hằng số, nhưng chúng xảy ra thường xuyên (một vài giờ mỗi lần, nhiều hơn trong các lần sao lưu). Bên cạnh sự kiện đó, nhật ký sự kiện hệ thống sẽ đăng những điều sau:

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Những điều này cũng xảy ra trên máy chủ CIFS không có vấn đề chạy trên cùng một SAN / Trình điều khiển và từ Google của tôi, chúng dường như không quan trọng.

Lưu ý rằng tất cả các máy chủ sử dụng cùng một NIC - Broadcom 5709C với trình điều khiển cập nhật. Bản thân các máy chủ là Dell R610.

Tôi không chắc chắn những gì để kiểm tra tiếp theo. Bất kỳ đề xuất?

Cập nhật - Chạy perfmon
Tôi đã thử ghi Trung bình. Đĩa sec / Đọc và ghi bộ đếm hoàn hảo trong khi thực hiện sao lưu. Việc sao lưu bắt đầu một cách rực rỡ, và sau đó về cơ bản dừng chết ở mức 50%, bò chậm về phía 100%, nhưng mất 20 lần thời gian cần thiết.

Hiển thị cả hai đường dẫn SAN đang được sử dụng, sau đó thả ra.

Sao lưu bắt đầu vào khoảng 15:38:50 - chú ý tất cả đều trông ổn, và sau đó là một loạt các đỉnh. Tôi không quan tâm đến việc viết, chỉ đọc dường như bị treo.

Lưu ý rất ít hành động bật / tắt, mặc dù hiệu suất rực rỡ ở cuối.

Lưu ý tối đa 12 giây, mặc dù trung bình là tổng thể tốt.

Cập nhật - Sao lưu thiết bị NUL
Để tách biệt các vấn đề đã đọc và đơn giản hóa mọi thứ, tôi đã chạy như sau:

BACKUP DATABASE XXX TO DISK = 'NUL'

Các kết quả hoàn toàn giống nhau - bắt đầu bằng một lần đọc và sau đó là các quầy hàng, tiếp tục các hoạt động ngay bây giờ và sau đó:

Cập nhật - Các quầy hàng IO
Tôi đã chạy truy vấn dm_io_virtual_file_stats từ cuốn sách Jonathan Kehayias và Ted Kruegers (trang 29), theo khuyến nghị của Shawn. Nhìn vào 25 tệp hàng đầu (mỗi tệp một tệp - tất cả các kết quả là tệp dữ liệu), có vẻ như các lần đọc tệ hơn ghi - có lẽ vì ghi trực tiếp vào bộ đệm SAN trong khi đọc lạnh cần nhấn vào đĩa - mặc dù chỉ là đoán .

Cập nhật - Thống kê chờ
Tôi đã thực hiện ba bài kiểm tra để thu thập một số thống kê chờ. Số liệu thống kê chờ được truy vấn bằng cách sử dụng tập lệnh Glenn Berry / Paul Randals . Và chỉ để xác nhận - các bản sao lưu không được thực hiện để ghi băng, mà là một iSCSI LUN. Kết quả tương tự nếu được thực hiện với đĩa cục bộ, với kết quả tương tự với bản sao lưu NUL.

Xóa số liệu thống kê. Chạy trong 10 phút, tải bình thường:

Xóa số liệu thống kê. Chạy trong 10 phút, tải bình thường + chạy sao lưu bình thường (không hoàn thành):

Xóa số liệu thống kê. Chạy trong 10 phút, tải bình thường + sao lưu NUL đang chạy (chưa hoàn thành):

Cập nhật - Wtf, Broadcom?
Dựa trên những gợi ý của Mark Storey-Smiths và những kinh nghiệm trước đây của Kyle Brandts với Broadcom NIC, tôi quyết định thực hiện một số thử nghiệm. Khi chúng tôi có nhiều đường dẫn hoạt động, tôi có thể dễ dàng thay đổi cấu hình của từng cái một mà không gây ra sự cố ngừng hoạt động.

Vô hiệu hóa TOE và khối lượng gửi lớn mang lại kết quả gần như hoàn hảo:

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Vậy đâu là thủ phạm, TOE hay LSO? Đã bật TOE, LSO bị vô hiệu hóa:

Didn't finish the backup as it took forever - just as the original problem!

TOE bị vô hiệu hóa, bật LSO - tìm kiếm tốt:

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

Và như một sự kiểm soát, tôi đã vô hiệu hóa cả TOE và LSO để xác nhận vấn đề đã biến mất:

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

Cuối cùng, có vẻ như Công cụ giảm tải TCP Broadcom được kích hoạt đã gây ra sự cố. Ngay khi TOE bị vô hiệu hóa, mọi thứ hoạt động như một cơ duyên. Đoán tôi sẽ không đặt hàng thêm bất kỳ NIC Broadcom nào trong tương lai.

Cập nhật - Xuống máy chủ CIFS
Hôm nay, máy chủ CIFS giống hệt và hoạt động bắt đầu hiển thị các yêu cầu IO bị treo. Máy chủ này không chạy SQL Server, chỉ đơn giản là Windows Web Server 2008 R2 phục vụ chia sẻ qua CIFS. Ngay sau khi tôi vô hiệu hóa TOE trên đó, mọi thứ đã hoạt động trở lại trơn tru.

Chỉ cần xác nhận rằng tôi sẽ không bao giờ sử dụng TOE trên Broadcom NIC nữa, nếu tôi không thể tránh được các Broadcom NIC, đó là.

Lưu ý rằng tất cả các máy chủ sử dụng cùng một NIC - Broadcom 5709C với trình điều khiển cập nhật. Bản thân các máy chủ là Dell R610.

Kyle Brandt có ý kiến ​​về các thẻ mạng Broadcom lặp lại trải nghiệm (lặp đi lặp lại) của riêng tôi.

Broadcom, Die Mutha

Các vấn đề của tôi luôn được liên kết với các tính năng Giảm tải TCP và trong 99% trường hợp vô hiệu hóa hoặc chuyển sang thẻ mạng khác đã giải quyết các triệu chứng. Một ứng dụng khách (như trong trường hợp của bạn) sử dụng các máy chủ Dell, luôn yêu cầu các Intel Intel riêng biệt và vô hiệu hóa các thẻ Broadcom trên bo mạch khi xây dựng.

Như được mô tả trong bài đăng trên blog MSDN này , tôi sẽ bắt đầu với việc vô hiệu hóa trong HĐH với:

netsh int ip set chimney DISABLED

IIRC có thể cần phải vô hiệu hóa các tính năng ở cấp trình điều khiển thẻ trong một số trường hợp, chắc chắn sẽ không hại gì khi làm như vậy.

Không phải tôi là chuyên gia về SAN / đĩa (có những người ở đây biết nhiều hơn tôi) ... Tôi chỉ chia sẻ những gì tôi đã làm một chút và chủ yếu là đọc :)

Jonathan Kehayias và Ted Krueger đã viết một cuốn sách "Xử lý sự cố máy chủ SQL" có một số thông tin tốt về hiệu suất đĩa. Bạn có thể nhận được PDF miễn phí từ đây . (Tôi có thể mua phiên bản in này cho bàn của mình.)

Dù sao, họ có một truy vấn tốt có thể được sử dụng để kiểm tra sys.dm_io_virtual_file_stats và kiểm tra độ trễ trung bình trên các tệp dữ liệu của bạn. Bạn có thể thấy rằng RAID10 không phải là cấu hình lý tưởng cho các tệp dữ liệu cư trú.