Za mało pamięci
Jest to bardzo prawdopodobne, że jest to problem z pamięcią, być może pogarszany lub wywoływany przez inne rzeczy, ale nadal jest to z natury problem z pamięcią. istnieją dwie inne (mniej prawdopodobne) możliwości, które należy najpierw sprawdzić i wyeliminować (ponieważ jest to łatwe):
Łatwe do sprawdzenia możliwości:
-
Możesz mieć włączone „Automatyczne zamykanie”:Automatyczne zamykanie może mieć dokładnie takie zachowanie, jednak rzadko jest ono włączone. Aby to sprawdzić, w programie SSMS kliknij prawym przyciskiem myszy bazę danych aplikacji, wybierz „Właściwości”, a następnie wybierz okienko „Opcje”. Spójrz na wpis "Auto Close" i upewnij się, że jest ustawiony na False. Sprawdź także tempdb.
-
Przyczyną tego mogą być zadania programu SQL Agent:Sprawdź dziennik historii agenta, aby sprawdzić, czy podczas zdarzeń stale działały jakieś zadania. Pamiętaj, aby sprawdzić również zadania konserwacji, ponieważ takie rzeczy jak indeksy odbudowywania są często wymieniane jako problemy z wydajnością podczas ich działania. Obecnie są to mało prawdopodobni kandydaci, tylko dlatego, że w normalnych warunkach Profiler na nich nie ma wpływu.
Dlaczego wygląda to na problem z pamięcią:
Jeśli te nic nie pokazują, powinieneś sprawdzić problemy z pamięcią. Podejrzewam, że przyczyną w twoim przypadku jest pamięć, ponieważ:
-
Masz 1 GB pamięci:chociaż jest to technicznie powyżej minimum dla SQL Server, jest znacznie poniżej zalecanego dla SQL Server i znacznie poniżej tego, co według mojego doświadczenia jest dopuszczalne w produkcji, nawet dla lekko obciążonego serwera.
-
Korzystasz z usług IIS i programu SQL Server na tym samym komputerze:nie jest to zalecane samo przez się, w dużej mierze ze względu na wynik rywalizacji o pamięć, ale przy tylko 1 GB pamięci skutkuje to powstaniem usług IIS, aplikacji, programu SQL Server, System operacyjny i inne zadania i/lub konserwacja walczą o bardzo mało pamięci. Sposób, w jaki system Windows zarządza tym, polega na przekazywaniu pamięci aktywnym procesom poprzez agresywne odbieranie jej od nieaktywnych procesów. Może minąć wiele sekund, a nawet minut, zanim duży proces, taki jak SQL Server, odzyska wystarczającą ilość pamięci, aby móc w tej sytuacji całkowicie obsłużyć żądanie.
-
Profiler sprawił, że 90% problemu zniknęło:jest to duża wskazówka, że prawdopodobnie problemem jest pamięć, ponieważ zazwyczaj rzeczy takie jak Profiler mają dokładnie taki wpływ na ten konkretny problem:zadanie Profilera utrzymuje SQL Server tylko trochę trochę aktywny przez cały czas. Często jest to wystarczająca aktywność, aby albo utrzymać ją z listy „zmiataczy” systemu operacyjnego, albo przynajmniej nieco zmniejszyć jej wpływ.
Jak sprawdzić pamięć jako winowajca:
-
Wyłącz profiler:ma wpływ Heisenberga na problem, więc musisz go wyłączyć lub nie będziesz w stanie wiarygodnie zobaczyć problemu.
-
Uruchom Monitor systemu (perfmon.exe) z innego komputera, który zdalnie łączy się z usługą zbierania wydajności na komputerze, na którym działa Twój SQL Server i IIS. najłatwiej to zrobić, usuwając najpierw trzy domyślne statystyki (są one tylko lokalne), a następnie dodaj potrzebne statystyki (poniżej), ale pamiętaj o zmianie nazwy komputera w pierwszym menu rozwijanym, aby połączyć się z twoim SQL pudełko.
-
Prześlij zebrane dane do pliku, tworząc „Dziennik liczników” w perfmon. Jeśli nie jesteś zaznajomiony z tym tematem, najłatwiejszą rzeczą do zrobienia jest prawdopodobnie zebranie danych do pliku oddzielonego tabulatorami lub przecinkami, który można otworzyć w programie Excel w celu analizy.
-
Skonfiguruj perfmon do zbierania danych do pliku i dodaj do niego następujące liczniki:
-- Procesor\%Czas procesora[Całkowity]
-- Dysk fizyczny\% czasu bezczynności[dla każdego dysku ]
-- Dysk fizyczny\Śr. Długość kolejki dysku[dla każdego dysku ]
-- Pamięć\Strony/s
-- Pamięć\Odczyty stron/s
-- Pamięć\Dostępne MB
-- Interfejs sieciowy\Bajty łącznie/s[dla każdego używanego interfejsu ]
-- Proces\% czasu procesora[patrz poniżej ]
-- Proces\Błędy stron/s[patrz poniżej ]
-- Proces\Zestaw roboczy [patrz poniżej ]
-
W przypadku liczników procesów (powyżej) chcesz uwzględnić proces sqlserver.exe, wszelkie procesy IIS i wszelkie stabilne procesy aplikacji. Zauważ, że będzie to działać TYLKO dla „stabilnych” procesów. Procesy, które są stale odtwarzane w razie potrzeby, nie mogą zostać przechwycone w ten sposób, ponieważ nie ma możliwości określenia ich, zanim zaistnieją.
-
Uruchom tę kolekcję do pliku w czasie, w którym najczęściej występuje problem. Ustaw interwał zbierania danych na około 10-15 sekund. (zbiera to dużo danych, ale będziesz potrzebować tej rozdzielczości, aby wybrać oddzielne zdarzenia).
-
Po wystąpieniu co najmniej jednego incydentu zatrzymaj zbieranie, a następnie otwórz plik zebranych danych w programie Excel. Prawdopodobnie będziesz musiał ponownie sformatować kolumnę sygnatury czasowej, aby była użyteczna i pokazywała godziny, minuty i sekundy. Użyj swojego dziennika IIS, aby znaleźć dokładny czas incydentów, a następnie przejrzyj dane perfmon, aby zobaczyć, co działo się przed i po incydencie. W szczególności chcesz sprawdzić, czy jego zestaw roboczy był mały przed i był duży po, z dużą ilością błędów między stronami. To najwyraźniejszy znak tego problemu.
ROZWIĄZANIA:
Albo rozdziel IIS i SQL Server na dwa różne pudełka (preferowane) albo dodaj więcej pamięci do pudełka. Myślę, że 3-4 GB powinno być minimum.
A co z tymi dziwnymi rzeczami EF?
Problem polega na tym, że najprawdopodobniej jest to albo peryferyjne, albo tylko przyczyniające się do twojego głównego problemu. Pamiętaj, że Profiler sprawił, że 90% Twoich incydentów zniknęło, więc to, co pozostaje, może być innym problemem lub może być tylko najbardziej ekstremalnym pogarszaczem problemu. Ze względu na jego zachowanie domyślam się, że albo cykliczne działanie pamięci podręcznej, albo istnieje inna konserwacja w tle procesów serwera aplikacji.
