Xử lý sự cố hiệu suất là một nghệ thuật và một khoa học. Nghệ thuật đến từ kinh nghiệm (và học hỏi từ kinh nghiệm của người khác) và khoa học đến từ các hướng dẫn nổi tiếng về việc phải làm trong các tình huống nào.
Hoặc ít nhất đó là điều tôi muốn nghĩ và dạy.
Trên thực tế, nhiều DBA và nhà phát triển ngoài kia thực hành cái mà tôi gọi là xử lý sự cố hiệu suất "đầu gối". Điều này thường xảy ra khi sự cố hiệu suất đã đến giai đoạn quan trọng, chẳng hạn như truy vấn hết thời gian chờ, quy trình chạy chậm hoặc không thành công, người dùng không hài lòng và ban quản lý muốn có câu trả lời và hành động nhanh chóng!
'Gớm đầu gối' xuất phát từ việc thực hiện một số phân tích hời hợt về vấn đề và đi đến kết luận (thực sự là nó đang nắm chặt lấy một ống hút) rằng triệu chứng phổ biến nhất phải là nguyên nhân gốc rễ và cố gắng giải quyết vấn đề đó, nhưng không hoặc ít có kết quả, thường sử dụng những lời khuyên sai lầm hoặc hoàn toàn không chính xác được tìm thấy trên mạng. Điều này dẫn đến rất nhiều thất vọng và lãng phí thời gian, và thường dẫn đến lãng phí tiền bạc khi tổ chức quyết định cố gắng ném phần cứng vào vấn đề bằng cách nâng cấp máy chủ và / hoặc hệ thống con I / O, chỉ để tìm ra vấn đề vẫn còn đó. hoặc xuất hiện lại khá nhanh.
Phân tích thống kê thời gian chờ là một trong những lĩnh vực dễ khiến bạn khó chịu nhất và trong bài đăng này, tôi sẽ nói về một số kiểu chờ đợi phổ biến và những sai lầm mà mọi người xung quanh mắc phải. Một bài viết như thế này không có phạm vi để đi sâu về những việc cần làm trong từng trường hợp, nhưng tôi sẽ cung cấp cho bạn đủ thông tin để chỉ bạn đi đúng hướng.
LCK_M_XX
Hầu hết mọi người đều cho rằng nếu khóa chờ là phổ biến nhất, thì đó phải là một loại vấn đề chặn nào đó mới là vấn đề. Thông thường, chẳng hạn như thiếu chỉ mục không phân loại phù hợp gây ra quá trình quét bảng ở các mức cách ly REPEATABLE_READ hoặc SERIALIZABLE dẫn đến khóa bảng S. (Và như một gợi ý nhanh, nếu bạn không nghĩ rằng mình đã từng sử dụng SERIALIZABLE, thì bạn sẽ làm như vậy nếu bạn sử dụng các giao dịch phân tán - mọi thứ đều được chuyển đổi thành SERIALIZABLE dưới vỏ bọc, điều này có thể dẫn đến việc bị chặn và bế tắc không mong muốn.)
Tuy nhiên, thường xảy ra trường hợp việc chặn do nguyên nhân khác. Dưới mức cách ly READ_COMMITTED mặc định, các khóa bao gồm các thay đổi được giữ cho đến khi giao dịch thực hiện và sẽ chặn các lần đọc và các cập nhật khác đối với (các) hàng tương tự. Nếu bất kỳ điều gì ngăn cản giao dịch thực hiện, điều đó có thể khiến khóa hiển thị.
Ví dụ:nếu cơ sở dữ liệu được sao chép đồng bộ, thì giao dịch không thể cam kết và giải phóng các khóa của nó cho đến khi các bản ghi nhật ký được gửi qua máy nhân bản và được ghi vào ổ đĩa nhật ký của máy nhân bản. Nếu mạng bị tắc nghẽn nghiêm trọng hoặc có sự tranh chấp I / O lớn trên máy nhân bản, điều này có thể làm chậm trễ nghiêm trọng hoạt động sao chép và do đó khiến giao dịch mất nhiều thời gian hơn để thực hiện. Điều này trông giống như chặn nhưng nguyên nhân gốc rễ là tranh chấp tài nguyên để làm với sao chép.
Đối với các đợt chờ khóa, trừ khi nguyên nhân là rõ ràng khi xem xét kế hoạch truy vấn, khóa tài nguyên (ví dụ:cấp bảng biểu thị mức tăng khóa hoặc cấp độ cô lập, hãy làm theo chuỗi chặn (sử dụng tập lệnh đi qua cột blocks_session_id trong sys.dm_exec_requests và sau đó hãy xem chuỗi ở đầu chuỗi chặn đang chờ đợi điều gì. Điều đó sẽ hướng tới nguyên nhân gốc rễ.
ASYNC_NETWORK_IO
Tên của cái này gây ra rất nhiều nhầm lẫn. Bạn tập trung vào từ nào? MẠNG. Nguyên nhân của kiểu chờ này thường không liên quan gì đến mạng. Nó thực sự phải được gọi là WAITING_FOR_APP_ACK (phân đoạn bây giờ), hoặc một cái gì đó tương tự, vì đó chính xác là những gì đang xảy ra:SQL Server đã gửi một số dữ liệu đến một máy khách và đang chờ máy khách xác nhận rằng dữ liệu đã được sử dụng.
Một trong những bản trình diễn yêu thích của tôi phải làm khi dạy về thống kê chờ là chạy một truy vấn trả về một tập hợp kết quả lớn trong Management Studio và xem máy chủ sắp xếp ASYNC_NETWORK_IO đợi. Rõ ràng là không có mạng nào liên quan - chỉ là SSMS mất nhiều thời gian để trả lời SQL Server. Nó đang làm những gì được gọi là RBAR (Row-By-Agofying-Row), trong đó chỉ một hàng tại một thời điểm được lấy từ kết quả và xử lý, thay vì lưu vào bộ nhớ đệm tất cả các kết quả và sau đó trả lời ngay lập tức cho SQL Server và tiếp tục xử lý các hàng được lưu trong bộ nhớ cache.
Đây là nguyên nhân chính của ASYNC_NETWORK_IO đợi - thiết kế ứng dụng kém. Sau đó, tôi sẽ xem xét liệu máy chủ chạy mã ứng dụng có vấn đề về hiệu suất hay không, ngay cả khi bản thân mã ứng dụng được thiết kế tốt. Đôi khi đó là mạng, nhưng theo kinh nghiệm của tôi thì điều đó là hiếm.
OLEDB
Phản ứng đầu gối phổ biến ở đây là đánh đồng kiểu chờ đợi này với các máy chủ được liên kết. Tuy nhiên, thời gian chờ đợi này trở nên phổ biến hơn khi SQL Server 2005 xuất xưởng, bởi vì năm 2005 có một loạt các DMV mới và các DMV hầu hết sử dụng OLE DB. Trước khi tìm kiếm sự cố máy chủ được liên kết, tôi sẽ kiểm tra xem liệu một công cụ giám sát có đang chạy DMV liên tục trên máy chủ hay không.
Nếu bạn có các máy chủ được liên kết, hãy tiếp tục khắc phục sự cố bằng cách đi tới máy chủ được liên kết và xem số liệu thống kê chờ ở đó để xem vấn đề phổ biến nhất là gì, sau đó tiếp tục phân tích tương tự.
Một thứ khác có thể gây ra sự chờ đợi của OLEDB là DBCC CHECKDB (và các lệnh liên quan). Nó sử dụng bộ hàng OLE DB để giao tiếp thông tin giữa các hệ thống con của Bộ xử lý truy vấn và Công cụ lưu trữ.
Chờ đợi khác
Một số sự chờ đợi khác gây ra phản ứng đầu gối là CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD và WRITELOG, và tôi sẽ đề cập đến những điều đó trong bài đăng của mình vào tháng tới.
Tóm tắt
Khi bạn gặp sự cố về hiệu suất, hãy dành thời gian để hiểu dữ liệu bạn đang xem và thực hiện các cuộc điều tra sâu hơn để giúp thu hẹp nguyên nhân gốc rễ của vấn đề. Đừng chỉ nắm bắt bất cứ điều gì có vẻ là thống kê chờ đợi hàng đầu và hãy làm theo lời khuyên đầu tiên bạn bắt gặp trực tuyến (trừ khi nó từ một nguồn nổi tiếng và uy tín) nếu không bạn có thể sẽ không giải quyết được vấn đề của mình và thậm chí có thể làm cho nó tồi tệ hơn.
Về số liệu thống kê chờ chung có liên quan, bạn có thể tìm thêm thông tin về cách sử dụng chúng để khắc phục sự cố hiệu suất trong:
- Chuỗi bài đăng trên blog của tôi, bắt đầu với số liệu thống kê Chờ hoặc vui lòng cho tôi biết điều đó gây đau đớn ở đâu
- Thư viện Các loại Chờ đợi và Lớp Chốt của tôi tại đây
- Khóa đào tạo trực tuyến Pluralsight của tôi SQL Server:Khắc phục sự cố về hiệu suất sử dụng thống kê chờ
- Cố vấn Hiệu suất SQL Sentry
Đây là bài đầu tiên trong một loạt các bài đăng mà tôi sẽ thực hiện trong suốt năm nay, nói về các hành động giật (lại) xung quanh SQL Server và tại sao chúng là điều sai trái phải làm. Cho đến lần sau, chúc bạn khắc phục sự cố!
