Ứng dụng truy vấn các bảng trống

Công ty của tôi sử dụng một ứng dụng có vấn đề hiệu năng khá lớn. Có một số vấn đề với chính cơ sở dữ liệu mà tôi đang trong quá trình xử lý, nhưng nhiều vấn đề hoàn toàn liên quan đến ứng dụng.

Trong cuộc điều tra của tôi, tôi thấy rằng có hàng triệu truy vấn truy cập vào cơ sở dữ liệu SQL Server truy vấn các bảng trống. Chúng tôi có khoảng 300 bảng trống và một số bảng được truy vấn tới 100-200 lần mỗi phút. Các bảng không liên quan gì đến lĩnh vực kinh doanh của chúng tôi và về cơ bản là một phần của ứng dụng gốc mà nhà cung cấp đã không gỡ bỏ khi chúng được công ty tôi ký hợp đồng sản xuất một giải pháp phần mềm cho chúng tôi.

Ngoài thực tế là chúng tôi nghi ngờ nhật ký lỗi ứng dụng của chúng tôi đang bị ngập trong các lỗi liên quan đến vấn đề này, nhà cung cấp đảm bảo với chúng tôi rằng không có tác động về hiệu suất hoặc tính ổn định cho ứng dụng hoặc máy chủ cơ sở dữ liệu. Nhật ký lỗi bị ngập đến mức chúng ta không thể thấy các lỗi có giá trị hơn 2 phút để chẩn đoán.

Chi phí thực tế của các truy vấn này rõ ràng là sẽ thấp về chu kỳ CPU, v.v. Nhưng có ai có thể đề xuất ảnh hưởng gì đến SQL Server và ứng dụng không? Tôi nghi ngờ rằng các cơ chế thực tế của việc gửi yêu cầu, xác nhận nó, xử lý nó, trả lại và thừa nhận biên nhận của ứng dụng sẽ có ảnh hưởng đến hiệu suất.

Chúng tôi sử dụng SQL Server 2008 R2, Oracle Weblogic 11g cho ứng dụng.

@ Frisbee- Câu chuyện dài, tôi đã tạo một bảng chứa truy vấn văn bản đánh vào các bảng trống trong cơ sở dữ liệu của ứng dụng, sau đó truy vấn nó cho tất cả các tablenames tôi biết đều trống và có một danh sách rất dài. Lượt truy cập cao nhất là 2,7 triệu lượt thực thi trong 30 ngày hoạt động, lưu ý rằng ứng dụng này thường được sử dụng từ 8 giờ sáng đến 6 giờ chiều để những con số này tập trung hơn vào giờ hoạt động. Nhiều bảng, nhiều truy vấn, có thể một số liên quan thông qua các phép nối, một số thì không. Lượt truy cập cao nhất (2,7 triệu vào thời điểm đó) là một lựa chọn đơn giản từ một bảng trống duy nhất có mệnh đề where, không tham gia. Tôi mong đợi các truy vấn lớn hơn khi tham gia vào các bảng trống có thể bao gồm các cập nhật cho các bảng được liên kết, nhưng tôi sẽ kiểm tra và cập nhật câu hỏi này càng sớm càng tốt.

Cập nhật: Có 1000 truy vấn với số lần thực hiện trong khoảng từ 1043 - 4622614 (hơn 2,5 tháng). Tôi sẽ phải đào sâu hơn để tìm hiểu khi kế hoạch lưu trữ bắt nguồn từ đâu. Đây chỉ là để cung cấp cho bạn một ý tưởng về mức độ của các truy vấn. Hầu hết là phức tạp hợp lý với hơn 20 tham gia.

@ srutzky- vâng Tôi tin rằng có một cột ngày liên quan đến thời điểm kế hoạch được biên soạn để có thể quan tâm, vì vậy tôi sẽ kiểm tra xem. Tôi tự hỏi liệu giới hạn luồng có phải là một yếu tố hay không khi SQL Server nằm trên cụm VMware? Rất sớm trở thành một Dell PE 730xD chuyên dụng.

