Widzimy ogromne problemy z wydajnością aplikacji internetowej i staramy się znaleźć wąskie gardło. Nie jestem administratorem, więc jest kilka rzeczy, których nie do końca rozumiem. Niektóre podstawowe badania pokazują, że procesor jest bezczynny, dużo pamięci jest dostępne, brak zamiany, brak operacji we / wy, ale wysokie średnie obciążenie.
Stos oprogramowania na tym serwerze wygląda następująco:
- Solaris 10
- Java 1.6
- WebLogic 10.3.5 (8 domen)
Aplikacje działające na tym serwerze rozmawiają z bazą danych Oracle na innym serwerze.
Ten serwer ma 32 GB pamięci RAM i 10 procesorów (tak myślę).
Bieganie prstat -Z
daje coś takiego:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3836 ducm0101 2119M 2074M cpu348 58 0 8:41:56 0.5% java/225
24196 ducm0101 1974M 1910M sleep 59 0 4:04:33 0.4% java/209
6765 ducm0102 1580M 1513M cpu330 1 0 1:21:48 0.1% java/291
16922 ducm0102 2115M 1961M sleep 58 0 6:37:08 0.0% java/193
18048 root 3048K 2440K sleep 59 0 0:06:02 0.0% sa_comm/4
26619 ducm0101 2588M 2368M sleep 59 0 8:21:17 0.0% java/231
19904 ducm0104 1713M 1390M sleep 59 0 1:15:29 0.0% java/151
27809 ducm0102 1547M 1426M sleep 59 0 0:38:19 0.0% java/186
2409 root 15M 11M sleep 59 0 0:00:00 0.0% pkgserv/3
27204 root 58M 54M sleep 59 0 9:11:38 0.0% stat_daemon/1
27256 root 12M 8312K sleep 59 0 7:16:40 0.0% kux_vmstat/1
29367 root 297M 286M sleep 59 0 11:02:13 0.0% dsmc/2
22128 root 13M 6768K sleep 59 0 0:10:51 0.0% sendmail/1
22133 smmsp 13M 1144K sleep 59 0 0:01:22 0.0% sendmail/1
22003 root 5896K 240K sleep 59 0 0:00:01 0.0% automountd/2
22074 root 4776K 1992K sleep 59 0 0:00:19 0.0% sshd/1
22005 root 6184K 2728K sleep 59 0 0:00:31 0.0% automountd/2
27201 root 6248K 344K sleep 59 0 0:00:01 0.0% mount_stat/1
20964 root 2912K 160K sleep 59 0 0:00:01 0.0% ttymon/1
20947 root 1784K 864K sleep 59 0 0:02:22 0.0% utmpd/1
20900 root 3048K 608K sleep 59 0 0:00:03 0.0% ttymon/1
20979 root 77M 18M sleep 59 0 0:14:13 0.0% inetd/4
20849 daemon 2856K 864K sleep 59 0 0:00:03 0.0% lockd/2
17794 root 80M 1232K sleep 59 0 0:06:19 0.0% svc.startd/12
17645 root 3080K 728K sleep 59 0 0:00:12 0.0% init/1
17849 root 13M 6800K sleep 59 0 0:13:04 0.0% svc.configd/15
20213 root 84M 81M sleep 59 0 0:47:17 0.0% nscd/46
20871 root 2568K 600K sleep 59 0 0:00:04 0.0% sac/1
3683 ducm0101 1904K 1640K sleep 56 0 0:00:00 0.0% startWebLogic.s/1
23937 ducm0101 1904K 1640K sleep 59 0 0:00:00 0.0% startWebLogic.s/1
20766 daemon 5328K 1536K sleep 59 0 0:00:36 0.0% nfsmapid/3
20141 daemon 5968K 3520K sleep 59 0 0:01:14 0.0% kcfd/4
20093 ducm0101 2000K 376K sleep 59 0 0:00:01 0.0% pfksh/1
20797 daemon 3256K 240K sleep 59 0 0:00:01 0.0% statd/1
6181 root 4864K 2872K sleep 59 0 0:01:34 0.0% syslogd/17
7220 ducm0104 1268M 1101M sleep 59 0 0:36:35 0.0% java/138
27597 ducm0102 1904K 1640K sleep 59 0 0:00:00 0.0% startWebLogic.s/1
27867 root 37M 4568K sleep 59 0 0:13:56 0.0% kcawd/7
12685 ducm0101 4080K 208K sleep 59 0 0:00:01 0.0% vncconfig/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
42 135 22G 19G 59% 87:27:59 1.2% dsuniucm01
Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11
Rozumiem, że procesor jest w większości bezczynny, ale średnia wartość obciążenia jest wysoka, co jest dla mnie dość dziwne. Pamięć nie wydaje się być problemem.
Bieganie vmstat 15
daje coś takiego:
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s4 sd in sy cs us sy id
0 0 0 32531400 105702272 317 1052 126 0 0 0 0 13 13 -0 8 9602 107680 10964 1 1 98
0 0 0 15053368 95930224 411 2323 0 0 0 0 0 0 0 0 0 23207 47679 29958 3 2 95
0 0 0 14498568 95801960 3072 3583 0 2 2 0 0 3 3 0 21 22648 66367 28587 4 4 92
0 0 0 14343008 95656752 3080 2857 0 0 0 0 0 3 3 0 18 22338 44374 29085 3 4 94
0 0 0 14646016 95485472 1726 3306 0 0 0 0 0 0 0 0 0 24702 47499 33034 3 3 94
Rozumiem, że procesor jest w większości bezczynny, żadne kolejki nie czekają w kolejce do wykonania, ma miejsce niewielka zamiana.
Bieganie iostat 15
daje to:
tty sd0 sd1 sd4 ssd0 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id
0 676 324 13 8 322 13 8 0 0 0 159 8 0 1 1 0 98
1 1385 0 0 0 0 0 0 0 0 0 0 0 0 3 4 0 94
0 584 89 6 24 89 6 25 0 0 0 332 19 0 2 1 0 97
0 296 0 0 0 0 0 0 0 0 0 0 0 0 2 2 0 97
1 1290 43 5 24 43 5 22 0 0 0 297 20 1 3 3 0 94
Uruchamianie netstat -i 15
zapewnia:
input aggr26 output input (Total) output
packets errs packets errs colls packets errs packets errs colls
1500233798 0 1489316495 0 0 3608008314 0 3586173708 0 0
10646 0 10234 0 0 26206 0 25382 0 0
11227 0 10670 0 0 28562 0 27448 0 0
10353 0 9998 0 0 29117 0 28418 0 0
11443 0 12003 0 0 30385 0 31494 0 0
czego mi brakuje?
źródło
psrinfo -v
do wyświetlania rzeczywistej liczby procesorów./
i obciążenie ciągle rosło aż do końca19.00
bez widocznego powodu. Zwolnienie miejsca rozwiązało problem (krótko po tym, jak się zepsuł); może być jednak zbiegiem okoliczności.Odpowiedzi:
Po dalszych badaniach wydaje się, że problem z wydajnością wynika głównie z dużej liczby połączeń sieciowych między dwoma systemami (Oracle SSXA i UCM). Połączenia są szybkie, ale obfite i szeregowane, stąd niskie zużycie procesora (głównie oczekiwanie na operacje wejścia / wyjścia), wysokie średnie obciążenie (wiele połączeń czeka na przetworzenie), a zwłaszcza długie czasy odpowiedzi (poprzez akumulację małych czasów odpowiedzi).
Dziękujemy za wgląd w ten problem!
źródło
Kiedy mówisz „High Load Average”, zakładam, że masz na myśli, że prstat pokazuje dla „Average Load” na dole danych wyjściowych
Liczby te wyglądają podobnie do tych, które zapewnia top i prawdopodobnie oznaczają średni rozmiar kolejki uruchomionego procesu. To nie jest procent wykorzystanego czasu procesora, ale ile „rzeczy” nęka procesor przed upływem czasu. Wprawdzie wyglądają one dość wysoko, ale wszystko zależy od uruchomionej aplikacji; Procesy mogą właściwie nie działać zbytnio, gdy zdobędą swoje miejsce. Zobacz tutaj na miły wyjaśnieniem górze.
Nie znam WebLogic, ale zauważyłem, że generalnie w Apache Tomcat wiele wątków Java może być spawnowanych jednocześnie, co wydaje się być mało żądaniami. Może to być przyczyną wysokich średnich obciążeń. Upewnij się, że do łączenia się z zapleczem używasz puli połączeń i rozważ zwiększenie liczby bezczynnych wątków dostępnych dla Twojej aplikacji do obsługi połączeń (nie wiesz, jak to zrobić w WebLogic; Tomcat ma pulę wątków na złącze lub ogólna pula wątków modułu wykonującego). Jeśli tego nie zrobisz, mogą pojawiać się nowe wątki w celu przetworzenia żądań.
Jeśli chodzi o wydajność, musisz ustalić, jaka część aplikacji cierpi. Czy przetwarzanie odbywa się po stronie WebLogic / Java, dostęp do bazy danych, wyszukiwanie DNS (jeśli są wykonywane z jakiegoś powodu ...), problemy z siecią lub coś w systemie operacyjnym.
99% czasu to będzie twój kod i sposób, w jaki mówi do bazy danych, która wstrzymuje się. To będzie konfiguracja aplikacji internetowej. Po tym punkcie będziesz pracował nad wyciśnięciem ostatnich milisekund z aplikacji lub nad zapewnieniem większej współbieżności z tym samym sprzętem. Do dokładniejszego dostrajania wydajności potrzebne są miary.
W przypadku Javy sugeruję zainstalowanie Java Melody . Może dostarczyć wielu informacji na temat tego, co robi Twój program i pomóc zawęzić czas, w którym spędza czas. Użyłem go tylko z Tomcat, ale powinien działać dobrze z każdym kontenerem / serwletem Java EE.
Istnieje wiele sposobów na dostrojenie Java, więc spójrz na ich wytyczne dotyczące wydajności (jestem pewien, że zapewne masz) i upewnij się, że ustawiasz odpowiedni rozmiar sterty itp. Odpowiedni dla twojego programu. Java Melody może pomóc Ci wyśledzić rozmiar stosu Java, który zużywasz, a także jak ciężko pracuje moduł czyszczenia śmieci / jak często przeszkadza programowi w usuwaniu obiektów.
Mam nadzieję, że było to pomocne. Jeśli podasz więcej informacji, być może uda mi się zaktualizować tę odpowiedź i dopracować ją bardziej w zależności od potrzeb.
źródło
Na marginesie, średnia obciążeń obejmuje również rzeczy czekające na aktywność dysku (tj. Nękanie dysku), a także te czekające na procesor, jest to suma obu ... więc możesz mieć problemy w jednym lub drugim.
Zobacz http://en.wikipedia.org/wiki/Load_(computing) „Linux zawiera także [w swojej średniej obciążenia] procesy w nieprzerwanych stanach uśpienia (zwykle czekających na aktywność dysku)”
Na marginesie, szczególnym problemem, na który natknąłem się, było to, że miałem wysoką średnią obciążalność, ale także dużo bezczynności procesora i niskie zużycie dysku.
Wygląda na to, że przynajmniej w moim przypadku wątki / procesy oczekujące na operacje we / wy pojawiają się w średniej obciążenia, ale nie powodują wzrostu kolumny „Oczekiwanie”. Ale nadal są związane we / wy.
Możesz powiedzieć, że tak jest w przypadku następującego kodu, jeśli uruchomisz go w trybie bujnym (robi tylko 100 wątków z dużą ilością we / wy każdy):
Co daje najwyższą wydajność:
Widać więc, że ma dużo wolnych procesorów, 0,0% wa, ale bardzo wysoką średnią obciążenia.
iostat podobnie pokazuje dysk jako zasadniczo bezczynny:
patrz także http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html
Jako dodatkowa uwaga, wydaje się to również sugerować, że (przynajmniej w tym przypadku - z uruchomionym CentOS) średnia obciążenia obejmuje każdy wątek osobno w sumie.
źródło
Miałem dzisiaj ten sam problem. Po kilku badaniach i diagnozach zdałem sobie sprawę, że mój mały VPS zaczyna brakować dysku .
W powłoce / znaku zachęty (Linux / Unix)
aby zobaczyć dysk wolny na twoim komputerze. Jeśli brakuje Ci dysku, może to być problem / problem.
źródło
Innym przydatnym narzędziem, które pomoże w tej sytuacji, jest nmon.
Zawiera różne sposoby przeglądania tych samych danych prezentowanych przez inne narzędzia w jednym małym pakiecie.
Jeśli jest to treść, której nie można buforować, zaleciłbym umieszczenie wielu serwerów za modułem równoważenia obciążenia, takim jak haproxy, w trybie TCP do dystrybucji obciążenia.
źródło
Aby dodać do tego, niektóre narzędzia specyficzne dla systemu Solaris, które nie zostały wymienione, przydatne w debugowaniu takich problemów, to „intrstat”, „mpstat” i „lockstat”. Mpstat, który wcześniej doświadczył podobnego problemu na hoście z dużymi obciążeniami ETL, ujawnił dużą liczbę przerwań dotyczących dużej liczby operacji we / wy, które sugerowały ten problem.
W tym czasie na T4-4 z mpstat widzieliśmy, że vcpus przekazuje ponad 30000 przerwań w krótkim cyklu monitorowania, po czym wydajność zaczęła spadać. W tym przypadku jedynym obejściem było zwiększenie wydajności procesora, jednak później przeprowadzono prace nad poprawą kodu.
Brendan Gregg napisał wiele na temat wydajności, szczególnie na temat wejść / wyjść na przestrzeni lat i warto poszukać, jeśli chcesz dowiedzieć się więcej.
źródło