Dlaczego czas odpowiedzi eksploduje, gdy spada częstotliwość żądań?

22

Korekta : czas odpowiedzi ( %D) to μs nie ms! 1

Nie zmienia to nic w dziwności tego wzoru, ale oznacza, że jest on praktycznie o wiele mniej niszczycielski.

Dlaczego czas odpowiedzi jest odwrotnie skorelowany z częstotliwością żądania?

Czy serwer nie powinien reagować szybciej, gdy jest mniej zajęty obsługą żądań?

Wszelkie sugestie, jak sprawić, by Apache „wykorzystywał” mniej obciążenia?

Ten wzór jest okresowy. Oznacza to, że wyświetli się, jeśli liczba wyświetleń spadnie poniżej około 200 żądań na minutę - co dzieje się (z powodu naturalnej aktywności użytkowników) od późnej nocy do wczesnego rana.

Żądania są bardzo prostymi testami POST wysyłającymi JSON o długości mniejszej niż 1000 znaków - ten JSON jest przechowywany (dołączany do pliku tekstowego) - to wszystko. Odpowiedź brzmi „-”.

Dane pokazane na wykresach zostały zarejestrowane w samym Apache:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

apache-2.4 ubuntu-14.04 high-load

— Raffael
źródło

2

Czy jest możliwe, że coś powoduje presję pamięci podręcznej, w wyniku czego musi pobierać rzeczy z dysku? Jak wygląda aktywność dysku?

— TLW

2

Czy są to żądania przychodzące na minutę, czy żądania obsługiwane na minutę?

— user253751

Jakiego oprogramowania użyłeś do zarejestrowania i wykreślenia tych danych?

— Naprawdę

1

@wingleader: nagrany z Apache2 i nakreślony z R

— Raffaelem

@immibis: zobacz konfigurację dziennika, którą dodałem - myślę, że to „przybycie”

— Raffael

31

Jest to typowe zachowanie w centrach danych. Czas, w którym czas odpowiedzi jest wolny, odpowiada tak zwanemu Oknu wsadowemu. Jest to okres, w którym oczekuje się, że aktywność użytkownika będzie niska i można będzie uruchomić procesy wsadowe. W tym okresie wykonywane są również kopie zapasowe. Te działania mogą obciążać zasoby serwera i sieci, powodując problemy z wydajnością, takie jak widoczne.

Istnieje kilka zasobów, które mogą powodować problemy:

Wysokie obciążenie procesora. Może to spowodować, że Apache będzie czekać na wycinek czasu w celu przetworzenia żądania.
Wysokie wykorzystanie pamięci. Może to opróżnić bufory, które umożliwiają apache do obsługi zasobów bez odczytywania ich z dysku. Może również powodować stronicowanie / zamianę pracowników Apache.
Wysoka aktywność dysku. Może to spowodować, że aktywność we / wy dysku zostanie umieszczona w kolejce z odpowiednim opóźnieniem w udostępnianiu treści.
Wysoka aktywność sieci. Może to spowodować umieszczenie pakietów w kolejce do transmisji, zwiększenie liczby ponownych prób i pogorszenie jakości usługi.

Używam sardo badania takich wydań. atsarmożna wykorzystać do gromadzenia sardanych w codziennych plikach danych. Można je zbadać, aby zobaczyć, jak zachowuje się system w ciągu dnia, gdy wydajność jest normalna, i bez zmian, gdy wydajność jest zmienna.

Jeśli monitorujesz system za pomocą muninlub innego systemu, który gromadzi i wykresuje wykorzystanie zasobów, możesz tam znaleźć pewne wskaźniki. Nadal uważam za sarbardziej precyzyjne.

Istnieją narzędzia, jak nicei ionicektóre mogą być stosowane w procesach wsadowych w celu zminimalizowania ich wpływu. Działają tylko w przypadku problemów z procesorem lub I / O. Jest mało prawdopodobne, aby rozwiązały problemy z pamięcią lub aktywnością sieci.

Przeniesienie kopii zapasowej do oddzielnej sieci i zmniejszenie rywalizacji sieci. Niektóre programy do tworzenia kopii zapasowych można skonfigurować w celu ograniczenia przepustowości, która będzie używana. To może rozwiązać konflikt sieci.

W zależności od tego, w jaki sposób uruchamiane są procesy wsadowe, można ograniczyć liczbę równoległych procesów wsadowych. Może to faktycznie poprawić wydajność procesów wsadowych, ponieważ prawdopodobnie doświadczają one tej samej rywalizacji o zasoby.

— BillThor
źródło

1

Link do sarmoże być przydatny. Znalazłem ten: en.wikipedia.org/wiki/Sar_(Unix)

— Roger Lipscombe