@Frisbee - Xin lỗi vì phản hồi muộn. Như bạn đề xuất, tôi đã chạy một lựa chọn * từ bảng trống 10.000 lần trên 24 luồng bằng SQLQueryStress (thực tế là 240.000 lần lặp) và đạt 10.000 Yêu cầu hàng loạt / giây ngay lập tức. Sau đó, tôi giảm xuống 1000 lần trên 24 chủ đề và chỉ đạt dưới 4.000 Yêu cầu hàng loạt / giây. Tôi cũng đã thử 10.000 lần lặp chỉ trong 12 luồng (vì vậy tổng số 120000 lần lặp) và điều này tạo ra 6,505 Batches / giây duy trì. Hiệu quả trên CPU thực sự đáng chú ý, khoảng 5-10% tổng mức sử dụng CPU trong mỗi lần chạy thử. Chờ đợi mạng là không đáng kể (như 3ms với máy khách trên máy trạm của tôi) nhưng chắc chắn tác động của CPU là điều đó, điều này khá là kết luận theo như tôi nghĩ. Nó dường như sôi sục với việc sử dụng CPU và một chút IO cơ sở dữ liệu không cần thiết. Tổng số lần thực hiện / giây hoạt động chỉ dưới 3000, đó là nhiều hơn trong sản xuất, tuy nhiên tôi chỉ thử nghiệm một trong hàng tá truy vấn như thế này. Hiệu ứng ròng của hàng trăm truy vấn đánh vào các bảng trống với tốc độ từ 300-4000 lần mỗi phút do đó sẽ không đáng kể khi nói đến thời gian của CPU. Tất cả các thử nghiệm được thực hiện đối với một PE 730xD nhàn rỗi với mảng flash kép và RAM 256 GB, 12 lõi hiện đại.

@ srutzky- suy nghĩ tốt. SQLQueryStress dường như sử dụng nhóm kết nối theo mặc định nhưng dù sao tôi cũng đã xem và thấy rằng có, hộp cho nhóm kết nối được chọn. Cập nhật để theo dõi

@ srutzky- Kết nối tổng hợp dường như không được bật trên ứng dụng - hoặc nếu có, nó không hoạt động. Tôi đã thực hiện theo dõi hồ sơ và thấy rằng các kết nối có EventSubClass "1 - Nonpooled" cho các sự kiện Đăng nhập kiểm toán.

RE: Pooling kết nối- Đã kiểm tra weblogics và tìm thấy pooling kết nối được kích hoạt. Chạy thêm dấu vết chống lại trực tiếp và tìm thấy dấu hiệu gộp chung không xảy ra / hoàn toàn:

Và đây là những gì nó trông giống như khi tôi chạy một truy vấn duy nhất mà không tham gia vào một bảng dân cư; các trường hợp ngoại lệ ghi "Đã xảy ra lỗi liên quan đến mạng hoặc trường hợp cụ thể trong khi thiết lập kết nối với SQL Server. Máy chủ không tìm thấy hoặc không truy cập được. Xác minh rằng tên đối tượng là chính xác và SQL Server được cấu hình để cho phép kết nối từ xa. (nhà cung cấp: Nhà cung cấp ống có tên, lỗi: 40 - Không thể mở kết nối với SQL Server) "Lưu ý bộ đếm yêu cầu hàng loạt. Ping máy chủ trong thời gian các ngoại lệ được tạo ra dẫn đến phản hồi ping thành công.

Cập nhật- hai lần chạy thử liên tiếp, cùng một khối lượng công việc (chọn * từEmptyTable), kích hoạt gộp / không bật. Việc sử dụng CPU nhiều hơn một chút và rất nhiều lỗi và không bao giờ vượt quá 500 yêu cầu lô / giây. Các thử nghiệm cho thấy 10.000 Batch / giây và không có lỗi khi gộp BẬT, và khoảng 400 lô / giây sau đó rất nhiều lỗi do gộp chung bị vô hiệu hóa. Tôi tự hỏi nếu những thất bại này có liên quan đến việc thiếu kết nối?

@ srutzky- Chọn Đếm (*) từ sys.dm_exec_connections;

• Kích hoạt nhóm: 37 liên tục, ngay cả sau khi thử nghiệm tải dừng lại

• Việc gộp nhóm bị vô hiệu hóa: 11-37 tùy thuộc vào việc có ngoại lệ
  xảy ra trên SQLQueryStress hay không : khi các máng đó xuất hiện trên
  biểu đồ Batches / giây, các ngoại lệ xảy ra trên SQLQueryStress và
  số lượng kết nối giảm xuống còn 11, sau đó dần dần lên tới 37 khi các đợt bắt đầu lên đến đỉnh điểm và các ngoại lệ không xảy ra. Rất, rất thú vị.

Kết nối tối đa trên cả hai trường hợp kiểm tra / trực tiếp được đặt ở mặc định là 0.

