Môi giới dịch vụ - Hội thoại trọn đời?

Chúng tôi đang cố gắng để Nhà môi giới dịch vụ làm việc trong môi trường của chúng tôi để giải quyết vụ việc kinh doanh. Tôi không biết tiêu đề thư có tốt không, nhưng câu hỏi của tôi ở bên dưới. Nhưng nó có thể không phải là một câu hỏi hay, vì vậy sau đó là những gì chúng ta đang làm và tại sao tôi nghĩ đó là câu hỏi đúng.

Có bao nhiêu tin nhắn nên được gửi trong một cuộc trò chuyện trước khi kết thúc cuộc trò chuyện?

Chúng tôi muốn sử dụng Nhà môi giới dịch vụ để cập nhật không đồng bộ bảng kết quả. Bảng kết quả được làm phẳng và nhanh chóng. Chúng tôi có các kích hoạt trên các bảng cơ sở gửi tin nhắn với bảng và khóa chính của chúng. Chúng tôi có ba hàng đợi:

• Độ trễ thấp - mục tiêu là 15 giây để xử lý. Nó xử lý các mục thay đổi liên quan đến một mục cụ thể.
• Hàng đợi số lượng lớn - mục tiêu là 5 phút để xử lý. Nó xử lý khi một cái gì đó thay đổi ảnh hưởng đến hàng trăm (hoặc hàng ngàn) mặt hàng. Nó phá vỡ danh sách các mặt hàng bị ảnh hưởng và đưa chúng vào Hàng đợi độ trễ thấp bị trì hoãn
• Trì hoãn độ trễ thấp - mục tiêu là 30 phút để xử lý. Điều này xử lý các mục nhưng chỉ từ hàng đợi số lượng lớn.

Về cơ bản, nếu thông tin của khách hàng cập nhật; có ảnh hưởng đến nhiều sản phẩm để được gửi đến hàng đợi để xử lý chậm hơn. Tuy nhiên, nếu một sản phẩm được cập nhật, nó sẽ được gửi đến hàng đợi có độ trễ thấp.

Chúng tôi sử dụng lại các cuộc hội thoại tương tự như blog của Remus Rusanu http://rusanu.com/2007/04/25/reUSE-conversations/ , ngoại trừ việc chúng tôi thực hiện dựa trên mô-đun của khóa chính. Điều này có lợi ích phụ của việc hỗ trợ sao chép lại khóa chính.

Vì vậy, chúng tôi đang sử dụng lại các cuộc hội thoại và nằm trong hướng dẫn của chúng tôi. Với hai luồng, tôi có thể ghi 125 tin nhắn / giây (giảm giả tạo vài nghìn tin nhắn), nhiều hơn khả năng theo kịp quá trình sản xuất (ước tính 15 tin nhắn / giây).

Tuy nhiên, vấn đề chúng tôi gặp phải là sau một khoảng thời gian, ~ 4 giờ hoặc 120K tin nhắn, chúng tôi bắt đầu thấy các khối và sự tranh chấp cao trên sysdesend và bảng xếp hàng. Các khóa là LCK_M_U và là các khóa KEY. Đôi khi hobt phân giải thành sysdesend và othertimes vào bảng xếp hàng cụ thể (queue_).

Chúng tôi có một quy trình tại chỗ sẽ kết thúc các cuộc trò chuyện sau 24 giờ hoặc 30 phút không hoạt động, vì vậy chúng tôi chỉ có thể tăng thời gian trước khi chuyển qua các cuộc hội thoại.

Chúng tôi đang sử dụng SQL 2016 Enterprise (13.0.4001.0)

1. Hỏa hoạn kích hoạt (gửi đến độ trễ thấp hoặc số lượng lớn)
2. Tra cứu hoặc tạo xử lý cuộc trò chuyện.
3. gửi tin nhắn
4. Thủ tục kích hoạt hàng đợi
5. Cập nhật bảng kết quả

Quá trình dọn dẹp chạy cứ sau 10 phút để xem có cuộc trò chuyện nhàn rỗi nào không. nếu nó tìm thấy chúng nhiều hơn ba lần liên tiếp, nó đánh dấu nó là không hoạt động và kết thúc các cuộc hội thoại.

Xin vui lòng cho tôi biết nếu có bất kỳ chi tiết bổ sung có thể có lợi. Tôi không có nhiều kinh nghiệm với Nhà môi giới dịch vụ nên tôi không biết tin nhắn / giây của chúng tôi thấp, cao hay thờ ơ.

CẬP NHẬT