mogą to być nie tylko kopie zapasowe, dostawcy maszyn wirtualnych mogą przenosić więcej maszyn wirtualnych na te same maszyny w czasie przestojów i wyłączać kilka stojaków w celu oszczędzania energii (lub rzeczywiście, przeznaczają je na zadania wsadowe)

— Jens Timmerman

8

Relacja ta może się zdarzyć w przeciwnym kierunku, jeśli nadawcy żądania zaczekają na wypełnienie poprzedniego żądania przed przesłaniem nowego. W takim przypadku ruch spada wraz ze wzrostem czasu żądania (z dowolnego powodu) z powodu kolejkowania po stronie klienta.

Lub może to być artefakt pomiaru - jeśli powyższy wykres pokazuje ukończone żądania , w przeciwieństwie do żądań przychodzących , szybkość spada wraz ze wzrostem czasu przetwarzania żądań (przy założeniu skończonej pojemności: D).

— Karol Nowak
źródło

Oczywiście to tylko zarysowanie możliwych przyczyn, ale oświadczenie o problemie otwierającym nie daje wiele do zobaczenia. Czy ten proces mówi coś jeszcze? Jakie rodzaje wniosków to obsługuje? Czy obciążenie zmienia się z czasem? I tak dalej ....

— Karol Nowak

ciekawa perspektywa, ale nie idzie dobrze z okresowością i czasem trwania objawów

— Raffael

7

Chociaż odpowiedź @ BillThor może być poprawna, wydaje się mało prawdopodobne, aby okres niskiego obciążenia został całkowicie zajęty przez procesy tworzenia kopii zapasowych (tj. Czy okresy są dokładnie dopasowane).

Alternatywnym wyjaśnieniem jest po prostu buforowanie. Jeśli dany skrypt / baza danych / cokolwiek nie było ostatnio używane, odpowiednie buforowane dane mogły zostać usunięte, aby zwolnić pamięć dla reszty systemu operacyjnego. Mogą to być indeksy bazy danych, bufory O / S w stosunku do pliku lub cokolwiek innego. Zapytanie będzie wówczas musiało odtworzyć tę informację, jeśli minęło trochę czasu od ostatniego zapytania. W okresach zajętości nie będzie to miało miejsca, ponieważ ostatnie zapytanie będzie częste. To by również wyjaśniało, dlaczego widzisz niskie czasy reakcji i wysokie czasy odpowiedzi w okresie zajętości.

— w płomieniach
źródło

Zwłaszcza jeśli chodzi o buforowanie zapytań i / lub buforowanie dostępu do dysku. Na marginesie, jeśli istnieje jakakolwiek strategia „ponownego użycia wątku”, która również pomaga.

— mckenzm

Nie wymaga to żadnego czytania.

— Raffael

1

@Raffael Wątpię, czy możesz zagwarantować, że nie ma w tym żadnego czytania. Na poziomie trywialnym załóżmy, że strony Apache są stronicowane, ponieważ coś innego chciało pamięci RAM? Załóżmy, że twój MPM dla Apache zmniejszył liczbę wątków / procesów, podczas gdy rzeczy są bezczynne i powstaje narzut związany z tworzeniem nowych? Mówisz poważnie, że jeśli uruchomisz straceproces Apache, nie zobaczysz żadnych read()wywołań systemowych lub podobnych? To byłoby dość niezwykłe.

— dniu

@abligh: cóż, poprawne, moja „usługa” nie implementuje jawnie niczego z odczytu z dysku

— Raffael

@Raffael, jeśli chcesz przetestować efekt buforowania systemu operacyjnego (tylko), to w okresie zajętości rób echo 3 > /proc/sys/vm/drop_cachesco 5 sekund przez minutę i sprawdź, czy masz podobny wpływ na czas odpowiedzi.

— abligh 21.07.16

2

To, co tam widzisz, wydaje mi się, że może to być problem statystyczny. Może nie być, odpowiedź @ BillThora może być słuszna, ale opublikuję to dla kompletności.

Wykresy czasu odpowiedzi są oparte na percentylach. Przykładowa pula 800-1000 żądań to dobra liczba próbek do tego celu, pula 50-100 żądań może nie tak bardzo.

Jeśli założymy, że liczba wolnych żądań nie jest liniową funkcją objętości żądań, tak że wzrost rzędu żądań nie powoduje wzrostu rzędu żądań wolniejszych, wówczas większe wolumeny zgłoszeń niższy średni czas zapytania.

— Kaithar
źródło

1

