SQL Server đã gặp phải các yêu cầu I / O mất hơn 15 giây

Trên SQL Server sản xuất, chúng tôi có cấu hình sau:

3 máy chủ Dell PowerEdge R630, được kết hợp thành Nhóm khả dụng Cả 3 được kết nối với một đơn vị lưu trữ Dell SAN duy nhất là một mảng RAID

Thỉnh thoảng, trên PRIMARY, chúng tôi thấy các thông báo tương tự như dưới đây:

SQL Server đã gặp phải 11 lần xuất hiện các yêu cầu I / O mất hơn 15 giây để hoàn thành tệp [F: \ Data \ MyDatabase.mdf] trong cơ sở dữ liệu id 8. Xử
lý tệp OS là 0x0000000000001FBC.
Giá trị bù của I / O dài mới nhất là: 0x000004295d0000.
Thời lượng của I / O dài là: 37394 ms.

Chúng tôi là người mới trong xử lý sự cố hiệu suất

Các cách phổ biến nhất hoặc thực tiễn tốt nhất trong việc khắc phục sự cố cụ thể này liên quan đến lưu trữ là gì? Những bộ đếm hiệu suất, công cụ, màn hình, ứng dụng, v.v ... phải được sử dụng để thu hẹp nguyên nhân gốc của những thông báo đó? Có thể có một Sự kiện mở rộng có thể giúp đỡ, hoặc một số loại kiểm toán / ghi nhật ký?

Chúng tôi có một thiết lập tương tự và gần đây đã gặp những thông báo này trong nhật ký. Chúng tôi đang sử dụng SAN DELL Compellent. Dưới đây là một số điều cần kiểm tra khi nhận được những tin nhắn này đã giúp chúng tôi tìm ra giải pháp

• Xem lại các bộ đếm hiệu suất windows cho các đĩa của bạn mà các thông điệp cảnh báo đang trỏ tới, cụ thể:
  • Đĩa avg. thơi gian đọc
  • Đĩa avg. viết thời gian
  • Đĩa đọc byte / giây
  • Đĩa ghi byte / giây
  • Truyền đĩa / giây
  • Trung bình chiều dài hàng đợi đĩa
• Trên đây là trung bình. Nếu bạn có nhiều tệp cơ sở dữ liệu trên một ổ đĩa, các mức trung bình này có thể làm lệch kết quả và che dấu cổ chai trên các tệp cơ sở dữ liệu cụ thể. Kiểm tra truy vấn này từ Paul S. Randal, trả về độ trễ trung bình cho mỗi tệp từ dmv sys.dm_io_virtual_file_stats. Trong trường hợp của chúng tôi, độ trễ trung bình được báo cáo là chấp nhận được, nhưng bên dưới bìa chúng tôi có nhiều tệp có độ trễ trung bình> 200 ms.
• Kiểm tra thời gian. Có mẫu nào không? Nó có xảy ra thường xuyên hơn vào một thời điểm nhất định trong đêm không? Nếu vậy hãy kiểm tra xem có bất kỳ công việc bảo trì nào đang chạy vào thời điểm đó hoặc bất kỳ hoạt động theo lịch trình nào có thể làm tăng hoạt động của đĩa và làm lộ cổ chai trong hệ thống con IO của bạn không.
• Kiểm tra trình xem sự kiện windows cho lỗi. Nếu công tắc hoặc SAN của bạn đang bị quá tải hoặc không được thiết lập đúng cho ứng dụng của bạn, bạn có thể tìm thấy một số thông báo trong nhật ký này và thật tốt khi đưa thông tin này đến quản trị viên SAN của bạn. Trong trường hợp của chúng tôi, chúng tôi đã nhận được lỗi kết nối iSCSI thường xuyên trong suốt cả ngày, gợi ý vấn đề.
• Xem lại mã SQL Server của bạn. Khi bạn nhận được những tin nhắn này, bạn không nên nghĩ ngay rằng đó là sự cố hệ thống con IO và chuyển nó đến quản trị viên SAN của bạn. Bạn cần phải làm một phần của bạn và xem xét cơ sở dữ liệu. Bạn có các truy vấn thực sự xấu đang được chạy thường xuyên qua hàng tấn dữ liệu? Lập chỉ mục xấu? Nhật ký giao dịch quá mức viết? Bạn có thể sử dụng một số truy vấn nguồn mở để kiểm tra sức khỏe trên cơ sở dữ liệu của mình, một ví dụ để kiểm tra xem kế hoạch truy vấn của bạn trông như thế nào là sp_blitzCache
• Đừng bỏ qua những điều này. Hôm nay bạn có thể nhận được chúng một vài lần một ngày ... sau đó vài tháng khi khối lượng công việc của bạn tăng lên và bạn quên theo dõi chúng thì chúng bắt đầu tăng lên. Nhận nhiều tin nhắn này có thể ngăn SQL Server truy cập vào một tệp nhất định và nếu đó là tempdb , điều đó không tốt. Trong trường hợp của chúng tôi, nó đã trở nên tồi tệ đến mức SQL Server tự tắt.

