Załaduj średnią dziwność na Linux Ubuntu

W ciągu ostatnich kilku dni starałem się zrozumieć dziwność, która dzieje się w naszej infrastrukturze, ale nie byłem w stanie jej zrozumieć, więc zwracam się do was z prośbą o wskazówki.

Zauważyłem w Graphite, że gwałtowne wzrosty w load_avg występują z śmiertelną regularnością mniej więcej co 2 godziny - nie są to dokładnie 2 godziny, ale są bardzo regularne. Załączam zrzut ekranu z grafitu

Utknąłem w badaniu tego - regularność tego doprowadziła mnie do myślenia, że jest to jakaś praca crona lub coś w tym rodzaju, ale na tych serwerach NIE ma żadnych cronjobs - w rzeczywistości są to maszyny wirtualne działające w chmurze Rackspace. To, czego szukam, jest pewnego rodzaju wskazówką, że może powodować te problemy i jak to zbadać dalej.

Serwery są dość bezczynne - jest to środowisko przejściowe, więc prawie nie ma ruchu przychodzącego / nie powinno być na nich żadnego obciążenia. To są wszystkie 4 wirtualne maszyny wirtualne z rdzeniem. Wiem na pewno, że bierzemy kilka próbek grafitu co około 10 sekund, ale jeśli to jest przyczyną obciążenia, to spodziewałbym się, że będzie stale wysoki, a nie co 2 godziny na falach na różnych serwerach.

Każda pomoc w zbadaniu tego problemu byłaby bardzo mile widziana!

Oto niektóre dane z sar dla app01 - który jest pierwszym niebieskim skokiem na powyższym obrazku - nie byłem w stanie wyciągnąć ŻADNYCH wniosków z danych. Nie oznacza to również, że bajty zapisują skok, który zdarza się co pół godziny (NIE CO 2 GODZINY), wynika z działania szefa-klienta co 30 minut. Spróbuję zebrać więcej danych, chociaż już to zrobiłem, ale nie mogłem wyciągnąć z nich żadnych wniosków.

ZAŁADUJ

09:55:01 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
10:05:01 PM         0       125      1.28      1.26      0.86         0
10:15:01 PM         0       125      0.71      1.08      0.98         0
10:25:01 PM         0       125      4.10      3.59      2.23         0
10:35:01 PM         0       125      0.43      0.94      1.46         3
10:45:01 PM         0       125      0.25      0.45      0.96         0
10:55:01 PM         0       125      0.15      0.27      0.63         0
11:05:01 PM         0       125      0.48      0.33      0.47         0
11:15:01 PM         0       125      0.07      0.28      0.40         0
11:25:01 PM         0       125      0.46      0.32      0.34         0
11:35:01 PM         2       130      0.38      0.47      0.42         0
11:45:01 PM         2       131      0.29      0.40      0.38         0
11:55:01 PM         2       131      0.47      0.53      0.46         0
11:59:01 PM         2       131      0.66      0.70      0.55         0
12:00:01 AM         2       131      0.81      0.74      0.57         0

procesor

09:55:01 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:05:01 PM     all      5.68      0.00      3.07      0.04      0.11     91.10
10:15:01 PM     all      5.01      0.00      1.70      0.01      0.07     93.21
10:25:01 PM     all      5.06      0.00      1.74      0.02      0.08     93.11
10:35:01 PM     all      5.74      0.00      2.95      0.06      0.13     91.12
10:45:01 PM     all      5.05      0.00      1.76      0.02      0.06     93.10
10:55:01 PM     all      5.02      0.00      1.73      0.02      0.09     93.13
11:05:01 PM     all      5.52      0.00      2.74      0.05      0.08     91.61
11:15:01 PM     all      4.98      0.00      1.76      0.01      0.08     93.17
11:25:01 PM     all      4.99      0.00      1.75      0.01      0.06     93.19
11:35:01 PM     all      5.45      0.00      2.70      0.04      0.05     91.76
11:45:01 PM     all      5.00      0.00      1.71      0.01      0.05     93.23
11:55:01 PM     all      5.02      0.00      1.72      0.01      0.06     93.19
11:59:01 PM     all      5.03      0.00      1.74      0.01      0.06     93.16
12:00:01 AM     all      4.91      0.00      1.68      0.01      0.08     93.33

