Câu lệnh CHỌN từ xa chậm do thời gian xử lý máy khách của Long, nhưng nhanh cục bộ


11

Trong khi được kết nối với máy chủ sản xuất của chúng tôi (SQL Server 2008, máy rất mạnh), câu lệnh CHỌN này mất 2 giây , quay lại tất cả các trường (tổng cộng 4 MB dữ liệu).

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

Từ bất kỳ hộp nào khác trên cùng một mạng (kết nối bằng xác thực SQL hoặc Xác thực Windows), cùng một truy vấn mất 1 phút, 8 giây .

Tôi đang thử nghiệm với tuyên bố rất đơn giản này để minh họa rằng đó không phải là vấn đề lập chỉ mục hoặc vấn đề liên quan đến truy vấn. (Chúng tôi có vấn đề về hiệu suất với tất cả các truy vấn tại thời điểm này ...)

Các hàng đến trong khối, và không phải tất cả cùng một lúc. Tôi nhận được các hàng đầu tiên của mình ngay lập tức và sau đó đợi hơn 1 phút để các lô hàng được đưa vào.

Dưới đây là Thống kê khách hàng của truy vấn, khi nó được chạy từ hộp từ xa:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

Chúng ta có thể thấy rằng "Thời gian xử lý của khách hàng" bằng tổng thời gian thực hiện.

Có ai biết những bước tôi có thể thực hiện để chẩn đoán tại sao việc truyền dữ liệu thực tế lại mất nhiều thời gian không?

Có tham số cấu hình SQL nào hạn chế hoặc giới hạn tốc độ truyền dữ liệu giữa các máy không?


Nhân tiện, chúng tôi đã thử sao chép tệp có cùng kích thước (4 MB) giữa máy chủ DB và một hộp khác, và việc đó mất một giây. Vì vậy, dường như không phải là một vấn đề mạng.
FranticRock

Ứng dụng khách là gì? SSMS trên máy trạm của người dùng cuối?
Thomas Stringer

Có Microsoft SQL Server Management Studio 10.50.1600.1. 2008 R2
FranticRock

Vấn đề này bắt đầu từ khi chúng tôi di chuyển các trung tâm dữ liệu và toàn bộ máy đã được cài đặt lại (mọi thứ bao gồm SQL). Chúng tôi với một nhà cung cấp lưu trữ rất đáng kính.
FranticRock

Câu trả lời:


4

Vấn đề của bạn chắc chắn là liên quan đến mạng, dựa trên thông tin của bạn. Như vậy, nó phải được xử lý với các chuyên gia mạng (tôi không phải là người duy nhất).

Những điều có thể giúp:

  • Thẻ NIC nhanh hơn (trên máy chủ SQL).
  • Thêm thẻ / mạng con được phân bổ / cụ thể giữa các máy chủ (máy chủ web và SQL Server).

Là máy chủ web trong cùng mạng con với máy chủ SQL?

Có bộ định tuyến / cầu nối giữa chúng không?

Không có nhiều thay đổi có thể có trên máy chủ SQL:

  • Dữ liệu đầu ra đang được gửi bởi SQL Server với MS "giao thức TDS" độc quyền.
  • Kích thước mặc định của bộ đệm TDS là 4 KB. Xem trong MSDB: "Tùy chọn kích thước gói mạng"
  • Nén dữ liệu (với SQL Server hoặc ứng dụng bên ngoài) - tùy thuộc vào bản chất của dữ liệu.

Bạn đang sử dụng kích thước mặc định: xem số liệu thống kê của bạn: "Các gói TDS nhận được từ máy chủ 1216" (4MB / 1K = 4KB). Có, kích thước của bộ đệm TDS có thể được thay đổi: xem trong google: "Kích thước lô giao thức TDS"

Thảo luận tốt về chủ đề: "kích thước gói mạng của sql có thực sự xác định lưu lượng chuyến đi khứ hồi không?"