Đã kiểm tra nhật ký ứng dụng và không thể tìm thấy sự cố kết nối, tuy nhiên, chỉ có một vài phút ghi nhật ký có sẵn do số lượng lớn và kích thước lỗi, ví dụ: rất nhiều lỗi theo dõi ngăn xếp. Một đồng nghiệp về hỗ trợ ứng dụng khuyên rằng một số lượng đáng kể các lỗi HTTP xảy ra liên quan đến kết nối. Dường như dựa trên điều này, vì một số lý do, ứng dụng không kết nối chính xác các kết nối và kết quả là, máy chủ liên tục hết kết nối. Tôi sẽ xem xét nhật ký ứng dụng nhiều hơn. Tôi tự hỏi có cách nào để chứng minh điều này đang xảy ra trong sản xuất từ ​​phía SQL Server không?

@ srutzky- Cảm ơn bạn. Tôi sẽ kiểm tra cấu hình weblogic vào ngày mai và cập nhật. Tôi đã suy nghĩ về chỉ 37 kết nối - nếu SQLQueryStress đang thực hiện 12 luồng với 10.000 lần lặp = 120.000 câu lệnh chọn không được gộp, điều đó có nghĩa là mỗi lựa chọn sẽ tạo ra một kết nối riêng biệt với thể hiện sql?

@ srutzky- Weblogics được cấu hình để kết nối nhóm, vì vậy nó sẽ hoạt động tốt. Nhóm kết nối được cấu hình như thế này, trên mỗi 4 weblogics cân bằng tải:

• Công suất ban đầu: 10
• Công suất tối đa: 50
• Công suất tối thiểu: 5

Khi tôi tăng số lượng luồng thực hiện lựa chọn từ truy vấn bảng trống, số lượng kết nối đạt cực đại khoảng 47. Với việc gộp nhóm kết nối bị vô hiệu hóa, tôi luôn thấy một yêu cầu lô tối đa thấp hơn / giây (từ 10.000 xuống còn khoảng 400). Điều sẽ xảy ra mọi lúc là 'ngoại lệ' trên SQLQueryStress xảy ra ngay sau khi các lô / giây đi vào một máng. Nó có liên quan đến kết nối nhưng tôi không thể hiểu chính xác lý do tại sao điều này xảy ra. Khi không có bài kiểm tra nào đang chạy, #connections giảm xuống còn khoảng 12.

Với việc kết nối bị vô hiệu hóa, tôi gặp khó khăn trong việc hiểu tại sao các ngoại lệ xảy ra, nhưng có lẽ đó là một câu hỏi / câu hỏi stackExchange khác cho Adam Machanic?

@srutzky Tôi tự hỏi tại sao các trường hợp ngoại lệ xảy ra mà không kích hoạt nhóm, mặc dù SQL Server không hết kết nối?

Tôi nghi ngờ rằng các cơ chế thực tế của việc gửi yêu cầu, xác nhận nó, xử lý nó, trả lại và thừa nhận biên nhận của ứng dụng sẽ có ảnh hưởng đến hiệu suất.

Có, và thậm chí còn có một số yếu tố bổ sung, nhưng mức độ mà bất kỳ yếu tố nào trong số này thực sự ảnh hưởng đến hệ thống của bạn là không thể nói mà không phân tích hệ thống.

Điều đó đang được nói, bạn đang yêu cầu những gì có thể là một vấn đề, và có một số điều cần đề cập, ngay cả khi một số trong số này hiện không phải là một yếu tố trong tình huống cụ thể của bạn. Bạn nói thế:

Chúng tôi có khoảng 300 bảng trống và một số bảng được truy vấn tới 100-200 lần mỗi phút.

