Vì sao cơ sở dữ liệu chậm vào giờ cao điểm và cách nhận biết thời gian chờ khóa
Hiệu năng cơ sở dữ liệu chậm vào giờ cao điểm thường do hàng đợi và tranh chấp khóa, không phải do lỗi phần cứng đột ngột. Trong công việc tối ưu hiệu năng CNTT, đây là mô hình quen thuộc: một hệ thống phản hồi bằng mili giây trong thời gian im ắng bắt đầu mất vài giây ngay khi lưu lượng tăng. Cơ sở dữ liệu thường vẫn đang chạy, nhưng các yêu cầu đang chờ. Hiểu vì sao cơ sở dữ liệu chậm vào giờ cao điểm và cách nhận biết thời gian chờ khóa giúp nhóm chẩn đoán nguyên nhân trước khi người dùng báo vấn đề.
Vì sao giờ cao điểm làm lộ rõ nút thắt cổ chai của cơ sở dữ liệu
Lưu lượng không ảnh hưởng đến cơ sở dữ liệu theo cách tuyến tính đơn giản. Khi có nhiều phiên kết nối hơn, mỗi giao dịch cạnh tranh cho các tài nguyên dùng chung như CPU, bộ nhớ, I/O lưu trữ, khe kết nối và khóa nội bộ. Khi nhu cầu tiến sát dung lượng, những mức tăng nhỏ về đồng thời có thể gây ra mức tăng lớn về thời gian phản hồi.
Giờ cao điểm cũng làm thay đổi cơ cấu công việc. Truy vấn báo cáo, tác vụ theo lô, bảo trì nền và yêu cầu tương tác có thể chạy cùng lúc. Một truy vấn vô hại khi xét riêng có thể giữ khóa hoặc tiêu tốn lượng I/O lớn trong khi nhiều giao dịch ngắn xếp hàng phía sau. Kết quả là một hàng đợi: công việc đến nhanh hơn khả năng xử lý của cơ sở dữ liệu.
Hàng đợi giải thích vì sao độ trễ có thể tăng mạnh ngay cả khi thông lượng trung bình có vẻ ổn định. Nếu cơ sở dữ liệu có thể xử lý 100 giao dịch mỗi giây và lưu lượng đạt 95, hệ thống có vẻ khỏe mạnh. Khi lưu lượng đạt 99, thời gian chờ có thể tăng nhanh hơn nhiều so với mức tăng của tải. Càng gần bão hòa, hệ thống càng nhạy với các đợt bùng phát, lưu trữ chậm hoặc một vài truy vấn tốn kém.
Tranh chấp khóa: khi các giao dịch chờ lẫn nhau
Khóa bảo vệ tính nhất quán dữ liệu. Một giao dịch cập nhật một dòng có thể giữ khóa cho đến khi commit hoặc rollback. Các giao dịch khác cần cùng dòng, trang hoặc bảng phải chờ. Thời gian chờ ngắn là bình thường, nhưng thời gian chờ dài gây ra hiện tượng chậm rõ rệt.
Tranh chấp khóa có nhiều khả năng xảy ra hơn khi giao dịch kéo dài, khi mã ứng dụng gọi mạng hoặc thao tác người dùng bên trong giao dịch cơ sở d�� liệu, hoặc khi nhiều phiên cập nhật cùng các bản ghi nóng. Chỉ một truy vấn chậm cũng có thể giữ khóa trong khi hàng chục yêu cầu khác xếp hàng phía sau. Đây là lý do một phiên đang chặn có thể ảnh hưởng đến cả một tính năng, ngay cả khi máy chủ cơ sở dữ liệu vẫn còn CPU dự phòng.
Thời gian chờ cũng có nhiều cấp độ khác nhau. Thời gian chờ ở cấp dòng có thể ảnh hưởng đến một số giao dịch nhỏ, trong khi thời gian chờ ở cấp bảng có thể dừng nhiều phần lớn hơn của khối lượng công việc. Câu hỏi quan trọng không chỉ là có tồn tại khóa hay không, mà là哪些 phiên đang chờ,哪些 phiên đang chặn chúng và chuỗi đó đã kéo dài trong bao lâu.
Cách nhận biết thời gian chờ khóa
Bắt đầu bằng các sự kiện chờ. Hầu hết công cụ giám sát cơ sở dữ liệu đều hiển thị thời gian chờ hiện tại theo danh mục. Hãy tìm các thời gian chờ liên quan đến khóa, latch, buffer pool, ghi log và I/O lưu trữ. Số thời gian chờ khóa tăng trong giờ cao điểm là tín hiệu mạnh cho thấy tranh chấp, thay vì năng lực CPU thuần túy, là vấn đề chính.
Tiếp theo, xác định chuỗi chặn. Tìm các phiên giữ khóa và các phiên đang chờ khóa đó. Ghi lại câu lệnh đang thực thi, thời điểm bắt đầu giao dịch, chế độ khóa và số phiên đang chờ. Một chuỗi có giao dịch chạy lâu ở đỉnh thường chỉ ra hành vi ứng dụng hoặc tác vụ theo lô được lên lịch không phù hợp.
So sánh thời gian chờ với thời gian thực thi. Một truy vấn mất 50 mili giây để thực thi nhưng chờ 3 giây không nhất thiết tự nó không hiệu quả; nó có thể bị một phiên khác chặn. Ngược lại, một truy vấn chạy 3 giây mà không có thời gian chờ khóa có thể cần chỉ số, kế hoạch tốt hơn hoặc ít dòng hơn. Việc tách thời gian thực thi khỏi thời gian chờ giúp tránh những kết luận sai lệch.
Theo dõi xu hướng thay vì các ảnh chụp riêng lẻ. Thời gian chờ khóa thường xuất hiện theo các đợt ngắn quanh tác vụ theo lô, triển khai hoặc bùng phát lưu lượng. Thu thập dữ liệu theo khoảng một phút và so sánh thời gian im ắng với giờ cao điểm. Đồng thời theo dõi mức sử dụng kết nối, phiên hoạt động, mức sử dụng CPU, độ trễ lưu trữ và thông lượng giao dịch cùng nhau. Sự kết hợp này giúp phân biệt vấn đề khóa với việc cạn kiệt tài nguyên.
Các nguyên nhân phổ biến phía sau mô hình này
- Giao dịch dài: Các phiên mở trong khi chờ logic ứng dụng, API bên ngoài hoặc đầu vào người dùng duy trì khóa lâu hơn mức cần thiết.
- Dòng nóng: Bộ đếm, bản ghi tồn kho và bảng hàng đợi nhận nhiều cập nhật tại cùng một vị trí, tạo ra tranh chấp lặp đi lặp lại.
- Thiếu hoặc sai chỉ số: Một truy vấn quét nhiều dữ liệu hơn dự kiến, làm tăng I/O và thời gian giữ khóa.
- Công việc theo lô không phối hợp: Các tác vụ báo cáo hoặc bảo trì chạy trong khung giờ bận nhất và cạnh tranh với lưu lượng tương tác.
- Cơn bão kết nối: Ứng dụng mở quá nhiều phiên, làm tăng việc chuyển ngữ cảnh và khiến hàng đợi xấu đi.
- Độ trễ lưu trữ: Ghi log hoặc đọc dữ liệu chậm làm kéo dài thời gian giao dịch, từ đó gián tiếp làm tăng thời gian chờ khóa.
Phải làm gì khi tìm ra nút thắt cổ chai
Trước hết, xác định nguồn chặn. Nếu một giao dịch dài đang giữ các khóa quan trọng, hãy quyết định xem có thể rút ngắn, di chuyển hay hủy an toàn hay không. Xem lại mã ứng dụng đối với các công việc thực hiện bên trong giao dịch và đưa các lời gọi bên ngoài ra ngoài phạm vi cơ sở dữ liệu khi có thể.
Thứ hai, giảm tranh chấp không cần thiết. Điều chỉnh phạm vi giao dịch, cập nhật các dòng theo thứ tự nhất quán và cân nhắc xem có thể thiết kế lại bản ghi nóng hay không. Trong một số trường hợp, thay đổi nhỏ về schema hoặc mẫu truy cập loại bỏ xung đột hiệu quả hơn nâng cấp phần cứng.
Thứ ba, tách các khối lượng công việc. Lên lịch báo cáo nặng trong thời gian im ắng, giới hạn mức đồng thời theo lô và sử dụng kiểm soát tài nguyên để bảo vệ lưu lượng tương tác. Nếu CPU hoặc lưu trữ cũng đã bão hòa, cải thiện dung lượng có thể hữu ích, nhưng chỉ sau khi hành vi chờ đã được đo lường.
Cuối cùng, đưa khả năng quan sát vào giám sát thường xuyên. Theo dõi thời gian chờ khóa, chuỗi chặn, truy vấn chậm và chiều sâu hàng đợi như các chỉ số chuẩn. Khi cơ sở dữ liệu chậm vào giờ cao điểm, mục tiêu là thấy哪些 yêu cầu đang chờ và tại sao. Góc nhìn đó biến một phàn nàn hiệu năng mơ hồ thành một chẩn đoán cụ thể, có thể hành động.