09:55:01 PM       tps      rtps      wtps   bread/s   bwrtn/s
10:05:01 PM      8.88      0.15      8.72      1.21    422.38
10:15:01 PM      1.49      0.00      1.49      0.00     28.48
10:25:01 PM      1.54      0.00      1.54      0.03     29.61
10:35:01 PM      8.35      0.04      8.31      0.32    411.71
10:45:01 PM      1.58      0.00      1.58      0.00     30.04
10:55:01 PM      1.52      0.00      1.52      0.00     28.36
11:05:01 PM      8.32      0.01      8.31      0.08    410.30
11:15:01 PM      1.54      0.01      1.52      0.43     29.07
11:25:01 PM      1.47      0.00      1.47      0.00     28.39
11:35:01 PM      8.28      0.00      8.28      0.00    410.97
11:45:01 PM      1.49      0.00      1.49      0.00     28.35
11:55:01 PM      1.46      0.00      1.46      0.00     27.93
11:59:01 PM      1.35      0.00      1.35      0.00     26.83
12:00:01 AM      1.60      0.00      1.60      0.00     29.87

SIEĆ:

10:25:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
10:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:35:01 PM      eth1      7.07      4.77      5.24      2.42      0.00      0.00      0.00
10:35:01 PM      eth0      2.30      1.99      0.24      0.51      0.00      0.00      0.00
10:45:01 PM        lo      8.35      8.35      2.18      2.18      0.00      0.00      0.00
10:45:01 PM      eth1      3.69      3.45      0.65      2.22      0.00      0.00      0.00
10:45:01 PM      eth0      1.50      1.33      0.15      0.36      0.00      0.00      0.00
10:55:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
10:55:01 PM      eth1      3.66      3.40      0.64      2.19      0.00      0.00      0.00
10:55:01 PM      eth0      0.79      0.87      0.08      0.29      0.00      0.00      0.00
11:05:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:05:01 PM      eth1      7.29      4.73      5.25      2.41      0.00      0.00      0.00
11:05:01 PM      eth0      0.82      0.89      0.09      0.29      0.00      0.00      0.00
11:15:01 PM        lo      8.34      8.34      2.18      2.18      0.00      0.00      0.00
11:15:01 PM      eth1      3.67      3.30      0.64      2.19      0.00      0.00      0.00
11:15:01 PM      eth0      1.27      1.21      0.11      0.34      0.00      0.00      0.00
11:25:01 PM        lo      8.32      8.32      2.18      2.18      0.00      0.00      0.00
11:25:01 PM      eth1      3.43      3.35      0.63      2.20      0.00      0.00      0.00
11:25:01 PM      eth0      1.13      1.09      0.10      0.32      0.00      0.00      0.00
11:35:01 PM        lo      8.36      8.36      2.18      2.18      0.00      0.00      0.00
11:35:01 PM      eth1      7.16      4.68      5.25      2.40      0.00      0.00      0.00
11:35:01 PM      eth0      1.15      1.12      0.11      0.32      0.00      0.00      0.00
11:45:01 PM        lo      8.37      8.37      2.18      2.18      0.00      0.00      0.00
11:45:01 PM      eth1      3.71      3.51      0.65      2.20      0.00      0.00      0.00
11:45:01 PM      eth0      0.75      0.86      0.08      0.29      0.00      0.00      0.00
11:55:01 PM        lo      8.30      8.30      2.18      2.18      0.00      0.00      0.00
11:55:01 PM      eth1      3.65      3.37      0.64      2.20      0.00      0.00      0.00
11:55:01 PM      eth0      0.74      0.84      0.08      0.28      0.00      0.00      0.00

Dla osób ciekawych cronjobs. Oto podsumowanie wszystkich cronjobs skonfigurowanych na serwerze (wybrałem app01, ale dzieje się tak również na kilku innych serwerach z tym samym ustawionym cronjobs)

$ ls -ltr /etc/cron*
-rw-r--r-- 1 root root  722 Apr  2  2012 /etc/crontab

/etc/cron.monthly:
total 0

/etc/cron.hourly:
total 0

/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 730 Dec 31  2011 apt-xapian-index
-rwxr-xr-x 1 root root 907 Mar 31  2012 man-db

/etc/cron.daily:
total 68
-rwxr-xr-x 1 root root  2417 Jul  1  2011 popularity-contest
-rwxr-xr-x 1 root root   606 Aug 17  2011 mlocate
-rwxr-xr-x 1 root root   372 Oct  4  2011 logrotate
-rwxr-xr-x 1 root root   469 Dec 16  2011 sysstat
-rwxr-xr-x 1 root root   314 Mar 30  2012 aptitude
-rwxr-xr-x 1 root root   502 Mar 31  2012 bsdmainutils
-rwxr-xr-x 1 root root  1365 Mar 31  2012 man-db
-rwxr-xr-x 1 root root  2947 Apr  2  2012 standard
-rwxr-xr-x 1 root root   249 Apr  9  2012 passwd
-rwxr-xr-x 1 root root   219 Apr 10  2012 apport
-rwxr-xr-x 1 root root   256 Apr 12  2012 dpkg
-rwxr-xr-x 1 root root   214 Apr 20  2012 update-notifier-common
-rwxr-xr-x 1 root root 15399 Apr 20  2012 apt
-rwxr-xr-x 1 root root  1154 Jun  5  2012 ntp

