Gần đây tôi đã gặp phải TRANSACTION_MUTEX cao thời gian chờ tích lũy trên hệ thống khách hàng. Tôi không thể nhớ lại trường hợp mà tôi thấy kiểu chờ đợi này ở gần đầu danh sách "số lần chờ cao" và tôi tò mò về những yếu tố nào có thể đẩy loại thời gian chờ tổng thể này.
Định nghĩa Sách Trực tuyến của TRANSACTION_MUTEX là nó "xảy ra trong quá trình đồng bộ hóa quyền truy cập vào một giao dịch theo nhiều lô." Không có nhiều khu vực trong công cụ SQL Server hiển thị loại chức năng này, vì vậy cuộc điều tra của tôi được thu hẹp thành các công nghệ sau:
-
sp_getbindtokenkhông dùng nữa vàsp_bindsessionhệ thống lưu trữ các thủ tục được sử dụng để xử lý các kết nối ràng buộc - Giao dịch phân tán
- MARS (Nhiều Bộ Kết quả Hoạt động)
Mục tiêu của tôi là kiểm tra từng công nghệ và xem liệu nó có ảnh hưởng đến TRANSACTION_MUTEX hay không loại chờ đợi.
Thử nghiệm đầu tiên tôi thực hiện đã sử dụng sp_getbindtoken không dùng nữa và sp_bindsession các thủ tục được lưu trữ. sp_getbindtoken trả về một số nhận dạng giao dịch sau đó có thể được sử dụng bởi sp_bindsession để liên kết nhiều phiên với nhau trên cùng một giao dịch.
Trước mỗi tình huống thử nghiệm, tôi đảm bảo xóa số liệu thống kê chờ phiên bản SQL Server thử nghiệm của mình:
DBCC SQLPERF('waitstats', CLEAR);
GO
Phiên bản SQL Server thử nghiệm của tôi đang chạy SQL Server 2012 SP1 Developer Edition (11.0.3000). Tôi đã sử dụng cơ sở dữ liệu mẫu Tín dụng, mặc dù bạn có thể sử dụng bất kỳ loại cơ sở dữ liệu mẫu nào khác như AdventureWorks nếu bạn muốn, vì lược đồ và phân phối dữ liệu không liên quan trực tiếp đến chủ đề của bài viết này và không cần thiết để thúc đẩy TRANSACTION_MUTEX thời gian chờ đợi.
sp_getbindtoken / sp_bindsession
Trong cửa sổ phiên đầu tiên của SQL Server Management Studio, tôi đã thực thi mã sau để bắt đầu giao dịch và xuất mã liên kết để nhập ngũ vào các phiên đã lên kế hoạch khác:
USE Credit; GO BEGIN TRANSACTION; DECLARE @out_token varchar(255); EXECUTE sp_getbindtoken @out_token OUTPUT; SELECT @out_token AS out_token; GO
Điều này trả lại một @out_token trong tổng số S/Z5_GOHLaGY<^i]S9LXZ-5---.fE--- . Trong hai cửa sổ truy vấn SQL Server Management Studio riêng biệt, tôi đã thực thi mã sau để tham gia vào các phiên hiện có (truy cập giao dịch được chia sẻ):
USE Credit; GO EXEC sp_bindsession 'S/Z5_GOHLaGY<^i]S9LXZ-5---.fE---';
Và với cửa sổ phiên đầu tiên vẫn mở, tôi đã bắt đầu vòng lặp sau để cập nhật bảng của bảng tính phí với ngày tính phí bằng ngày và giờ hiện tại, sau đó thực hiện cùng một logic trong hai cửa sổ khác (ba phiên hoạt động trong vòng lặp):
WHILE 1 = 1
BEGIN
UPDATE dbo.charge
SET charge_dt = SYSDATETIME();
END
Sau một vài giây, tôi đã hủy từng truy vấn đang thực thi. Trong số ba phiên, chỉ một phiên có thể thực sự thực hiện cập nhật - mặc dù hai phiên còn lại được tham gia tích cực vào cùng một giao dịch. Và nếu tôi đã xem TRANSACTION_MUTEX loại chờ đợi, tôi có thể thấy rằng nó đã thực sự tăng lên:
SELECT [wait_type],
[waiting_tasks_count],
[wait_time_ms],
[max_wait_time_ms],
[signal_wait_time_ms]
FROM sys.dm_os_wait_stats
WHERE wait_type = 'TRANSACTION_MUTEX'; Kết quả cho thử nghiệm cụ thể này như sau:
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms TRANSACTION_MUTEX 2 181732 93899 0
Vì vậy, tôi thấy rằng có hai tác vụ đang chờ (hai phiên đồng thời cố gắng cập nhật cùng một bảng thông qua vòng lặp). Vì tôi chưa thực hiện SET NOCOUNT ON , Tôi có thể thấy rằng chỉ UPDATE được thực thi đầu tiên vòng lặp có các thay đổi trong. Tôi đã thử kỹ thuật tương tự này bằng cách sử dụng một vài biến thể khác nhau (ví dụ - bốn phiên tổng thể, với ba phiên chờ) - và TRANSACTION_MUTEX tăng dần cho thấy hành vi tương tự. Tôi cũng thấy TRANSACTION_MUTEX tích lũy khi cập nhật đồng thời một bảng khác nhau cho mỗi phiên - vì vậy không cần sửa đổi đối với cùng một đối tượng trong một vòng lặp để tái tạo TRANSACTION_MUTEX tích lũy thời gian chờ đợi.
Giao dịch phân tán
Thử nghiệm tiếp theo của tôi liên quan đến việc xem TRANSACTION_MUTEX thời gian chờ đợi đã được tăng lên cho các giao dịch phân tán. Đối với thử nghiệm này, tôi đã sử dụng hai phiên bản SQL Server và một máy chủ được liên kết được kết nối giữa hai phiên bản đó. MS DTC đang chạy và được định cấu hình đúng cách và tôi đã thực thi đoạn mã sau để thực hiện DELETE cục bộ và một DELETE từ xa thông qua máy chủ được liên kết và sau đó khôi phục các thay đổi:
USE Credit; GO SET XACT_ABORT ON; -- Assumes MS DTC service is available, running, properly configured BEGIN DISTRIBUTED TRANSACTION; DELETE [dbo].[charge] WHERE charge_no = 1; DELETE [JOSEPHSACK-PC\AUGUSTUS].[Credit].[dbo].[charge] WHERE charge_no = 1; ROLLBACK TRANSACTION;
TRANSACTION_MUTEX cho thấy không có hoạt động nào trên máy chủ cục bộ:
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms TRANSACTION_MUTEX 0 0 0 0
Tuy nhiên, số lượng nhiệm vụ chờ đã tăng lên trên máy chủ từ xa:
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms TRANSACTION_MUTEX 1 0 0 0
Vì vậy, kỳ vọng của tôi khi thấy điều này đã được xác nhận - với điều kiện là chúng tôi có một giao dịch phân tán với nhiều hơn một phiên được tham gia theo một cách nào đó với cùng một giao dịch.
MARS (Nhiều Bộ Kết quả Hoạt động)
Còn về việc sử dụng Nhiều Bộ Kết quả Hoạt động (MARS) thì sao? Chúng ta cũng sẽ thấy TRANSACTION_MUTEX tích lũy khi kết hợp với việc sử dụng MARS?
Đối với điều này, tôi đã sử dụng mã ứng dụng bảng điều khiển C # sau được kiểm tra từ Microsoft Visual Studio dựa trên phiên bản SQL Server 2012 của tôi và cơ sở dữ liệu Tín dụng. Logic của những gì tôi thực sự đang làm không hữu ích lắm (trả về một hàng từ mỗi bảng), nhưng các trình đọc dữ liệu trên cùng một kết nối và thuộc tính kết nối MultipleActiveResultSets được đặt thành true, do đó, đủ để xác minh xem MARS thực sự có thể thúc đẩy TRANSACTION_MUTEX hay không tích lũy cũng như:
string ConnString = @"Server=.;Database=Credit;Trusted_Connection=True;MultipleActiveResultSets=true;";
SqlConnection MARSCon = new SqlConnection(ConnString);
MARSCon.Open();
SqlCommand MARSCmd1 = new SqlCommand("SELECT payment_no FROM dbo.payment;", MARSCon);
SqlCommand MARSCmd2 = new SqlCommand("SELECT charge_no FROM dbo.charge;", MARSCon);
SqlDataReader MARSReader1 = MARSCmd1.ExecuteReader();
SqlDataReader MARSReader2 = MARSCmd2.ExecuteReader();
MARSReader1.Read();
MARSReader2.Read();
Console.WriteLine("\t{0}", MARSReader1[0]);
Console.WriteLine("\t{0}", MARSReader2[0]);
Sau khi thực thi mã này, tôi thấy phần tích lũy sau cho TRANSACTION_MUTEX :
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms TRANSACTION_MUTEX 8 2 0 0
Vì vậy, như bạn có thể thấy, hoạt động MARS (tuy nhiên được triển khai một cách nhẹ nhàng) đã gây ra sự gia tăng trong TRANSACTION_MUTEX tích lũy kiểu chờ đợi. Và bản thân thuộc tính chuỗi kết nối không thúc đẩy điều này, việc triển khai thực tế thì có. Ví dụ:tôi đã xóa triển khai trình đọc thứ hai và chỉ duy trì một trình đọc duy nhất với MultipleActiveResultSets=true và như mong đợi, không có TRANSACTION_MUTEX tích lũy thời gian chờ đợi.
Kết luận
Nếu bạn thấy TRANSACTION_MUTEX cao chờ đợi trong môi trường của bạn, tôi hy vọng bài đăng này cung cấp cho bạn một số thông tin chi tiết về ba con đường để khám phá - để xác định cả những sự chờ đợi này đến từ đâu và liệu chúng có cần thiết hay không.