Vì vậy, chúng tôi đã thử lại ngày hôm nay và gặp phải vấn đề tương tự. Chúng tôi đã thay đổi thời gian trò chuyện thành 2 giờ và điều đó không có kết quả. Vì vậy, sau đó chúng tôi thực hiện thủ thuật 150; trong đó có cùng một vấn đề.

Hàng tấn chờ đợi trên GỬI CHUYỂN ĐỔI, chờ đợi trên sysdesend. Có ai có thêm ý tưởng nào không?

CẬP NHẬT 2

Chúng tôi đã chạy thử nghiệm lâu hơn hôm nay và trong một trong những khoảng thời gian mẫu là 17 phút, chúng tôi đã xử lý 41K tin nhắn trên 4 tay cầm hội thoại. Chúng tôi đã có thể theo kịp ngoại trừ về cuối khi các khóa trên sysdesend và bảng xếp hàng trở nên quá nhiều và chúng tôi bắt đầu trôi dạt phía sau trước khi dừng nó lại. Chúng tôi dường như không có vấn đề xử lý tin nhắn, không có thứ gì vào hàng đợi, chúng tôi có thể kéo chúng ra và xử lý chúng ít nhất gấp 5 lần tốc độ đó. Tốc độ của chúng tôi dường như bị hạn chế dựa trên việc thêm tin nhắn.

Trong lần kiểm tra sau, chúng tôi đã xóa một trong các trình kích hoạt chiếm 80% số tin nhắn. Ngay cả với tải giảm nhiều này, chúng tôi đã bắt đầu thấy sự chờ đợi tương tự.

CẬP NHẬT 3

Cảm ơn bạn, Remus cho lời khuyên của bạn (và cảm ơn bạn đã đăng các bài viết blog tuyệt vời như vậy về chủ đề này, họ là công cụ để đi đến điểm này).

Chúng tôi đã chạy nó một lần nữa ngày hôm nay và làm tốt hơn (như chúng tôi đã đi lâu hơn trước khi thấy sự chờ đợi và thậm chí lâu hơn trước khi nó làm tê liệt chúng tôi). Vì vậy, các chi tiết.

Chúng tôi đã thay đổi: * Tăng số lượng cuộc hội thoại được duy trì cho mỗi luồng từ 1: 1 lên 2: 1. Về cơ bản, chúng tôi đã có 8 tay cầm hội thoại cho 4 chủ đề.

• hợp nhất hàng đợi số lượng lớn (vì một tin nhắn đến có thể có nghĩa là hàng trăm tin nhắn gửi đi) để hợp nhất thành các tin nhắn nhỏ hơn, lớn hơn.

Lưu ý về nỗ lực này:

• vô hiệu hóa thủ tục kích hoạt hàng đợi mục tiêu. không thay đổi trong việc chặn (chúng tôi đã đợi 5 phút) và các tin nhắn đã được gửi đến sys.transmission_queues.

• giám sát sys.conversation_endpoint. Con số này tăng từ 0 13K rất nhanh, và sau đó tăng chậm hơn trong suốt cả ngày kết thúc vào khoảng 25K sau ~ 5 giờ. Chặn không bắt đầu xảy ra cho đến khi nó đạt 16K +/-

• Tôi đã đi vào DAC và chạy các lệnh DBREINDEX cho các hàng đợi, mặc dù từ một truy vấn, các bản ghi ma không bao giờ vượt quá 200 hoặc trước khi dọn dẹp xuất hiện và giảm số đếm xuống 0.

• sysdesend và sysdercv có số lượng giống hệt nhau là 24.932 khi tôi kết thúc bài kiểm tra.

• chúng tôi đã xử lý ~ 310K tin nhắn trong 5 giờ.

Chúng tôi đã đi rất lâu trước khi mọi thứ sụp đổ đến mức tôi thực sự nghĩ rằng chúng tôi sẽ làm điều đó lần này. Ngày mai chúng tôi sẽ cố gắng buộc các tin nhắn đi qua dây.

Tôi biết đó là hình thức xấu để trả lời câu hỏi của riêng bạn, nhưng tôi muốn đóng nó cho bất cứ ai quan tâm. Cuối cùng chúng tôi đã xoay sở để giải quyết vấn đề, hoặc ít nhất là giải quyết nó đủ để đáp ứng yêu cầu của chúng tôi. Tôi muốn cảm ơn tất cả những người đã đóng góp ý kiến; Remus Rusanu và Kin vì họ rất hữu ích.