/etc/cron.d:
total 4
-rw-r--r-- 1 root root 395 Jan  6 18:27 sysstat
$ sudo ls -ltr /var/spool/cron/crontabs 
total 0
$

Jak widać, nie ma żadnych GODZIN Cronjobs. Tylko codziennie / co tydzień itp.

Zebrałem mnóstwo statystyk (vmstat, mpstat, iostat) - choć bardzo się staram, po prostu nie widzę żadnych leadów, które mogłyby sugerować, że jakikolwiek komponent VM źle się zachowuje ... Zaczynam skłaniać się w kierunku potencjalnych problemów w hypervisor. Rzuć okiem na statystyki . Gist rozpoczyna się od wyjścia sar -q wokół „obrażającego” czasu, a następnie widać vm, mp i iostats ....

Zasadniczo jest to dla mnie całkowita tajemnica ...

— milosgajdos
źródło

Czy masz jakieś interaktywne dane, które możesz udostępnić w celu dalszego zbadania (tj., Co wyświetla „góra”, „htop” i „iotop” podczas powtarzających się skoków obciążenia)? Ponadto, czy sprawdziłeś dzienniki aplikacji w danych czasach, aby zobaczyć, czy wykazują jakieś dziwne zachowanie? Ponadto, czy masz jakieś hosty o podobnych konfiguracjach, które nie są hostowane w infrastrukturze chmury publicznej, a jeśli tak, to czy wykazują podobne zachowanie?

— esquireofoz

Jeśli chodzi o dzienniki aplikacji - nic się nie dzieje. Jedyne wpisy w dzienniku, które zawiera, to kontrole z monitorowania, które odbywają się co minutę - w zasadzie system monitorowania trafia na główną stronę i zgłasza kod wyniku - poza tym dzienniki są całkowicie puste. Jak widać, powyżej znajduje się wiele hostów - dzieje się to na wszystkich (redis, serwer aplikacji, serwer szefa kuchni itp.)

— milosgajdos

Czy próbowałeś użyć psacct, aby go zawęzić?

— HTTP500

zakładasz prawidłowość, ale wyświetlane dane nie pokazują żadnych regularnych skoków. Proszę bardziej szczegółowo określić dokładny okres, w którym wykazuje regularność (być może przez kilka dni? na zdjęciu, nie ma regularności). uruchamiaj „top -n 1” co około 1 milion i przechowuj je w pliku, a to może pomóc zobaczyć, jakie inne procesy konkurują o procesor w tym samym czasie, gdy wystąpi skok. Jeśli App1 to aplikacja internetowa, może po prostu ktoś uzyskuje do niej dostęp i wymusza takie zachowanie? dodaj też regularne logowanie „netstat -an” (co minutę?)

— Olivier Dulac

Czy widziałeś załączony zrzut ekranu? Jeśli to nie pokazuje regularitu, nie wiem co. Teraz zwiększyłem okres próbkowania sar, więc próbuję co 5 minut. Regularność na zdjęciu jest bardziej niż oczywista - dzieje się co dwie godziny. Jest to środowisko przejściowe, w którym NIE ma żadnego ruchu - jak z pewnością widać z powyższych wyników sar dla statystyk sieciowych.

— milosgajdos

Ciekawy.

Po pierwsze, czy możesz zwiększyć częstotliwość rejestrowania sar. Zamiast 10 minut staraj się logować co minutę. Cronjob sysstat można konfigurować.

Następnie spróbuj wykonać skrypt dla następujących poleceń.

ps auxf > /tmp/ps.out
vmstat 1 50 > /tmp/vm.out
mpstat -P ALL 1 50 > /tmp/mp.out
iostat -xdk 1 50 > /tmp/io.out
cat /proc/meminfo > /tmp/meminfo.out

Zbierz ten zestaw danych albo przy każdej iteracji, gdy średnia obciążenie wzrośnie ręcznie lub przez cron. Dobrze byłoby mieć dane z co najmniej jednego pełnego dnia roboczego.