Giải pháp của chúng tôi là nâng cấp công tắc của chúng tôi lên công tắc SAN. Có, đây là tất cả các điểm cần bao gồm trong SQL Server. Điều khiến chúng tôi phát hiện ra nó là công tắc là chúng tôi đã nhận được khoảng 1500 lỗi ngắt kết nối pSC iSCSI trong trình xem sự kiện ứng dụng Windows trên SQL Server mỗi ngày. Điều đó đã thúc đẩy cuộc điều tra của các quản trị viên SAN của chúng tôi vào việc chuyển đổi.

Ngay sau khi nâng cấp, các lỗi iSCSI đã biến mất và độ trễ trung bình giảm xuống khoảng 50 ms cho tất cả các tệp và điều đó tương quan với hiệu suất tốt hơn trong ứng dụng. Với những điểm này trong tâm trí hy vọng bạn có thể tìm thấy giải pháp của mình.

Đây không phải là vấn đề về đĩa thường xuyên và thường là vấn đề về mạng. Bạn biết không, N trong SAN?

Nếu bạn đi đến nhóm SAN của bạn và bắt đầu nói về việc các đĩa bị chậm, họ sẽ hiển thị cho bạn một biểu đồ lạ mắt với độ trễ 0 mili giây trên đó và sau đó chỉ một cái dập ghim vào bạn.

Thay vào đó, hãy hỏi họ về đường dẫn mạng đến SAN. Nhận tốc độ, nếu nó là đa tốc độ, v.v. Lấy số từ chúng về tốc độ bạn sẽ thấy. Hỏi xem họ có điểm chuẩn từ khi máy chủ được thiết lập không.

Sau đó, bạn có thể sử dụng Crystal Disk Mark hoặc đĩapd để xác thực các tốc độ đó. Nếu họ không xếp hàng, một lần nữa, rất có thể đó là mạng.

Bạn cũng nên tìm kiếm nhật ký lỗi của mình để tìm các thông báo có chứa "FlushCache" và "bão hòa", vì đó cũng có thể là dấu hiệu của sự tranh chấp mạng.

Một điều bạn có thể làm để tránh những điều đó với tư cách là một DBA là đảm bảo rằng việc bảo trì của bạn và bất kỳ nhiệm vụ nặng dữ liệu nào khác (như ETL) sẽ không diễn ra cùng một lúc. Điều đó chắc chắn có thể gây áp lực lớn lên mạng lưu trữ.

Bạn cũng có thể muốn kiểm tra các câu trả lời ở đây để có thêm gợi ý: Điểm kiểm tra chậm và cảnh báo I / O 15 giây trên bộ lưu trữ flash

Tôi viết blog về một chủ đề tương tự ở đây: Từ máy chủ đến SAN