• Các bảng trống không được truy vấn không phải là một vấn đề. Nhưng tôi đoán bạn cũng có thể có nghĩa là tất cả họ đều bị truy vấn, chỉ là một số người bị tấn công nhiều hơn những người khác.
• Phân tích cú pháp truy vấn & tạo kế hoạch thực hiện không nên gây ra nhiều vấn đề nếu văn bản truy vấn được gửi vẫn giống nhau trên các cuộc gọi. SQL Server sẽ băm văn bản của truy vấn và tìm kiếm nó trong bộ đệm kế hoạch. Nếu được tìm thấy, thì nó sẽ không thực hiện lại các bước phân tích cú pháp hoặc biên dịch (cho đến khi gói được xóa khỏi bộ đệm).
• Bất kỳ bảng nào, trống hoặc không trống, sẽ yêu cầu ít nhất một khóa "chia sẻ" để chỉ ra rằng tài nguyên đang được sử dụng. Điều này ngăn các hoạt động yêu cầu khóa độc quyền (thêm / thay đổi / xóa cột, v.v.) để thực hiện thay đổi trong khi tài nguyên đang được sử dụng. Khóa và mở khóa, ngay cả khi hoàn thành trong vòng chưa đến 1 mili giây do không có dữ liệu, vẫn yêu cầu tài nguyên hệ thống (bộ nhớ và CPU) để quản lý các hoạt động khóa đó.
• Ngay cả khi không có bộ kết quả nào quay lại ứng dụng từ SQL Server, vẫn có cùng một lưu lượng truy cập mạng đến SQL Server cho dù truy vấn có mang lại kết quả hay không. Văn bản của truy vấn hoặc tên của thủ tục được lưu trữ cần phải được gửi. Và ngay cả khi không có kết quả nào quay lại, SQL Server vẫn phải gửi một số gói mạng chứa cấu trúc tập kết quả ngoài các gói cho khách hàng biết rằng tập kết quả đang bắt đầu (ngay cả khi không tìm thấy hàng nào) và sau đó tập kết quả là kết thúc và nên được đóng lại. Và có thể có thêm thông báo từ báo cáo in và / hoặc số hàng.
• Kết nối với SQL Server yêu cầu một số lượng tài nguyên hệ thống. Phải mất CPU và bộ nhớ để xử lý xác thực (cũng như các gói mạng qua lại) và điều này cũng mất thời gian. Đây là lý do tại sao Kết nối kết nối tồn tại: để cắt giảm chi phí này.
• Ngay cả với Kết nối giảm việc sử dụng tài nguyên hệ thống, SQL Server vẫn cần duy trì các kết nối đó và yêu cầu bộ nhớ và một số CPU tối thiểu.
• Ngay cả khi không có hàng và do đó thời gian thực hiện rất nhanh, truy vấn vẫn được thực hiện. Ngay cả khi có 10 hoặc 10.000 hàng và những hàng được kéo từ Vùng đệm (tức là bộ nhớ) vì chúng được sử dụng thường xuyên, một luồng vẫn cần thực hiện công việc đó. Và một luồng đang làm việc trên truy vấn vô dụng này không hoạt động trên một truy vấn hữu ích thực sự.

Thậm chí có thể có nhiều hơn, nhưng điều này sẽ giúp có được ý nghĩa của mọi thứ. Và hãy nhớ rằng giống như hầu hết các vấn đề về hiệu suất, tất cả chỉ là vấn đề quy mô. Tất cả các mục được đề cập ở trên là không có vấn đề nếu bị đánh một lần mỗi phút. Nó giống như kiểm tra một thay đổi trên máy trạm của bạn hoặc trong cơ sở dữ liệu phát triển: nó luôn hoạt động chỉ với 10 - 100 hàng trong các bảng. Chuyển mã đó sang sản xuất và phải mất 10 phút để chạy và ai đó buộc phải nói: "tốt, nó hoạt động trên hộp của tôi" ;-). Có nghĩa, đó chỉ là do khối lượng cuộc gọi tuyệt đối được thực hiện mà bạn đang thấy một vấn đề, nhưng đó là tình huống tồn tại.

Vì vậy, ngay cả ở mức 1 triệu truy vấn vô dụng, 0 hàng, số tiền đó là:

• thêm 2 triệu thao tác khóa (mọi khóa phải được mở khóa, phải không?). đây chủ yếu là một chi phí thời gian dành cho một hoạt động vô ích thay vì một hoạt động hữu ích.
• lưu lượng truy cập mạng nhiều hơn có thể giúp bạn tiến gần đến bão hòa hơn (không chắc khả năng này là như thế nào, nhưng vẫn vậy)