Tuy nhiên, việc thay đổi kích thước gói TDS (chắc chắn) sẽ có tác dụng không thể đoán trước và chỉ nên được sử dụng trong sản xuất trong các trường hợp đặc biệt.

Thay đổi kiến ​​trúc hoặc giới thiệu bộ nhớ đệm dữ liệu trên tầng giữa cũng sẽ có ích.


7

Vấn đề này hiện đã được giải quyết.

Đó là một sự cố mạng và hộp SQL đã sử dụng thẻ NIC 100 MB / s , thay vì thẻ NIC 10 GB / giây ...

Thay đổi cấu hình mạng để sử dụng card mạng chính xác đã khắc phục sự cố. Bây giờ chúng tôi đang nhận được hiệu suất tương tự cho tất cả các truy vấn từ hộp SQL sản xuất và từ các hộp khác trên mạng.

Cảm ơn mọi người đã giúp đỡ.


3

Lúc đầu đọc có vẻ như bạn đang gặp một số vấn đề về độ trễ mạng. Bạn đã xem một số quầy của Perfmon Network chưa? Chúng có thể cung cấp cho bạn một số dấu hiệu về những gì đang xảy ra với mạng.

Trích dẫn từ những gì quầy Perfmon tôi nên theo dõi và ý nghĩa của từng người trong số họ?

MẠNG IO

Để đo I / O mạng, bạn có thể sử dụng các bộ đếm sau:

Giao diện mạng Tổng số tế bào / giây

Ngưỡng: Các giá trị duy trì của hơn 80 phần trăm băng thông mạng.

Ý nghĩa: Bộ đếm này cho biết tốc độ gửi và nhận byte qua mỗi bộ điều hợp mạng. Bộ đếm này giúp bạn biết liệu lưu lượng tại bộ điều hợp mạng của bạn đã bão hòa chưa và nếu bạn cần thêm bộ điều hợp mạng khác. Bạn có thể nhanh chóng xác định sự cố như thế nào tùy thuộc vào loại mạng bạn có cũng như việc bạn có chia sẻ băng thông với các ứng dụng khác hay không.

Giao diện mạng Nhận được / giây

Bộ đếm này cho biết tốc độ mà byte được nhận qua mỗi bộ điều hợp mạng. Bạn có thể tính tốc độ của dữ liệu đến như là một phần của tổng băng thông. Điều này sẽ giúp bạn biết rằng bạn cần tối ưu hóa dữ liệu đến từ máy khách hoặc bạn cần thêm một bộ điều hợp mạng khác để xử lý lưu lượng đến.

Giao diện mạng Đã gửi / giây

Bộ đếm này cho biết tốc độ mà byte được gửi qua mỗi bộ điều hợp mạng. Bạn có thể tính tốc độ của dữ liệu đến như là một phần của tổng băng thông. Điều này sẽ giúp bạn biết rằng bạn cần tối ưu hóa dữ liệu được gửi đến máy khách hoặc bạn cần thêm một bộ điều hợp mạng khác để xử lý lưu lượng truy cập đi.

Tổng số ServerBytes / giây

Giá trị này không được quá 50 phần trăm dung lượng mạng.

Bộ đếm này cho biết số byte được gửi và nhận qua mạng. Giá trị cao hơn cho thấy băng thông mạng là nút cổ chai. Nếu tổng Byte Tổng / giây cho tất cả các máy chủ gần bằng với tốc độ truyền tối đa của mạng của bạn, bạn có thể cần phải phân đoạn mạng.

Bộ xử lý% Thời gian gián đoạn

Bộ đếm này cho biết phần trăm thời gian bộ xử lý dành để nhận và phục vụ các ngắt phần cứng. Giá trị này là một chỉ báo gián tiếp về hoạt động của các thiết bị tạo ra các ngắt, chẳng hạn như bộ điều hợp mạng.

Giao diện mạng (*) Độ dài hàng đợi đầu ra

