Hết thời gian chờ truy vấn Azure Synapse Analytics

Question

Chúng tôi đã phải đối mặt với một vấn đề trong sản xuất muộn. Có một phiên bản DW2500c của phân tích khớp thần kinh Azure (trước đây là DWH). Mọi thứ vẫn hoạt động tốt cho đến gần đây, một nhóm đã triển khai một ứng dụng web dành cho doanh nghiệp để truy cập dữ liệu từ đó. Dữ liệu được lấy từ DWH. Những gì chúng tôi nhận thấy là đã có một lượng truy vấn và phiên tăng đột ngột gây ra sự cố đồng thời. Tôi đã đính kèm các số liệu thống kê DWHTừ tài liệu, tôi có thể thấy số phiên tối đa được phép là 1024. Điều này cho thấy rằng đó không phải là vấn đề về số phiên mà là số lượng truy vấn đồng thời (300+) và các truy vấn có thể đã đi vào hàng đợi nội bộ để chờ tài nguyên để được giải phóng. Tôi đang thực hiện một số nghiên cứu về quản lý khối lượng công việc và nghĩ rằng chúng ta có thể thử. Chúng ta vẫn cần kiểm tra các bài tập hiện tại cho các nhóm khối lượng công việc là gì và xem liệu chúng ta có cần tăng tính đồng thời hay tăng bộ nhớ hay không. Chúng tôi đã thử tăng cấp từ 2000 lên 2500 nhưng điều đó không giúp được gì. Nhưng tôi muốn có một ý kiến ​​chung, cách tốt nhất để tránh loại kịch bản này là gì?

Answer 1

Bạn nên xem kỹ lớp tài nguyên mà ứng dụng web đang truy cập vào cơ sở dữ liệu. tức là nó là một lớp tĩnh giống như staticrc80phân bổ cùng một lượng bộ nhớ không phân biệt DWU hiện tại, hoặc một lớp tài nguyên động giống như largercphân bổ một lượng bộ nhớ động tùy thuộc vào DWU. Nếu trình phát triển ứng dụng web chưa chỉ định rõ ràng bất kỳ lớp tài nguyên nào, thì rất có thể nó đang chạy tại smallrc.

Có thể các nhà thiết kế ứng dụng web nghĩ rằng ứng dụng của họ quan trọng hơn bất cứ thứ gì khác và đã tự gán cho mình một lớp tài nguyên tham lam. Dù bằng cách nào, điều này sẽ mang tính hướng dẫn. Sau đó, bạn sẽ cần thảo luận với các kiến ​​trúc sư chịu trách nhiệm về ứng dụng web, Synapse và các DBA chăm sóc Synapse của bạn về việc lập kế hoạch năng lực.

Vấn đề này cũng nên trở nên rõ ràng trong thử nghiệm tải. Ngày nay, thật dễ dàng để kiểm tra nhiều người dùng với các ứng dụng web, ví dụ như kiểm tra tải Azure DevOps , Selenium, v.v. Vui lòng hỏi các nhà phát triển ứng dụng web về kết quả kiểm tra tải của họ.

Thay vào đó, có một số điều bạn có thể làm:

• Hãy thử tính năng lưu vào bộ nhớ đệm bộ kết quả mới trong Synapse, tính năng lưu vào bộ nhớ đệm kết quả truy vấn khi được bật. Các truy vấn chạy với bộ nhớ cache không được tính vào giới hạn đồng thời của bạn. Tuy nhiên, loại này dựa trên rất nhiều truy vấn tương tự đang được chạy, nhưng tính năng này có thể làm giảm sự cố của bạn và tăng hiệu suất.
• Vì Kho dữ liệu SQL và bây giờ là Synapse không nổi tiếng về tính đồng thời lớn, nên các mẫu thay thế có thể được sử dụng, ví dụ như trung tâm và nói, nơi bạn kết xuất một số bảng nhất định vào Cơ sở dữ liệu Azure SQL thông thường (không có vấn đề tương tự) và thậm chí có thể tạm dừng của bạn Synapse (trung tâm của bạn). Yêu cầu người dùng ứng dụng web của bạn kết nối với SQL DB (nói chuyện).
• Một tính năng mới và hấp dẫn khác của Synapse là SQL theo yêu cầu . Điều này sẽ cho phép một biến thể của trung tâm và nói nơi bạn có thể kết xuất các bảng vào Azure Data Lake bằng cách sử dụng CREATE EXTERNAL TABLEvà sau đó yêu cầu người dùng ứng dụng web của bạn kết nối với điểm cuối SQL theo yêu cầu thay vì Synapse. Về lý thuyết, nó sẽ chỉ là một sự thay đổi chuỗi kết nối đối với chúng và sẽ giải quyết vấn đề đồng thời của bạn. Bạn không thể thực sự điều chỉnh các truy vấn và phạm vi T-SQL theo yêu cầu của SQL bị hạn chế hơn một chút nhưng chắc chắn đó là một mẫu thú vị và tôi đang xem xét nó ngay bây giờ.
• một giải pháp thay thế đã được thử và thử nghiệm khác là đặt Dịch vụ Phân tích Azure (AAS) hoặc Power BI trước cơ sở dữ liệu Synapse của bạn để giảm tải công việc.

HTH