Chúng tôi có một phiên bản SQL Server 2016 SP1 duy nhất đang chạy trong máy ảo VMware. Nó chứa 4 cơ sở dữ liệu, mỗi cơ sở cho một ứng dụng khác nhau. Những ứng dụng này đều nằm trên các máy chủ ảo riêng biệt. Không ai trong số họ đang sử dụng sản xuất. Những người kiểm tra các ứng dụng đang báo cáo các vấn đề hiệu suất, mặc dù.
Đây là số liệu thống kê của máy chủ:
- RAM 128 GB (Bộ nhớ tối đa 110 GB cho Máy chủ SQL)
- 4 lõi @ 4,6 GHz
- Kết nối mạng 10 GB
- Tất cả các lưu trữ là dựa trên SSD
- Tệp chương trình, tệp nhật ký, tệp cơ sở dữ liệu và tempdb nằm trên các phân vùng riêng biệt của máy chủ
- asd
Người dùng đang thực hiện truy cập màn hình đơn thông qua ứng dụng ERP dựa trên C ++.
Khi tôi nhấn mạnh kiểm tra Máy chủ SQL với Microsoft ostressbằng nhiều truy vấn nhỏ hoặc truy vấn lớn, tôi sẽ có hiệu suất tối đa. Điều duy nhất điều tiết là khách hàng, bởi vì anh ta không thể trả lời đủ nhanh.
Nhưng khi hầu như không có bất kỳ người dùng nào, SQL Server hầu như không làm gì cả. Tuy nhiên, mọi người phải chờ đợi mãi mãi để lưu bất cứ thứ gì trong ứng dụng.
Theo truy vấn " Hãy cho tôi biết nơi nào đau " của Paul Randal , 50% của tất cả các sự kiện chờ đợi là ASYNC_NETWORK_IO.
Điều này có thể có nghĩa là sự cố mạng hoặc sự cố hiệu suất với máy chủ ứng dụng hoặc máy khách. Không ai trong số họ thậm chí từ xa sử dụng tài nguyên của họ ở công suất tối đa. Hầu hết thời gian CPU là khoảng 26% trên tất cả các máy (Máy khách, máy chủ ứng dụng, máy chủ db).
Độ trễ của kết nối mạng là khoảng 1-3ms. IO của máy chủ db đạt tốc độ ghi tối đa 20MB / s trong quá trình sử dụng bình thường với ứng dụng (avg là 7-9MB / s). Khi tôi căng thẳng kiểm tra, tôi nhận được khoảng 5GB / s.
Kích thước bộ đệm của bộ đệm là 60 GB cho DB của hệ thống ERP của chúng tôi, 20 GB cho phần mềm tài chính của chúng tôi, 1 GB cho phần mềm đảm bảo chất lượng, 3 GB cho hệ thống lưu trữ tài liệu.
Tôi đã cho tài khoản SQL Server quyền sử dụng Khởi tạo tệp tức thì . Điều đó đã không tăng hiệu suất trong một chút.
Tuổi thọ của trang là khoảng 15k + trong khi sử dụng bình thường. Giảm xuống khoảng 0,05k trong khi kết thúc thử nghiệm căng thẳng nặng, dự kiến. Mẻ / giây là khoảng 2-8k, tùy thuộc vào khối lượng công việc.
Tôi muốn nói rằng ứng dụng ERP chỉ được viết kém, nhưng tôi không thể vì tất cả các ứng dụng đều bị ảnh hưởng. Ngay cả ở khối lượng công việc tối thiểu.
Tuy nhiên, tôi không thể xác định chính xác những gì gây ra điều này. Có bất kỳ lời khuyên, hướng dẫn gợi ý, ứng dụng, tài liệu thực hành tốt nhất / tồi tệ nhất hoặc bất cứ điều gì khác mà các bạn có trong tâm trí về vấn đề này?
Đây là kết quả từ sp_BlitzFirst:
Tôi đã chạy nó 600 giây. Tôi đã khởi động nó trong một khối lượng công việc lớn của ứng dụng. 1/3 thời gian đó ASYNC_NETWORK_IO. Tôi cũng đã thử nghiệm kết nối mạng với NTttcp, PsPing, ipferf3, và pathping. Không có gì bất thường. Thời gian đáp ứng tối đa là 3ms, trung bình 0,3ms. Thông lượng là khoảng 1000 MB / s.
Cuộc điều tra của tôi luôn dẫn đến kết quả ASYNC_NETWORK_IOlà người chờ đợi số một.
Chúng tôi đã điều tra kết quả của việc vô hiệu hóa Large-Receive-Offloadtính năng này trong VMware. Chúng tôi vẫn đang thử nghiệm, nhưng kết quả có vẻ không nhất quán. Kết quả 'điểm chuẩn' đầu tiên của chúng tôi có thời lượng 19 phút (kết quả cao nhất là 13 phút chỉ đạt được khi ứng dụng đang chạy trên máy ảo với chính SQL Server). Kết quả thứ hai là 28 phút, điều này thực sự tồi tệ.
Kết quả đầu tiên của "điểm chuẩn" của chúng tôi là 19 phút. Cái nào tốt. Bởi vì kết quả hàng đầu là 13 phút (chỉ có thể đạt được khi ứng dụng điểm chuẩn trên VM với chính SQL Server). Điều này gợi ý mạnh mẽ về một số vấn đề liên quan đến mạng. Hoặc một vấn đề với cấu hình VMware.
Tôi hiện đang bị mất phương pháp sử dụng, để đóng nó vào nút cổ chai.
Hiệu suất tối đa với ứng dụng chỉ có thể đạt được khi ứng dụng đang chạy trên VM với chính SQL Server. Nếu ứng dụng được thực thi trên bất kỳ máy ảo hoặc máy tính để bàn ảo nào khác, thời lượng điểm chuẩn của chúng tôi sẽ tăng gấp ba lần (từ thời lượng 13 phút đến 40 phút trở lên). Tất cả các điểm cuối (VM của SQL Server, VM của máy chủ ứng dụng và Virtual Desktop) đều sử dụng cùng một phần cứng vật lý. Chúng tôi đã chuyển tất cả các điểm cuối khác sang phần cứng khác.
EDIT: Có vẻ như vấn đề đã trở lại. Sau khi thiết lập chế độ tiết kiệm năng lượng từ cân bằng đến hiệu suất cao, chúng tôi thực sự đã cải thiện thời gian phản hồi một cách kịch tính. Nhưng hôm nay tôi đã chạy lại sp_BlitzFirst, với mẫu 300 giây. Đây là kết quả:
Nó cho thấy thời gian chờ của ASYNC_NETWORK_IO nhiều hơn so với giây mà sp_blitzfirst đã chạy.