Bộ đếm này kiểm tra xem có bao nhiêu luồng đang chờ trên bộ điều hợp mạng. Nếu có rất nhiều luồng đang chờ trên bộ điều hợp mạng, thì rất có thể hệ thống sẽ bão hòa I / O mạng rất có thể do độ trễ mạng hoặc băng thông mạng.

Chiều dài hàng đợi đầu ra là chiều dài của hàng đợi gói đầu ra (tính theo gói). Nếu điều này dài hơn hai, có sự chậm trễ và nút cổ chai nên được tìm thấy và loại bỏ, nếu có thể. Do các yêu cầu được xếp hàng bởi Đặc tả giao diện trình điều khiển mạng (NDIS) trong triển khai này, nên điều này sẽ luôn là 0.


Sau khi theo dõi các số liệu thống kê trong Perfmon, tôi nhận thấy một vài điều. Tổng số byte / giây không bao giờ tăng quá 700K / giây trên bất kỳ thẻ mạng nào. Ngay cả khi tôi đang chạy truy vấn yêu cầu megabyte dữ liệu, con số này vẫn ở mức khoảng 500K / giây. Băng thông của chúng tôi là 100 MBPS và chúng tôi thậm chí không sử dụng đến 1%. Tôi nghĩ rằng nên có một giới hạn được cấu hình ở đâu đó đang buộc giảm kích thước của các gói hoặc giới hạn tốc độ truyền. Các ngắt phần cứng / giây là 700-2000. Hàng đợi đầu ra trống. Đỉnh điểm sử dụng card mạng ở mức cao nhất khoảng 4%.
FranticRock

2
Có thể có sự không phù hợp giữa tốc độ card mạng và cổng chuyển đổi. Bạn đã tham gia nhóm mạng của mình để xem xét nó từ phía chuyển đổi chưa?
jgardner04

2

Một số câu hỏi sơ bộ: 1) Máy chủ có máy khách SQL trên Prod. Máy chủ được thiết lập, phải không? Vậy nếu bạn thực hiện cùng một truy vấn từ máy khách nằm trên cùng một máy thì nó sẽ được hoàn thành sau 2 giây? Bạn đã cố gắng để làm điều này? Có thực sự là 2 giây? 2) Bạn đã đề cập rằng cấu hình của môi trường sản xuất của bạn đã được thay đổi (hoặc máy chủ sản xuất được chuyển sang mạng / tổng máy chủ khác được thực hiện lại), phải không? Thời gian tiêu thụ truy vấn trong môi trường sản xuất cũ là gì?

Từ bất kỳ hộp nào khác trên cùng một mạng ... cùng một truy vấn mất 1 phút, 8 giây. 3) Bạn đang nói rằng truy vấn trả về và được sử dụng từ máy khách, được đặt trên bất kỳ máy nào trong mạng đã cho (trục xuất máy cụ thể của bạn) trong khoảng 70 giây? Tôi hiểu đúng? 3.1 Ngẫu nhiên thời gian tiêu thụ của truy vấn này, được doanh nghiệp chấp nhận là gì? 4) Tuy nhiên, bạn chỉ định rằng đối với một máy khách cụ thể mà bạn đang sử dụng thời gian tiêu thụ đầu ra truy vấn là: Thời gian thực hiện của máy khách 15:30: 48 15 phút? (và thời gian này rõ ràng là không thể chấp nhận)? Chính xác? 5) vì vậy vấn đề được giới hạn trong một máy khách? Hoặc để BẤT K client máy khách / máy trung cấp vv (trong môi trường mới)? 6) độ trễ được hiển thị bởi ping là gì? từ máy khách đến máy chủ? 7) Bạn (hoặc quản trị viên mạng) đã chạy tracert cả hai cách (từ máy khách đến máy chủ, từ máy chủ đến máy khách)? Có bao nhiêu bước nhảy? Thời gian kết hợp là gì? 8) Mạng lưới sản xuất cũ còn sống không? Bạn có thể so sánh bằng Ping và Traceroute - thời gian và bước nhảy giữa máy khách và máy chủ ở đó là gì không?