Teraz rozumiem, że serwery są bezczynne, ale niektóre aplikacje muszą być uruchomione. Czym oni są?

Czy to możliwe, że możesz uruchomić jakieś narzędzie profilujące, takie jak perf lub oprofile.

Czy jakikolwiek komponent sprzętowy serwera jest zmieniany? Nawet coś tak nieszkodliwego jak aktualizacja oprogramowania lub aktualizacja oprogramowania.

Hej, jedno pytanie. Jakiego harmonogramu używasz. Wierzę, że to jest cfq, każda szansa, że możesz zmienić to na noop. Wprowadź elevator=noopparametr wiersza polecenia jądra i uruchom ponownie system i sprawdź, czy to poprawi.

— Soham Chakraborty
źródło

Dodałem małą edycję dotyczącą harmonogramu. zobacz wynik.

— Soham Chakraborty,

Zaloguj najlepsze procesy

Ponieważ wystąpienie jest bardzo regularne, ustaw zadanie cron w celu monitorowania najlepszych procesów w tym okresie

#app01
20-59 0/2 * * * root /usr/bin/top -b -n 1 | /usr/bin/head -n 15 >> /var/log/top.log

Zmiana 20-59na *rejestruje całą godzinę dla każdej parzystej liczby godzin. W obu przypadkach zadanie Cron będzie uruchamiane raz na minutę.

Możesz dodać plik top.log do rotacji dziennika, aby nie zajmował całego miejsca na wypadek, gdybyś zapomniał go wyłączyć.

Sprawdź plik dziennika

Wyszukaj wpisy pliku dziennika przy dużym obciążeniu

Weź przykładowy wpis obciążenia

10:25:01 PM         0       125      4.10      3.59      2.23         0

Zrobić

grep ' 22:2' /var/log/*
grep ' 22:2' /var/log/apache2/*

To pokaże wszystkie wpisy dziennika dla 22:2x:xx. Może zawierać inne katalogi dziennika.

Niedz. 6 stycznia 21:00:07 2013: xvda w_await spike

Wykres xvda - skok w_await jest w niedz. 6 stycznia 21:00:07 2013 wprowadź opis zdjęcia tutaj

— John Siu
źródło

Jedną rzecz, którą zdecydowanie sprawdziłbym:

wykresy vSphere dla tego samego wzorca, być może inna maszyna wirtualna na tym samym hoście zjada procesory (w ten sposób zwiększa się obciążenie maszyny wirtualnej, ponieważ przetwarzanie takiej samej ilości danych przy stałym przepływie zajmuje więcej czasu z powodu krótszego czasu procesora dostępnego dla twoja maszyna wirtualna).

Edycja: nie dostałem go za pierwszym razem :) Działasz na Rackspace, więc nie masz kontroli nad hiperwizorem, ale może warto zapytać rackspace, czy mogą sprawdzić, czy ten wzorzec jest powszechny na innych maszynach wirtualnych na tym samym hoście .

— Martino Dino
źródło

Jestem tego podejrzliwy - nie byłby to pierwszy raz, gdy chmura Rackspace wywołałaby jakieś szaleństwo. Wątpię jednak, aby monitorowali którykolwiek ze swoich serwerów hypervisora - mam na myśli niewłaściwie działające maszyny wirtualne, jednak chciałbym wykluczyć wszelkie „wewnętrzne” możliwości, zanim przejdę do ostateczności - obsługi Rackspace.

— milosgajdos

Czy wydajność hiperwizora wpłynie na oczywistą średnią obciążenie maszyny wirtualnej? To prowadzi mnie do zastanowienia się nad sposobem obliczania średniej obciążenia. Czy może to być jakiś efekt zielonej / energooszczędnej funkcji okresowo przenoszącej pracę na mniejszą liczbę rdzeni bez wiedzy o systemie operacyjnym? A może dynamicznie zmieniająca się częstotliwość taktowania na podstawie np. Czynników środowiskowych?

— trp

Przeciętne obciążenie jest obliczane przez algorytm planowania, innymi słowy, jeśli masz 100 zadań w kolejce przetwarzania, a hiperwizor jest w 100% wydajny w wykonywaniu 10 zadań na 1 sekundę, to potrzebujesz 10 sekund na wykonanie 100 zadań, jeśli twój hiperwizor jest wydajny tylko w 50% (być może nadmierna wydajność procesora), wykonanie tej samej liczby zadań zajmie 20 sekund, co prowadzi do zwiększenia obciążenia. Pełne wyjaśnienie: blog.scoutapp.com/articles/2009/07/31/…

— Martino Dino