Mamy jedno wystąpienie SQL Server 2016 SP1 działające na maszynie wirtualnej VMware. Zawiera 4 bazy danych, każda dla innej aplikacji. Wszystkie te aplikacje znajdują się na osobnych serwerach wirtualnych. Żadne z nich nie jest jeszcze w użyciu produkcyjnym. Osoby testujące aplikacje zgłaszają jednak problemy z wydajnością.
Oto statystyki serwera:
- 128 GB pamięci RAM (maks. 110 GB pamięci dla programu SQL Server)
- 4 rdzenie @ 4,6 GHz
- Połączenie sieciowe 10 GBit
- Cała pamięć jest oparta na dyskach SSD
- Pliki programów, pliki dziennika, pliki bazy danych i tempdb znajdują się na osobnych partycjach serwera
- asd
Użytkownicy wykonują dostęp do pojedynczego ekranu za pośrednictwem aplikacji ERP opartej na C ++.
Kiedy przeprowadzam test warunków skrajnych SQL Servera z Microsoftem za ostresspomocą wielu małych zapytań lub dużych zapytań, uzyskuję maksymalną wydajność. Jedynym ograniczeniem jest klient, ponieważ nie może wystarczająco szybko odpowiedzieć.
Ale kiedy prawie nie ma użytkowników, SQL Server prawie nic nie robi. Jednak ludzie muszą czekać wiecznie, aby zapisać wszystko w aplikacji.
Według zapytania Paula Randala „ Powiedz mi, gdzie boli ” 50% wszystkich zdarzeń oczekiwania ASYNC_NETWORK_IO.
Może to oznaczać albo problem z siecią, albo problem z wydajnością serwera aplikacji lub klienta. Żadne z nich nie wykorzystuje nawet swoich zasobów przy maksymalnej wydajności. Przez większość czasu procesor wynosi około 26% na wszystkich komputerach (klient, serwer, serwer db).
Opóźnienie połączenia sieciowego wynosi około 1-3 ms. IO serwera db ma maksymalną prędkość zapisu 20 MB / s podczas normalnego użytkowania z aplikacją (średnio 7-9 MB / s). Kiedy przeprowadzam test warunków skrajnych, uzyskuję około 5 GB / s.
Rozmiar bufora pamięci podręcznej wynosi 60 GB dla bazy danych naszego systemu ERP, 20 GB dla naszego oprogramowania finansowego, 1 GB dla oprogramowania do kontroli jakości, 3 GB dla systemu archiwizacji dokumentów.
Dałem konto SQL Server prawo do natychmiastowej inicjalizacji plików . To w żaden sposób nie zwiększyło wydajności.
Oczekiwana długość życia strony wynosi około 15 000+ podczas normalnego użytkowania. W trakcie ciężkich testów wytrzymałościowych spada do około 0,05 tys., Czego należy się spodziewać. Liczba partii na sekundę wynosi około 2-8 tys., W zależności od obciążenia pracą.
Powiedziałbym, że aplikacja ERP jest po prostu źle napisana, ale nie mogę, ponieważ dotyczy to wszystkich aplikacji. Nawet przy minimalnym obciążeniu.
Jednak nie potrafię wskazać, co to powoduje. Czy są jakieś wskazówki, samouczki ze wskazówkami, aplikacje, dokumenty najlepszych / najgorszych praktyk lub cokolwiek innego, co macie na myśli w związku z tym problemem?
Są to wyniki z sp_BlitzFirst:
Uruchomiłem to 600 sekund. Zacząłem to podczas dużego obciążenia aplikacji. 1/3 tego czasu ASYNC_NETWORK_IO. Ja również przetestowane połączenie sieciowe z NTttcp, PsPing, ipferf3, i pathping. Nic niezwykłego. Czasy odpowiedzi wynoszą maksymalnie 3 ms, średnio 0,3 ms. Przepustowość wynosi około 1000 MB / s.
Moje dochodzenie zawsze ASYNC_NETWORK_IOkończy się na tym, że jestem numerem jeden.
Zbadaliśmy rezultat wyłączenia tej Large-Receive-Offloadfunkcji w VMware. Wciąż testujemy, ale wyniki wydają się niespójne. Nasz pierwszy „test porównawczy” trwał 19 minut (najwyższy wynik to 13 minut, który osiąga się tylko wtedy, gdy aplikacja działa na maszynie wirtualnej z samym serwerem SQL Server). Drugi wynik to 28 minut, co jest naprawdę złe.
Pierwszy wynik naszego „testu porównawczego” wynosił 19 minut. Który jest dobry. Ponieważ najwyższy wynik wynosił 13 minut (co można osiągnąć tylko wtedy, gdy aplikacja porównuje wyniki na maszynie wirtualnej z samym serwerem SQL Server). To mocno wskazuje na problem związany z siecią. Lub problem z konfiguracją VMware.
Obecnie jestem zagubiony w metodach, które należy zastosować, aby doprowadzić go do wąskiego gardła.
Maksymalną wydajność aplikacji można osiągnąć tylko wtedy, gdy aplikacja jest uruchomiona na maszynie wirtualnej z samym serwerem SQL Server. Jeśli aplikacja zostanie uruchomiona na innej maszynie wirtualnej lub wirtualnym pulpicie, czas trwania naszego testu porównawczego wzrośnie trzykrotnie (od 13 minut do 40 minut lub więcej). Wszystkie punkty końcowe (maszyna wirtualna programu SQL Server, maszyna wirtualna serwera aplikacji i pulpit wirtualny) korzystają z tego samego fizycznego sprzętu. Przenieśliśmy wszystkie inne punkty końcowe na inny sprzęt.
EDYCJA: Wydaje się, że problem powrócił. Po zmianie trybu oszczędzania energii ze zrównoważonej na wysoką wydajność, znacznie poprawiliśmy czasy reakcji. Ale dzisiaj ponownie uruchomiłem sp_BlitzFirst, z 300-sekundową próbką. Oto wynik:
Pokazuje więcej sekundy oczekiwania na ASYNC_NETWORK_IO niż sekundy sp_blitzfirst.
źródło