Tại sao lưu trữ dữ liệu trên SAN? Vấn đề ở đây là gì? Tất cả hiệu suất cơ sở dữ liệu được gắn với Đĩa I / O và bạn đang sử dụng 3 máy chủ chỉ có một thiết bị cho I / O phía sau chúng. Điều đó vô nghĩa ... và thật không may, rất phổ biến.

Tôi dành cả đời để bắt gặp những nền tảng phần cứng được thiết kế kém, nơi mọi người chỉ cố gắng thiết kế một máy tính quy mô lớn. Tất cả sức mạnh CPU ở đây, tất cả các đĩa ở đó ... hy vọng không có thứ gọi là RAM từ xa. Và điều đáng buồn nhất là họ bù đắp cho sự thiếu hiệu quả của thiết kế này với các máy chủ khổng lồ có giá gấp mười lần so với mức cần thiết. Tôi thấy infra $ 400k chậm hơn so với máy tính xách tay $ 1k.

Phần mềm máy chủ SQL là một phần mềm rất tiên tiến, nó được thiết kế để tận dụng mọi bit phần cứng, lõi CPU, bộ đệm CPU, TLB, RAM, bộ điều khiển đĩa, bộ đệm ổ cứng ... Chúng hầu như bao gồm tất cả logic hệ thống tệp. Chúng được phát triển trên máy tính thông thường và được điểm chuẩn trên các hệ thống cao cấp. Do đó, một máy chủ SQL phải có đĩa riêng. Cài đặt chúng trên SAN giống như "giả lập" máy tính, bạn sẽ mất tất cả các tối ưu hóa hiệu suất. SAN là để lưu trữ các bản sao lưu, các tệp không thay đổi và các tệp bạn chỉ cần nối thêm dữ liệu vào (nhật ký).

Quản trị viên trung tâm dữ liệu có xu hướng đưa tất cả những gì họ có thể vào SAN vì theo cách này họ chỉ có một nhóm lưu trữ để quản lý, việc này dễ dàng hơn việc chăm sóc lưu trữ trên mỗi máy chủ. Đó là một lựa chọn "Tôi không muốn làm công việc của mình", và một điều rất tồi tệ, bởi vì sau đó họ phải giải quyết các vấn đề về hiệu suất và tất cả công ty phải chịu đựng điều này. Chỉ cần cài đặt phần mềm trên phần cứng được thiết kế cho. Giữ cho nó đơn giản. Chăm sóc băng thông I / O, bộ đệm và chuyển đổi ngữ cảnh, jess ressource (xảy ra khi chia sẻ ressource). Cuối cùng, bạn sẽ duy trì 1/10 thiết bị cho cùng một công suất đầu ra, tiết kiệm cho nhóm ops của bạn nhiều vấn đề đau đầu, đạt được hiệu suất làm cho người dùng cuối của bạn hài lòng và làm việc hiệu quả hơn, giúp công ty của bạn trở thành nơi làm việc tốt hơn và tiết kiệm nhiều năng lượng (hành tinh sẽ cảm ơn bạn).

Bạn đã nói trong các bình luận, bạn đang xem xét để đưa SSD vào máy chủ của bạn. Bạn sẽ không nhận ra thiết lập của mình bằng SSD chuyên dụng, so với SAN, bạn sẽ nhận được thứ gì đó như cải thiện 500 lần ngay cả với các tệp nhật ký giao dịch và dữ liệu trên cùng một ổ đĩa. Một máy chủ SQL hiện đại sẽ có SSD riêng biệt nhanh chóng cho dữ liệu và nhật ký giao dịch trên các kênh điều khiển phần cứng khác nhau (hầu hết các bo mạch chủ máy chủ đều có một số). Nhưng so với thiết lập hiện tại của bạn, chúng tôi đang nói về khoa học viễn tưởng ở đó. Chỉ cần thử SSD.

