Lös ”Too Many Open files error” och ”native OutOfMemory på grund av att det inte gick att skapa tråd” – problem i WebSphere Application Server som körs på Linux

Body

image

vi får en hel del problem records (PMRs) / service requests(SRS) för infödda OutOfMemory frågor i WebSphere Application Server och en av de mest kända infödda OOM frågor händer särskilt på Linux OS på grund av otillräcklig ulimit-u (NPROC) värde.
vi får också ett stort antal PMR för ”för många öppna filer” fel för WebSphere Application Server som körs på Linux.
med enkel felsökning och ulimit-kommandotolkning kan du enkelt undvika att öppna en PMR med IBM-stöd för dessa problem.

1) Vad är ulimit i Linux?
ulimit-kommandot låter dig styra användarresursgränserna i systemet, t.ex. processdatastorlek, process virtuellt minne och processfilstorlek, antal processer etc.

2) Vad händer när inställningarna i det här kommandot inte är korrekt inställda?
olika problem händer som inbyggd OutOfMemory, för många öppna filer fel, dumpfiler genereras inte helt etc.

3) Hur kan du kontrollera aktuella ulimit-inställningar?
det finns olika sätt att kontrollera de aktuella inställningarna:

a) från kommandotolken, fråga
$ ulimit-a
vi kan se liknande utdata som nedan.
kärnfilstorlek (Block, -c) 0
data seg-storlek (kbytes,- d) obegränsad
schemaläggningsprioritet (- e) 0
filstorlek (Block,- f) obegränsad
väntande signaler (- i) 32767
max låst minne (kbytes,- l) 32
max minnesstorlek (kbytes,- m) obegränsad
öppna filer (- n) 1024
rörstorlek (512 byte,- p) 8
POSIX meddelandeköer (byte,-Q) 819200
realtidsprioritet (-r) 0
stackstorlek (KBytes, -s) 10240
CPU-tid (sekunder,- t) obegränsad
Max användarprocesser (- U) 50
virtuellt minne (KBytes,- v) obegränsat
fillås (- x) obegränsat
detta visas alla aktuella inställningar som är inställda för den aktuella inloggningssessionen och som standard mjuka gränser visas. Gränser kan mjuka och hårda.
hårda gränser är den maximala gränsen som kan konfigureras. Endast root-användaren kan öka hårda gränser, även om andra användare kan minska dem. Mjuka gränser kan ställas in och ändras av andra användare, men de kan inte överskrida de hårda gränserna.
om du vill hitta specifika gränsvärden fråga
ulimit-Sa
för nuvarande mjuk gränsvärde.
ulimit-Ha
för nuvarande hårda gränsvärde.

b)om du känner till Process-ID (PID) för WebSphere-applikationsservern som ska undersökas kan du också inspektera följande fil.
plats: /proc/<PID>
fil:gränser
innehållet i den här filen liknar utmatningen från kommandot ”ulimit-a”.
den här filen kommer att ha en lista över ulimit-parametrar och deras tillhörande värden för den angivna PID.
c) om du känner till process-ID för servern du vill kontrollera de aktuella ulimit-inställningarna kan du ta en Javacore genom att utfärda
kill -3 <PID>
du kan öppna denna Javacore i vilken textredigerare som helst (som NotePad++, Ultra Edit etc.)
och Sök efter ulimit och det tar dig ulimit-avsnittet.
exempel på ulimit-inställningar som det ses från en Javacore.
användargränser (i byte förutom NOFILE och NPROC)
————————————————————–
typ mjuk gräns hård gräns
RLIMIT_AS 11788779520 obegränsat
RLIMIT_CORE 1024 obegränsat
RLIMIT_CPU Obegränsat Obegränsat
RLIMIT_DATA Obegränsat Obegränsat
RLIMIT_FSIZE Obegränsat Obegränsat
RLIMIT_LOCKS Obegränsat Obegränsat
RLIMIT_MEMLOCK Obegränsat Obegränsat
rlimit_nofile 18192 18192
rlimit_nproc 79563 79563
rlimit_rss 8874856448 obegränsat
RLIMIT_STACK 33554432 obegränsat
om du vill hitta de globala inställningarna, inspektera nedanstående fil i linux.
/etc/säkerhet / gränser.conf.
alla ändringar av dessa globala konfigurationsgränser ska utföras av systemadministratören.
för att ta reda på mer information om varje inställning i ulimit-kommandot och även för att hitta om ulimit-kommandot på olika operativsystem, se denna technote: riktlinjer för inställning av ulimits (WebSphere Application Server)

4) Vilken typ av inbyggd OOM förväntas på grund av otillräckliga ulimit-inställningar?
en ut ur Minnesdumphändelse med en ”misslyckades med att skapa en tråd” kommer att hända.
exempel: Nedan visas meddelandet i Javacore.
”systhrow” (00040000) detalj ”java/lang/OutOfMemoryError”
”det gick inte att skapa en tråd: retVal -1073741830, errno 12” mottagna
errno 12 är en verklig native OOM på en start tråd.
ibland, misslyckades med att skapa en tråd ses också i serverloggar som SystemOut.logga, SystemErr.logga etc., och även i FFDC-loggar och detta fel indikerar att en inbyggd OutOfMemory hände under skapandet av ny tråd.