• nhiều kết nối đang được duy trì sẽ chiếm nhiều bộ nhớ hơn. Bạn có bao nhiêu RAM vật lý chưa sử dụng? bộ nhớ đó sẽ được sử dụng tốt hơn để chạy truy vấn và / hoặc bộ đệm kế hoạch truy vấn. Trường hợp xấu nhất là bạn hết bộ nhớ vật lý và SQL Server phải bắt đầu sử dụng bộ nhớ ảo (trao đổi), vì điều đó làm mọi thứ chậm lại (kiểm tra nhật ký lỗi SQL Server của bạn để xem bạn có nhận được thông báo về bộ nhớ bị phân trang không).

  Và chỉ trong trường hợp bất cứ ai đề cập, "tốt, có kết nối tổng hợp". Vâng, điều đó chắc chắn giúp giảm số lượng kết nối cần thiết. Nhưng với các truy vấn đến với tốc độ lên tới 200 lần mỗi phút, đó là rất nhiều hoạt động đồng thời và các kết nối vẫn cần tồn tại cho các yêu cầu hợp pháp. Làm một SELECT * FROM sys.dm_exec_connections;để xem có bao nhiêu kết nối hoạt động bạn đang duy trì.

• bất kể điều gì khác, điều này vẫn còn ít nhất 1 triệu lần mỗi ngày rằng một chủ đề có thể đã làm một cái gì đó hữu ích thay vì không có sẵn.

Nếu tôi không sai về những gì tôi đã nêu ở đây, thì dường như với tôi, ngay cả khi ở quy mô nhỏ, đây là một kiểu tấn công DDoS trên hệ thống của bạn vì nó đang tràn ngập mạng và Máy chủ SQL của bạn với các yêu cầu không có thật , ngăn các yêu cầu thực sự đến SQL Server hoặc được SQL Server xử lý.

Nếu các bảng đang bị tấn công 100-200 lần một phút thì chúng (hy vọng) trong bộ nhớ. Tải trên máy chủ rất rất thấp. Trừ khi bạn có CPU hoặc bộ nhớ cao trên máy chủ cơ sở dữ liệu, đây có thể không phải là vấn đề.

Có, các truy vấn mất khóa chia sẻ nhưng hy vọng không chặn bất kỳ khóa cập nhật nào cũng như không bị chặn bởi bất kỳ khóa cập nhật nào. Bạn có bất kỳ cập nhật, chèn hoặc xóa trên các bảng này. Nếu không tôi sẽ chỉ để nó đi - nếu bạn đang gặp vấn đề về hiệu năng thì phải có một con cá lớn hơn để chiên từ góc độ máy chủ cơ sở dữ liệu.

Tôi đã chạy thử nghiệm trên 100.000 lượt chọn (*) trên một bảng trống và nó chạy trong 32 giây và các truy vấn đã qua mạng. Vậy là 1/3 mili giây. Trừ khi mạng của bạn đang bị quá tải, điều này thậm chí không ảnh hưởng đến máy khách. Nếu bạn đang gặp vấn đề về hiệu năng lớn thì các truy vấn trống 1/3 mili giây này không phải là thứ đang giết chết ứng dụng.

Và đây có thể chỉ là một phần của việc tham gia bên trái lấy một số dữ liệu kiểu tĩnh mà không phải là một phần của ứng dụng hiện tại. Nó có thể được kết nối với các truy vấn khác để nó không phải là một chuyến đi khứ hồi. Nếu vậy, nó là cẩu thả nhưng nó thậm chí không gây ra lưu lượng truy cập nhiều hơn.

Vì vậy, trở lại để xem xét các báo cáo thực tế. Bạn có thấy bất kỳ cập nhật, thêm hoặc xóa trên các bảng này không?

Có nhiều bảng trống và truy vấn đến các bảng trống là dấu hiệu của mã hóa cẩu thả. Nhưng nếu bạn đang gặp vấn đề về hiệu năng lớn thì đây không phải là nguyên nhân trừ khi bạn có một số thao tác ghi thực sự cẩu thả cũng diễn ra với các bảng này.

Nói chung trên mỗi truy vấn, các bước sau đây được thực hiện:

1. Yêu cầu từ Ứng dụng.
2. Cơ sở dữ liệu Phân tích truy vấn.
3. Công cụ cơ sở dữ liệu kiểm tra xem truy vấn này đã được lưu trong RAM chưa. sử dụng kế hoạch thực hiện nếu tồn tại trong Bộ nhớ.
4. nếu không có trong RAM, công cụ cơ sở dữ liệu sẽ kiểm tra các số liệu thống kê hiện có về các đối tượng trong truy vấn và xác định kế hoạch thực hiện.
5. Chạy kế hoạch thực hiện, sử dụng i / o để lấy dữ liệu từ đĩa.
6. đáp ứng ứng dụng.

nhiều truy vấn như bạn đã đề cập có thể gây ra tải thêm trên một hệ thống vốn đã nặng - tải thêm vào các kết nối, CPU, RAM và I / O.