Body
otrzymujemy sporo rekordów problemów (PMRs) / żądań usług (SRS) dla natywnych problemów OutOfMemory w serwerze aplikacji WebSphere, a jeden z najbardziej znanych natywnych problemów OOM ma miejsce szczególnie w systemie operacyjnym Linux z powodu niewystarczającej wartości ulimit-u(NPROC).
otrzymujemy również dużą liczbę PMR dla błędu „zbyt wiele otwartych plików” dla serwera aplikacji WebSphere działającego pod Linuksem.
dzięki prostemu rozwiązywaniu problemów i strojeniu poleceń ulimit możesz łatwo uniknąć otwierania PMR z obsługą IBM dla tych problemów.
1) Co to jest ulimit w Linuksie?
polecenie ulimit pozwala kontrolować limity zasobów użytkownika w systemie, takie jak rozmiar danych procesu, pamięć wirtualna procesu i rozmiar pliku procesu, liczba procesów itp.
2) co się dzieje, gdy ustawienia w tym poleceniu nie są poprawnie skonfigurowane?
zdarzają się różne problemy, takie jak natywna pamięć wyjściowa, zbyt wiele błędów otwartych plików, pliki zrzutu nie są generowane całkowicie itp.
3) Jak sprawdzić aktualne ustawienia ulimit?
istnieją różne sposoby sprawdzania bieżących ustawień:
a) z wiersza polecenia, issue
$ ulimit-a
możemy zobaczyć podobne wyjście, jak poniżej.
Rozmiar pliku rdzenia (bloki, -c) 0
rozmiar segmentu danych (kbytes, -d) nieograniczony
priorytet planowania (-e) 0
Rozmiar pliku (bloki, -f) nieograniczony
sygnały oczekujące (-i) 32767
maksymalna zablokowana pamięć (kbytes, -l) 32
maksymalna wielkość pamięci (kbytes, -m) nieograniczony
otwarte pliki (-n) 1024
rozmiar potoku (512 bajtów, -P) 8
kolejki komunikatów POSIX (bajty, -Q) 819200
priorytet czasu rzeczywistego (- R) 0
rozmiar stosu (Kbytes,- s) 10240
czas procesora (sekundy,- t) nieograniczony
maks. Kbytes,- v) Unlimited
blokada plików (-x) unlimited
to wyświetli zostaną wyświetlone wszystkie bieżące ustawienia, które są ustawione dla bieżącej sesji logowania i domyślnie limity miękkie. Limity mogą być miękkie i twarde.
limity twarde są maksymalnym limitem, który można skonfigurować. Tylko użytkownik root może zwiększyć twarde limity, chociaż inni użytkownicy mogą je zmniejszyć. Limity miękkie mogą być ustawiane i zmieniane przez innych użytkowników, ale nie mogą przekraczać limitów twardych.
jeśli chcesz znaleźć konkretne wartości graniczne problem
ulimit-Sa
dla bieżącej miękkiej wartości granicznej.
ulimit-Ha
dla bieżącej twardej wartości granicznej.
b) jeśli znasz Identyfikator procesu (PID) serwera aplikacji WebSphere, który ma zostać zbadany, możesz również sprawdzić następujący plik.
Location: /proc/< PID>
File: limits
zawartość tego pliku jest podobna do wyniku polecenia” ulimit-a”.
ten plik będzie zawierał listę parametrów ulimit i powiązanych z nimi wartości dla podanego PID.
C)Jeśli znasz ID procesu serwera, który chcesz sprawdzić bieżące ustawienia ulimit, możesz pobrać Javacore wydając
kill -3 <PID>
możesz otworzyć ten Javacore w dowolnym edytorze tekstu (jak NotePad++, Ultra Edit itp.)
i wyszukaj ulimit, a zabierze cię sekcja ulimit.
przykład ustawień ulimit jak widać z Javacore.
limity użytkownika (w bajtach z wyjątkiem NOFILE i NPROC)
————————————————————–
Typ limit miękki limit twardy
RLIMIT_AS 11788779520 nieograniczony
RLIMIT_CORE 1024 nieograniczony
RLIMIT_CPU Nieograniczony Nieograniczony
RLIMIT_DATA Nieograniczony Nieograniczony
RLIMIT_FSIZE Nieograniczony Nieograniczony
RLIMIT_LOCKS Nieograniczony Nieograniczony
RLIMIT_MEMLOCK Nieograniczony Nieograniczony
RLIMIT_NOFILE 18192 18192
rlimit_nproc 79563 79563
rlimit_rss 8874856448 unlimited
RLIMIT_STACK 33554432 Unlimited
jeśli chcesz znaleźć ustawienia globalne, sprawdź poniższy plik w Linuksie.
/etc / security / limits.conf.
wszelkie zmiany w tych globalnych plikach limitów konfiguracji powinny być wykonywane przez administratora systemu.
aby dowiedzieć się więcej o każdym ustawieniu w Komendzie ulimit, a także dowiedzieć się o komendzie ulimit na różnych systemach operacyjnych, zobacz tę technote: Guidelines for setting ulimits (WebSphere Application Server)
4) jakiego rodzaju natywnego OOM jest oczekiwany z powodu niewystarczających ustawień ulimit?
nastąpi zdarzenie zrzutu pamięci z „nie udało się utworzyć wątku”.
przykład: Poniżej pojawi się komunikat w Javacore.
„systhrow” (00040000) Detail „java / Lang / OutOfMemoryError”
„nie udało się utworzyć wątku: retVal -1073741830, errno 12” received
errno 12 jest rzeczywistym natywnym OOM w wątku startowym.
czasami nieudane utworzenie wątku jest również widoczne w logach serwera, takich jak SystemOut.log, SystemErr.log itp., a także w logach FFDC i ten błąd wskazuje na natywną OutOfMemory podczas tworzenia nowego wątku.
5) Jaka jest przyczyna tego błędu?
powodem jest to, że aktualna wartość ulimit-u(nproc) jest zbyt niska, powodując to.
limit nproc zazwyczaj liczy tylko procesy na serwerze w celu określenia tej liczby. Szczególnym przypadkiem są systemy Linux z systemem WebSphere Application Server. Limit nproc w Linuksie zlicza liczbę wątków we wszystkich procesach, które mogą istnieć dla danego użytkownika. Dla większości starszych wersji Linuksa wartość ta będzie domyślnie ustawiona na około 2048 roku. Po wyjęciu z pudełka Red Hat Enterprise Linux (RHEL) 6 wartość domyślna dla nproc zostanie ustawiona na 1024.
to niskie ustawienie domyślne dla większych systemów nie pozwoli na wystarczającą liczbę wątków we wszystkich procesach.
6) Jak rozwiązać ten problem?
obsługa serwera aplikacji WebSphere zaleca ustawienie ulimit-u lub nproc na wartość 131072 podczas pracy pod Linuksem, aby bezpiecznie uwzględnić wszystkie rozwidlone wątki w procesach, które można utworzyć.
może być tymczasowo zwiększona dla bieżącej sesji Przez ustawienie
ulimit-u 131072
, które ustawia wartość miękkiego limitu.
aby ustawić limity miękkie i twarde, wydaj
ulimit-Su 131072 dla limitu miękkiego.
ulimit-Hu 131072 dla twardego limitu.
aby ustawić go globalnie, administrator systemu Linux musi edytować
/etc/security/limits.conf
mamy tę technote wyjaśniającą to: niewystarczająca wartość ulimit-u (NPROC) przyczynia się do natywnego OutOfMemory
7) co z błędem „zbyt wiele otwartych plików”?
ten błąd wskazuje, że wszystkie dostępne uchwyty plików dla procesu zostały użyte (dotyczy to również gniazd).
przykład: błędy podobne do poniższych będą widoczne logi serwera.
java.io.IOException: zbyt wiele otwartych plików
prefs w nie może zablokować prefs użytkownika. Kod błędu UNIX 24.
8) Dlaczego pojawia się ten błąd?
może się zdarzyć, jeśli aktualna liczba otwartych plików jest zbyt niska lub jest to wynikiem wycieku uchwytów plików przez jakąś część aplikacji.
9) Jak to naprawić?
wsparcie IBM zaleca ustawienie liczby otwartych plików jako wartości ulimit-n dla serwera aplikacji WebSphere działającego pod Linuksem jako 65536 dla limitów miękkich i twardych.
ulimit-Sn 65536
ulimit-Hn 65536
10) Co Zrobić, jeśli w aplikacji występuje wyciek deskryptora pliku?
w Linuksie możemy sprawdzić, czy jakieś konkretne otwarte pliki rosną przez jakiś czas, pobierając poniższe dane za pomocą polecenia lsof przeciwko problematycznemu ID procesu JVM na zasadzie okresowej.
lsof-p-r > lsof.out
wyjście dostarczy Ci wszystkich otwartych plików dla określonego PID. Będziesz mógł określić, które pliki są otwierane i które Pliki rosną w czasie.
Alternatywnie możesz wyświetlić zawartość deskryptorów plików jako listę dowiązań symbolicznych w poniższym katalogu, gdzie PODMIENIASZ PID na
ID procesu. Jest to szczególnie przydatne, jeśli nie masz dostępu do polecenia lsof:
LS-al /proc/PID/fd
powiązane technote: zbyt wiele otwartych plików komunikat o błędzie
11) czy jest coś jeszcze do dostrojenia?
mamy jeszcze jedno ustawienie, które możemy dostroić na Linuksie za pomocą pid_max, co jest rzadkością i występuje tylko w dużych środowiskach. Jeśli nie używasz dużego środowiska, możesz pominąć ten krok.
ustawienie pid_max służy do wewnętrznego limitu maksymalnej liczby unikalnych identyfikatorów procesów obsługiwanych przez system.
domyślną wartością jest 32,768 i jest to wystarczające dla większości klientów.
w dużych środowiskach z ogromną liczbą procesów istnieje możliwość osiągnięcia tego limitu i
natywne OutOfMemory będzie miało podobny komunikat w
Javacore z nieudanym utworzeniem wątku errno 11.
przykład:
Dump Event „systhrow” (00040000) Detail „java/Lang/OutOfMemoryError”
„nie udało się utworzyć wątku: retVal -106040066, errno 11” otrzymał
, aby znaleźć bieżącą wartość pid_max w Linuksie.
cat /proc / sys / kernel / pid_max
aby go zwiększyć, wydaj
jądro sysctl-W.pid_max = <wartość>
czasami można osiągnąć domyślną wartość 32,768 z powodu wycieku / s wątku, powodując natywny OOM. W takim przypadku musisz naprawić ten wyciek puli wątków, aby rozwiązać natywny OOM.
powiązane technologie:
Rozwiązywanie problemów z pamięcią natywną
potencjalne wykorzystanie pamięci natywnej w pulach wątków serwera aplikacji WebSphere
podsumowanie:
upewnij się, że poniższe ustawienia ulimit w systemie Linux zapobiegają „zbyt wielu błędom otwartych plików” i „natywnemu wyczerpaniu pamięci” z powodu nieudanego utworzenia wątku.
limity użytkownika (w bajtach z wyjątkiem NOFILE i NPROC)
soft_limit hard_limit
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072
12) czy jest coś jeszcze do sprawdzenia?
wsparcie IBM zaleca poniższe wartości dla wszystkich ustawień ulimit dla WebSphere Application Server działającego pod Linuksem, które zawierają omówione dotychczas ustawienia.
limity użytkownika (w bajtach z wyjątkiem NOFILE i NPROC)
Typ limit miękki limit twardy
RLIMIT_AS Nieograniczony Nieograniczony
RLIMIT_CORE Nieograniczony Nieograniczony
RLIMIT_CPU Nieograniczony Nieograniczony
RLIMIT_DATA Nieograniczony Nieograniczony
RLIMIT_FSIZE Nieograniczony Nieograniczony
RLIMIT_LOCKS Nieograniczony Nieograniczony
rlimit_memlock 65536 65536
RLIMIT_NOFILE 65536 65536
rlimit_nproc 131072 131072
13) co dalej?
upewnij się, że powyższe ustawienia zostały omówione na wszystkich serwerach JVM WebSphere Application Server, takich jak DMGr, Nodeagent i AppServers i uruchom ponownie JVMs, jeśli ustawienia zostały wykonane globalnie lub wyloguj się i zaloguj ponownie z tym samym użytkownikiem, jeśli zmiany zostały wykonane w bieżącej sesji (powłoka).