Cơ sở dữ liệu của chúng tôi khá bận rộn và đang ở chế độ RCSI. Chúng tôi có nhiều (hàng ngàn) thiết bị di động cập nhật thông tin vị trí của họ cứ sau 45 giây. Thông qua các cập nhật này, nhiều bảng được cập nhật thông tin của họ (thiết kế kém, vì tôi sẽ giới hạn thông tin dễ bay hơi vào một bảng duy nhất và sau đó tham gia vào đó để biết kết quả). Các bảng này giống với các bảng mà chúng tôi đã cố gắng tạo không đồng bộ thông tin báo cáo thay vì để người dùng cuối đi trực tiếp vào các bảng cơ sở.

Ban đầu, chúng tôi đã kích hoạt thực hiện một con trỏ trên các bản ghi đã sửa đổi trong mỗi câu lệnh cập nhật / chèn (đáng lẽ phải là một hàng trong hầu hết các trường hợp) và gửi từng khóa chính trong một tin nhắn cho nhà môi giới dịch vụ. Bên trong môi giới dịch vụ, đặc biệt là hàng đợi số lượng lớn là các con trỏ tiếp tục thực hiện quy trình nâng cấp cho báo cáo (một thực thi cho mỗi khóa chính).

Điều cuối cùng đã khiến chúng tôi làm việc:

• Chúng tôi đã loại bỏ các con trỏ và giải quyết gửi tin nhắn lớn hơn. Vẫn là một tin nhắn cho mỗi giao dịch người dùng trên mỗi bảng, nhưng hiện tại chúng tôi gửi tin nhắn có nhiều hơn một khóa chính.

• Bộ xử lý hàng loạt cũng gửi nhiều khóa cho mỗi tin nhắn, giúp giảm số lần GỬI CHUYỂN ĐỔI đang diễn ra khi nó xáo trộn các tin nhắn sang hàng đợi khác nếu phù hợp.

• Bảng dễ bay hơi nhất (bảng dữ liệu thiết bị di động của chúng tôi) đã loại bỏ các kích hoạt. Chúng tôi đã cập nhật quy trình nâng cấp để bao gồm các khóa ngoại thích hợp và bây giờ chúng tôi chỉ cần tham gia lại trên bảng đó khi tìm nạp kết quả cho người dùng. Bảng này dễ dàng đóng góp 80% các tin nhắn chúng tôi phải xử lý trong một ngày.

Chúng tôi xử lý ~ 1 triệu tin nhắn mỗi ngày (không có bảng Di động) và phần lớn (99% +) tin nhắn của chúng tôi được xử lý trong mục tiêu của chúng tôi. Chúng tôi vẫn có những ngoại lệ không thường xuyên nhưng do tính chất hiếm có của nó được coi là chấp nhận được.

Yếu tố góp phần:

• Tôi đã tìm thấy một lỗi trong quy trình dọn dẹp cuộc trò chuyện được đề cập trước đó không thực sự làm sạch các cuộc hội thoại một cách thích hợp và kết thúc sớm chúng. Điều này hiện đã dẫn đến số lượng sysdesend của chúng tôi không bao giờ nhiều hơn vài nghìn (phần lớn đến từ việc sử dụng thủ thuật 150).

• Các con trỏ trong trình kích hoạt dường như giữ nhiều khóa hơn dự đoán (ngay cả với tĩnh, Forward_only). loại bỏ những cái dường như đã làm cho các khóa mà chúng ta thấy trên GỬI CHUYỂN ĐỔI trong tự nhiên hơn (hoặc ít nhất là những lần chúng ta thấy thấp hơn nhiều).

• Về cơ bản, chúng tôi đã chạy hai giải pháp cạnh nhau (phụ trợ giải pháp của Nhà môi giới dịch vụ (để thử nghiệm theo tải sản xuất)) và giải pháp hiện tại (truy vấn khủng khiếp kéo dài nhiều bảng).

Là một lợi ích phụ, điều này đã phát hiện ra sự cố Ghost Record Cleanup và mặc dù nó không nằm trên các bảng của Nhà môi giới dịch vụ (hệ thống hoặc hàng đợi), nhưng nó khá lan man trong hệ thống của chúng tôi và các triệu chứng thực sự phù hợp với "không có nguyên nhân rõ ràng" vấn đề chúng ta gặp nhiều lúc Điều tra đang diễn ra trên đó, chúng tôi đang cố gắng tìm các bảng đóng góp cho nó và có lẽ chúng tôi sẽ thường xuyên xây dựng lại các chỉ mục của chúng.

Cảm ơn bạn một lần nữa.