5) Vad är orsaken till att detta fel händer?
anledningen är att det nuvarande ulimit-u-värdet(NPROC) är för lågt och orsakar det.
nproc-gränsen räknar vanligtvis bara processer på en server för att bestämma detta nummer. Linux-system som kör WebSphere Application Server är ett särskilt fall. Nproc-gränsen på Linux räknar antalet trådar inom alla processer som kan existera för en viss användare. För de flesta fall av äldre versioner av Linux kommer detta värde att vara standard till omkring 2048. För Out of the box Red Hat Enterprise Linux (RHEL) 6 standardvärdet för nproc kommer att ställas in på 1024.
denna låga standardinställning för större system tillåter inte tillräckligt med trådar i alla processer.

6) Hur åtgärdar du problemet?
WebSphere Application Server Support rekommenderar att du ställer in ulimit-u eller nproc till ett värde av 131072 när du kör på Linux för att säkert redogöra för alla gafflade trådar i processer som kan skapas.
det kan ökas tillfälligt för den aktuella sessionen genom att ställa in
ulimit-u 131072
som anger värdet för mjuk gräns.
för att ställa in både mjuka och hårda gränser, fråga
ulimit-Su 131072 för mjuk gräns.
ulimit-Hu 131072 för hård gräns.
för att ställa in det globalt måste Linux-systemadministratören redigera
/etc/security/limits.conf
vi har denna technote som förklarar detta: otillräckligt ulimit-u (NPROC) – värde bidrar till inbyggt OutOfMemory

7) Vad sägs om ”för många öppna filer” – fel?
detta fel indikerar att alla tillgängliga filhandtag för processen har använts (detta inkluderar också uttag).
exempel: fel som liknar nedan kommer att ses serverloggar.
java.Io.IOException: för många öppna filer
prefs W kunde inte låsa Användarprefs. UNIX felkod 24.

8) varför detta fel händer?
det kan hända om det aktuella antalet öppna filer gränsen är för låg eller om detta är resultatet av fil handtag som läckt av någon del av programmet.

9) Hur fixar du det här?
IBM support rekommenderar antalet öppna filer inställning ulimit-n värde för WebSphere Application Server som körs på Linux som 65536 för både mjuka och hårda gränser.
ulimit-Sn 65536
ulimit-Hn 65536

10) Vad händer om det finns en filbeskrivningsläcka i applikationen?
på Linux kan vi hitta om några speciella öppna filer växer över en tidsperiod genom att ta underdata med lsof-kommando mot he problematiskt JVM-process-ID regelbundet.
lsof-p-r > lsof.ut
utgången ger dig alla öppna filer för den angivna PID. Du kommer att kunna avgöra vilka filer som öppnas och vilka filer som växer över tiden.
Alternativt kan du lista innehållet i filbeskrivarna som en lista med symboliska länkar i följande katalog, där du ersätter PID med
process-ID. Detta är särskilt användbart om du inte har tillgång till kommandot lsof:
ls-al /proc/PID/fd
relaterad technote: för många öppna filer felmeddelande

11) finns det något annat att ställa in?
vi har ytterligare en inställning som vi kan ställa in på Linux med pid_max vilket är sällsynt och förekommer endast stora miljöer. Om du inte använder en stor miljö kan du hoppa över det här steget.
pid_max-inställningen är för intern gräns för maximalt antal unika processidentifierare som ditt system stöder.
Standardvärdet är 32,768 och detta är tillräckligt för de flesta kunder.
på stora miljöer med stort antal processer finns det en möjlighet att denna gräns kan nås och
native OutOfMemory kommer att hända med liknande meddelande i
Javacore med misslyckades med att skapa tråd errno 11.
exempel:
dumpa Händelse ”systhrow” (00040000) detalj ”java/lang/OutOfMemoryError”
”det gick inte att skapa en tråd: retVal -106040066, errno 11” fick
för att hitta det aktuella pid_max-värdet på Linux.
cat /proc/sys/kernel/pid_max
för att öka den,utfärda
sysctl-w kernel.pid_max = < värde>
ibland kan Standard 32,768 nås på grund av vissa trådläckage/s, vilket orsakar native OOM. I det här fallet måste du fixa den här trådpoolläckan för att lösa native OOM.
relaterade technotes:
felsökning native minnesproblem
potentiell native minnesanvändning i WebSphere Application Server tråd pooler
sammanfattning:
se till att ha nedanstående ulimit inställningar på Linux för att undvika ”alltför många öppna filer fel” och ”native ur minnet” problem på grund av misslyckades med att skapa en tråd.
användargränser (i byte förutom NOFILE och NPROC)
soft_limit hard_limit
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072

12) finns det något annat att kontrollera?
IBM support rekommenderar nedanstående värden för alla ulimit-inställningar för WebSphere Application Server som körs på Linux, vilket inkluderar de inställningar vi diskuterade hittills.
användargränser (i byte förutom NOFILE och NPROC)
typ mjuk gräns hård gräns
RLIMIT_AS Obegränsat Obegränsat
RLIMIT_CORE Obegränsat Obegränsat
RLIMIT_CPU Obegränsat Obegränsat
RLIMIT_DATA Obegränsat Obegränsat
RLIMIT_FSIZE Obegränsat Obegränsat
RLIMIT_LOCKS Obegränsat Obegränsat
rlimit_memlock 65536 65536
rlimit_nofile 65536 65536
rlimit_nproc 131072 131072

13) Vad är nästa?
se till att ha ovanstående diskuterade inställningar på alla WebSphere Application Server JVM som DMGr, NodeAgent och AppServers och starta om JVM om inställningarna gjordes globalt eller logga ut och logga in igen med samma användare om ändringarna gjordes i den aktuella sessionen (shell).

Lämna ett svar

Din e-postadress kommer inte publiceras.