jeśli obserwacja składała się tylko z 50 do 100 żądań, to rzeczywiście może to być po prostu losowość, ale jeśli spojrzysz na wykres, zobaczysz, że mówimy o 60 x 5 eksperymentach, z których każde obejmuje około 50 do 100 żądań - to zdecydowanie wystarcza, aby wyklucz losowość. Jeśli przyjrzysz się uważnie, zobaczysz stabilny średni 50. percentyl pojawiający się przy około 2500 ms.

— Raffael

Niekoniecznie, nie tak dokładnie zachowują się te statystyki. Na przykład 1000 żądań w ciągu 1 godziny i 1000 żądań w ciągu 1 minuty nie będzie zachowywać się tak samo. Prawdopodobnie też tu się nie dzieje. Małe rozmiary próbek zachowują się dziwnie, w tym przypadku bardziej przypominają zestawy próbek 60 x 5. Wzór może być wynikiem obciążenia nieliniowego.

— Kaithar,

0

Są kłamstwa, wielkie kłamstwa i statystyki.

Moja hipoteza: masz trzy różne kategorie wniosków:

Normalny strumień zmienny, który zawiera większość żądań i wszystkie one są realizowane w ciągu 200–300 μs.
Mały strumień o stałej szybkości około 20 żądań na minutę (nawet w nocy). Każda z nich zajmuje około 2500 μs.
Mały strumień o stałej szybkości około 10 żądań na minutę (nawet w nocy). Każda trwa znacznie powyżej 4.000 μs.

W nocy 50 żądań na minutę to odpowiednio 20 + 20 + 10. I tak, wynik 50% percentyla silnie zależy teraz od wyniku strumienia 2. A 95% percentyla zależy od strumienia 3, więc nigdy nie będzie nawet widoczny na wykresie.

W ciągu dnia strumienie 2 + 3 są dobrze ukryte powyżej 95% percentyla.

— kubańczyk
źródło

Co masz na myśli przez stream? Żądania są absolutnie jednorodne, podczas gdy klienci żądający są absolutnie heterogeniczni.

— Raffael

0

Im dłużej na to patrzę, tym bardziej skłonny jestem myśleć, że istnieje problem z gromadzeniem danych.

Po pierwsze, z Twoim TPS dzieje się coś naprawdę dziwnego. Podczas gdy ogólny wzór wygląda normalnie, występuje bardzo ostra przerwa o około 21 wieczorem, a następnie o około 7 rano. Normalny wykres będzie znacznie płynniejszy podczas przejścia do godzin poza szczytem.

Sugeruje to zmianę profilu i możliwe, że masz 2 różne typy klientów:

Taki, który działa tylko między 7 rano (ish) a 9pm (ish), przy dużych głośnościach i
inny, który prawdopodobnie działa przez całą dobę, przy niższych poziomach głośności.

Druga wskazówka to około 18:00. Przez większość czasu przed i po mamy profil wysokiego poziomu głośności - wysokie TPS i małe opóźnienia. Ale około 18:00 następuje nagły spadek z 800-1000 RPM do mniej niż 400 RPM. Co może to spowodować?

Trzecią wskazówką jest obniżenie czasów reakcji w piątym percentylu. Właściwie wolę patrzeć na minimalne czasy odpowiedzi (ale 5. percentyl jest prawdopodobnie lepszy) z dwóch powodów: Mówi mi o czasie usługi (tj. Czas odpowiedzi minus kolejkowanie), a czasy odpowiedzi mają tendencję do podążania za rozkładem Weibulla, co oznacza, że tryb (lub najczęstszą wartością) jest nieco powyżej minimum.

Tak więc obniżenie piątego percentyla mówi mi, że nastąpiła nagła przerwa w serii, a czas obsługi faktycznie skrócił się, mimo że zarówno wariancja, jak i średni czas reakcji znacznie wzrosły.

Następne kroki

Na tym etapie zagłębiałbym się w dzienniki, aby dowiedzieć się, co różni się w próbkach o małej objętości 18:00 w porównaniu do próbek o dużej objętości przed i po nim.

Szukałbym:

różnice w lokalizacji geograficznej (w przypadku, gdy opóźnienie wpływa na $ request_time)
różnice w adresie URL (nie powinny być żadne)
różnice w metodzie HTTP (POST / GET) (nie powinny być żadne)
powtarzające się żądania z tego samego adresu IP
i wszelkie inne różnice ...

BTW, „zdarzenie” o 18:00 jest dla mnie wystarczającym dowodem na to, że nie ma to nic wspólnego z przeciążeniem / aktywnością centrum danych. Aby to było prawdą, przeciążenie musiałoby spowodować spadek TPS, co jest możliwe o godzinie 18:00, ale jest bardzo mało prawdopodobne, aby powodowało trwały i płynnie zakrzywiony spadek TPS przez 10 godzin między 21:00 a 7:00.

— Nathan Webb
źródło