Vì tò mò: đây là một ví dụ về truy vấn? hoặc từ ngữ chính xác của truy vấn? Truy vấn thực sự KHÔNG chứa mệnh đề WHERE? Đồng ý với tôi rằng điều này rất bất thường .. Bảng có chỉ số cụm hoặc là Heap? Bảng chứa bao nhiêu hàng tất cả? Cái bàn bị phân mảnh nặng nề? Vì tò mò: tại sao CHỌN NNN HÀNG ĐẦU? Tại sao không THIẾT LẬP ROWCOUNT NNN - sau đó CHỌN *? Truy vấn này được khách hàng cấp bao nhiêu lần mỗi ngày? 1? 100? 1MLN? Dữ liệu dưới mức là tĩnh hoặc là động và được thay đổi nhiều? Bao nhiêu (0,01 phần trăm mỗi ngày? 1 phần trăm mỗi ngày? 10 phần trăm mỗi ngày?) Đầu ra truy vấn được xử lý theo chương trình? (không phải bởi người dùng?) Tại sao nó không được lưu trữ / không được lưu trữ trên tầng giữa? cảm ơn, Alexei


Cảm ơn rất nhiều cho các thông tin. Câu trả lời của tôi dưới đây. 1. Đúng. Các công cụ máy khách cũng được cài đặt trên prod và cùng một truy vấn tôi đã đề cập mất 2 giây để trả về tất cả 30.000 bản ghi (tổng kích thước 4 MB). Nhân tiện, truy vấn tôi sử dụng chỉ là một ví dụ. Nó không phải là một truy vấn kinh doanh thực sự. Nó chỉ là một phương tiện để lấy 4 MB dữ liệu từ một bảng. Hiện tại chúng tôi có vấn đề về hiệu suất khi đọc vài megabyte dữ liệu từ bất kỳ bảng nào với bất kỳ truy vấn nào hiện tại.
FranticRock

2. Thời gian tiêu thụ đã gần, nếu không giống với truy vấn tương tự được chạy cục bộ từ hộp SẢN PHẨM. (IE 2 giây) 3. Đúng 1 phút 8 giây là thời gian thực hiện. Thời gian này khác nhau giữa các máy khách khác nhau. Từ máy phát triển của chúng tôi (nằm xa hơn nhiều so với máy sân khấu), tôi đã chạy truy vấn này 8 lần liên tiếp và thời gian dao động từ 11 giây đến 22 giây. (trung bình 18 giây)
FranticRock

từ hộp dev của chúng tôi tracert Prod_IP_Address 1 53 ms 52 ms 53 ms SQL2008 Từ máy giai đoạn, thời gian nhất quán hơn 1 phút. tracert Prod_IP_Address tracert: 1 1 ms <1 ms <1 ms SQL2008 Từ máy chủ web sản xuất: thời gian thực hiện là 53 giây. tracert: 1 1 ms <1 ms <1 ms SQL2008
FranticRock

4. Cột trên cùng "Thời gian thực hiện của máy khách" chỉ là giờ địa phương của máy (IE: 15:30:00) 5. Sự cố xảy ra trên bất kỳ máy nào đánh vào máy chủ DB sản xuất, kể cả trên máy chủ web sản xuất của chúng tôi. 6. Độ trễ ping là <1 MS từ hộp giai đoạn đến hộp prod SQL. 7. Xin vui lòng xem ở trên. 8. Thật không may, mạng cũ không còn tồn tại.
FranticRock

Điều thực sự thú vị là mặc dù DEV ping 53 MS, nhưng chỉ mất 11-22 giây để chạy truy vấn. Trong khi, giai đoạn ping 1 MS, phải mất hơn 1 phút để trả lại dữ liệu. Dev cũng là xa hơn về mặt địa lý. Và sân khấu ở ngay bên cạnh hộp prod, và còn mất nhiều thời gian hơn.
FranticRock
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.