Ok, cho bất cứ ai quan tâm,

Chúng tôi đã giải quyết vấn đề trong Câu hỏi vài tháng trước chỉ bằng cách cài đặt ổ SSD gắn trực tiếp vào mỗi 3 máy chủ và di chuyển dữ liệu DB và tệp nhật ký từ SAN sang các ổ SSD đó

Ở đây tóm tắt về những gì tôi đã làm để nghiên cứu về vấn đề này (sử dụng các đề xuất từ ​​tất cả các bài đăng câu hỏi này), trước khi chúng tôi quyết định cài đặt ổ SSD:

1) bắt đầu thu thập bộ đếm PerfMon cho các ổ đĩa sau tại cả 3 máy chủ:

Disk F:là đĩa logic dựa trên SAN, chứa tệp dữ liệu MDF
Disk I:là đĩa logic dựa trên SAN, chứa tệp nhật ký LDF
Disk T:được gắn trực tiếp SSD, chỉ dành riêng cho tempDB

Hình dưới đây là giá trị trung bình được thu thập trong khoảng thời gian 2 tuần

Disk I: (LDF)có IO nhỏ như vậy và Độ trễ rất thấp, vì vậy Đĩa I: có thể bị bỏ qua
Bạn có thể thấy rằng Disk T: (TempDB)IO có lớn hơn so với Disk F: (MDF)và nó có Độ trễ tốt hơn nhiều cùng một lúc - 0 ms

Rõ ràng có điều gì đó không ổn với Đĩa F: nơi chứa các tệp dữ liệu, nó có Độ trễ cao và Hàng đợi ghi đĩa trung bình, mặc dù IO thấp

2) Đã kiểm tra độ trễ cho cơ sở dữ liệu cá nhân bằng cách sử dụng truy vấn từ trang web này

https://www.brentozar.com/blitz/slow-st Storage-read-writes /

Rất ít cơ sở dữ liệu hoạt động trên máy chủ Chính có độ trễ đọc 150-250 ms và độ trễ ghi 150-450 ms
Điều thú vị, các tệp cơ sở dữ liệu chính và msdb có độ trễ đọc lên đến 90 ms đáng ngờ với kích thước nhỏ của dữ liệu và IO thấp - một dấu hiệu khác có gì đó không ổn với SAN

3) Không có thời gian cụ thể

Trong đó các thông báo "SQL Server đã gặp phải sự cố ..." xuất hiện
Không có bảo trì hoặc đĩa ETL nặng chạy khi các thông báo đó được ghi lại

4) Trình xem sự kiện Windows

Không hiển thị bất kỳ mục nào khác có thể gợi ý vấn đề, ngoại trừ "Máy chủ SQL đã gặp phải sự cố ..."

5) Bắt đầu kiểm tra 10 truy vấn hàng đầu

Từ sp_BlitzCache (cpu, đọc, v.v.) và tối ưu hóa khi có thể
Không có truy vấn nặng siêu IO nào có thể gây ra hàng tấn dữ liệu và ảnh hưởng đến việc lưu trữ, mặc dù
Lập chỉ mục trong cơ sở dữ liệu vẫn ổn, tôi vẫn duy trì

6) Chúng tôi không có đội SAN

Chúng tôi chỉ có 1 sysadmin giúp tìm
đường dẫn mạng tới SAN - nó được nhân lên, mỗi máy chủ có 3 cáp mạng dẫn đến chuyển mạch và sau đó đến SAN và được cho là 1 Gigabyte / giây

7) Không có kết quả CrystalDiskMark

Hoặc bất kỳ kết quả kiểm tra điểm chuẩn nào khác từ khi máy chủ được thiết lập, vì vậy tôi không biết tốc độ sẽ là bao nhiêu và không thể đo điểm chuẩn vào thời điểm này để xem tốc độ hiện tại là gì, vì nó sẽ ảnh hưởng đến Sản xuất

8) Thiết lập phiên Sự kiện mở rộng về sự kiện điểm kiểm tra cho cơ sở dữ liệu được đề cập

Phiên XE đã giúp phát hiện ra rằng trong các thông báo "Máy chủ SQL đã gặp sự cố ...", điểm kiểm tra xảy ra rất chậm (tối đa 90 giây)

9) Nhật ký lỗi máy chủ SQL

Chứa các mục "FlushCache" "Saturation"
Những mục này được cho là hiển thị khi thời gian điểm kiểm tra cho cơ sở dữ liệu đã cho vượt quá cài đặt khoảng thời gian phục hồi

Chi tiết cho thấy lượng dữ liệu mà trạm kiểm soát đang cố gắng xóa là nhỏ và mất nhiều thời gian để hoàn thành và tốc độ tổng thể là khoảng 0,25 MB / giây ... kỳ lạ

10) Cuối cùng, hình ảnh này hiển thị biểu đồ xử lý sự cố lưu trữ:

Dường như chúng ta chỉ có một "Sự cố phần cứng: - Làm việc với quản trị viên hệ thống / nhà cung cấp phần cứng để khắc phục mọi cấu hình sai của SAN, trình điều khiển cũ / bị lỗi, bộ điều khiển, chương trình cơ sở, v.v."

Trong một câu hỏi khác "Điểm kiểm tra chậm ..." Điểm kiểm tra chậm và cảnh báo I / O 15 giây trên bộ lưu trữ flash Sean có danh sách rất hay về những mục phải kiểm tra ở cấp độ phần cứng và phần mềm để khắc phục sự cố

Sysadmin của chúng tôi không thể kiểm tra tất cả mọi thứ từ danh sách, vì vậy chúng tôi chỉ đơn giản chọn cách ném một số phần cứng vào vấn đề này - nó hoàn toàn không tốn kém

Nghị quyết:

Chúng tôi đã đặt mua ổ SSD 1 TB và cài đặt trực tiếp vào máy chủ

Vì chúng tôi có Nhóm sẵn có, đã di chuyển các tệp dữ liệu DB từ SAN sang SSD trên các bản sao thứ cấp, sau đó không thành công và di chuyển các tệp trên bản chính cũ Điều này cho phép tổng thời gian chết tối thiểu - dưới 1 phút

Giờ đây, mỗi máy chủ đều có bản sao dữ liệu DB cục bộ và sao lưu toàn bộ / diff / log được thực hiện cho SAN đã đề cập
Không còn thông báo "SQL Server nào gặp phải ..." trong nhật ký Windows Event Viewer và hiệu suất sao lưu, kiểm tra tính toàn vẹn, xây dựng lại chỉ mục, truy vấn, vv đã tăng đáng kể

Hiệu suất về độ trễ IO đã được cải thiện bao nhiêu kể từ khi chúng tôi di chuyển các tệp DB sang SSD?

Để đánh giá tác động, hiệu suất được sử dụng Windows Performance Monitor ghi lại 2 tuần trước khi di chuyển và 4 tuần sau khi di chuyển:

Ngoài ra bên dưới là so sánh thống kê độ trễ của mức DB (được sử dụng thống kê tệp ảo đã bắt của SQL Server trước và sau khi di chuyển)

Tóm lược

Di chuyển từ SAN sang SSD cục bộ gắn trực tiếp là hoàn toàn xứng đáng
Nó có tác động lớn đến độ trễ lưu trữ và trung bình cải thiện hơn 90% (đặc biệt là các hoạt động VIẾT) và chúng tôi không còn tăng đột biến 20-50 giây tại IO nữa

Việc chuyển sang SSD cục bộ đã giải quyết không chỉ các vấn đề về hiệu suất lưu trữ mà còn về an toàn dữ liệu mà tôi lo ngại (nếu SAN thất bại, cả 3 máy chủ đều mất dữ liệu cùng một lúc)