Løse” for mange åbne filer fejl “og” native OutOfMemory på grund af kunne ikke oprette tråd ” problemer i applikationsserveren, der kører på

krop

image

vi modtager en hel del problemoptegnelser (pmrs) / serviceanmodninger (SRS) for native OutOfMemory-problemer i applikationsserveren, og et af de mest berømte native oom-problemer sker især på OS på grund af utilstrækkelig ulimit-u(NPROC) værdi.
vi modtager også et stort antal PMR ‘ er for “for mange åbne filer” – fejl for applikationsserver, der kører på .
med enkel fejlfinding og ulimit-kommandotuning kan du nemt undgå at åbne en PMR med IBM-support til disse problemer.

1) Hvad er ulimit?
ulimit-kommandoen giver dig mulighed for at kontrollere brugerressourcegrænserne i systemet, såsom procesdatastørrelse, proces virtuel hukommelse og procesfilstørrelse, antal processer osv.

2) Hvad sker der, når indstillingerne i denne kommando ikke er konfigureret korrekt?
forskellige problemer sker som native OutOfMemory, for mange åbne filer fejl, dump filer genereres ikke helt osv.

3) Hvordan kan du kontrollere aktuelle ulimit-indstillinger?
der er forskellige måder at kontrollere de aktuelle indstillinger på:

A) fra kommandoprompten, issue
$ ulimit-a
vi kan se lignende output som nedenfor.
kernefilstørrelse (blokke, -c) 0
data seg-størrelse (kbytes,- d) ubegrænset
planlægningsprioritet (- e) 0
Filstørrelse (blokke,- f) ubegrænset
afventende signaler (- i) 32767
maks låst hukommelse (kbytes,- l) 32
maks hukommelsesstørrelse (kbytes,- m) ubegrænset
Åbn filer (- n) 1024
rørstørrelse (512 bytes,- P) 8
positionskøer (bytes,-k) 819200
realtidsprioritet (-r) 0
stackstørrelse (Kbytes, -s) 10240
CPU-tid (sekunder,- t) ubegrænset
maks. brugerprocesser (- U) 50
virtuel hukommelse (Kbytes,- v) ubegrænset
fillåse (- h) ubegrænset
dette vil vise alle aktuelle indstillinger, der er indstillet til den aktuelle login-session og som standard bløde grænser, vises. Grænser kan bløde og hårde.
hårde grænser er den maksimale grænse, der kan konfigureres. Kun rodbrugeren kan øge hårde grænser, selvom andre brugere kan reducere dem. Bløde grænser kan indstilles og ændres af andre brugere, men de kan ikke overskride de hårde grænser.
hvis du ønsker at finde specifikke grænseværdier problem
ulimit-Sa
for aktuelle bløde grænseværdi.
ulimit-Ha
for nuværende hårde grænseværdi.

b) hvis du kender proces-ID (PID) på applikationsserveren, der skal undersøges, kan du også inspicere følgende fil.
placering: /proc/<PID>
fil:grænser
indholdet af denne fil svarer til udgangen af kommandoen “ulimit-a”.
denne fil vil have en liste over ulimit parametre og deres tilknyttede værdier for den angivne PID.
c)hvis du kender proces-ID ‘ et for den server, du vil kontrollere de aktuelle ulimit-indstillinger, kan du tage en Javacore ved at udstede
kill -3 <PID>
du kan åbne denne Javacore i enhver teksteditor (som NotePad++, Ultra Edit osv.)
og søg efter ulimit, og det vil tage dig ulimit sektionen.
eksempel på ulimit-indstillinger, som det ses fra en Javacore.
Brugerbegrænsninger (i bytes undtagen NOFILE og NPROC)
————————————————————–
type blød grænse hård grænse
RLIMIT_AS 11788779520 ubegrænset
RLIMIT_CORE 1024 ubegrænset
RLIMIT_CPU ubegrænset ubegrænset
RLIMIT_DATA ubegrænset ubegrænset
RLIMIT_FSTØRRELSE ubegrænset ubegrænset
RLIMIT_LOCKS ubegrænset ubegrænset
RLIMIT_MEMLOCK ubegrænset ubegrænset
rlimit_nofile 18192 18192
rlimit_nproc 79563 79563
rlimit_rss 8874856448 ubegrænset
RLIMIT_STACK 33554432 ubegrænset
hvis du vil finde de globale indstillinger, Undersøg nedenstående fil.
/etc/sikkerhed/grænser.conf.
eventuelle ændringer af disse globale konfigurationsgrænsefiler skal udføres af systemadministratoren.
for at finde ud af flere detaljer om hver indstilling i ulimit-kommandoen og også for at finde om ulimit-kommandoen på forskellige operativsystemer, se denne technote: retningslinjer for indstilling af ulimits (Ulimit Application Server)

4) Hvilken slags native OOM forventes på grund af utilstrækkelige ulimit-indstillinger?
en ud af hukommelse Dump begivenhed med en “kunne ikke oprette en tråd” vil ske.
eksempel: Nedenstående meddelelse vises i Javacore.
“Systrom” (00040000) Detalje “java/lang/OutOfMemoryError”
“kunne ikke oprette en tråd: retVal -1073741830, errno 12” modtaget
errno 12 er en faktisk indfødt OOM på en starttråd.
nogle gange kan man ikke oprette en tråd også ses i serverlogfiler som SystemOut.log, SystemErr.log osv., og også i FFDC-logfiler, og denne fejl indikerer en indfødt OutOfMemory skete under oprettelsen af ny tråd.

5) Hvad er årsagen til denne fejl?
årsagen er, at den nuværende ulimit-u(NPROC) værdi er for lav, hvilket forårsager den.
nproc-grænsen tæller normalt kun processer på en server til bestemmelse af dette nummer. Det er et særligt tilfælde, at der er tale om systemer, der kører applikationsserver. Nproc-grænsen tæller antallet af tråde inden for alle processer, der kan eksistere for en given bruger. I de fleste tilfælde af ældre versioner vil denne værdi blive standardiseret til omkring 2048. For ud af boksen Red Hat Enterprise Linuks (RHEL) 6 standardværdien for nproc vil blive indstillet til 1024.
denne lave standardindstilling for større systemer tillader ikke nok tråde i alle processer.

6) Sådan løser du dette problem?
Application Server Support anbefaler at indstille ulimit-U eller nproc til en værdi på 131072, når du kører på for sikkert at tage højde for alle de forked tråde i processer, der kunne oprettes.
det kan øges midlertidigt for den aktuelle session ved at indstille
ulimit-u 131072
som indstiller værdien for blød grænse.
hvis du vil indstille både bløde og hårde grænser, skal du udstede
ulimit-Su 131072 for blød grænse.
ulimit-Hu 131072 til hård grænse.
for at indstille det globalt skal systemadministratoren redigere
/etc/security/limits.conf
vi har denne technote, der forklarer dette: utilstrækkelig Ulimit-U (NPROC) værdi bidrager til Native OutOfMemory

7) Hvad med “for mange åbne filer” fejl?
denne fejl angiver, at alle tilgængelige filhåndtag til processen er blevet brugt (dette inkluderer også stikkontakter).
eksempel: fejl svarende til Nedenfor ses serverlogfiler.
java.io.Ioundtagelse: for mange åbne filer
prefs kunne ikke låse bruger prefs. Fejlkode 24.

8) hvorfor denne fejl sker?
det kan ske, hvis det aktuelle antal åbne filer grænse er for lav, eller hvis dette er resultatet af fil håndtag lækket af en del af programmet.

9) Sådan løses dette?
IBM-support anbefaler antallet af åbne filer, der indstiller ulimit-n-værdi for applikationsserver, der kører på 65536 for både bløde og hårde grænser.
ulimit-sn 65536
ulimit-HN 65536

10) Hvad hvis der er en filbeskrivelseslækage i applikationen?
vi kan finde ud af, om nogen bestemte åbne filer vokser over en periode ved at tage nedenstående data med lsof-kommando mod HE problematisk JVM-proces-ID med jævne mellemrum.
lsof-p-r > lsof.out
udgangen vil give dig alle de åbne filer for den angivne PID. Du vil være i stand til at bestemme, hvilke filer der åbnes, og hvilke filer der vokser over tid.
Alternativt kan du liste indholdet af filbeskrivelserne som en liste over symbolske links i følgende mappe, hvor du erstatter PID med
proces-ID ‘ et. Dette er især nyttigt, hvis du ikke har adgang til kommandoen lsof:
ls-al/proc/PID / fd
relateret technote: for mange åbne filer fejlmeddelelse

11) er der noget andet, der skal indstilles?
vi har endnu en indstilling, vi kan indstille på Linuks ved hjælp af pid_maks, som er sjælden og forekommer kun store miljøer. Hvis du ikke bruger et stort miljø, kan du springe dette trin over.
indstillingen pid_maks er for intern grænse for maksimalt antal unikke proces-id ‘ er, som dit system understøtter.
standardværdien er 32.768, og det er tilstrækkeligt for de fleste kunder.
på store miljøer med stort antal processer er der en mulighed for, at denne grænse kan nås, og
native OutOfMemory vil ske med lignende besked i
Javacore med kunne ikke oprette tråd errno 11.
eksempel:
Dump begivenhed “Systrom” (00040000) Detalje “java/lang/OutOfMemoryError”
“kunne ikke oprette en tråd: retVal -106040066, errno 11” modtaget
for at finde den aktuelle pid_maks-værdi på Linuk.
cat /proc/sys/kernel/pid_maks
for at øge det,udstede
sysctl-med kerne.Pid_maks=<værdi >
nogle gange kan standard 32,768 nås på grund af nogle trådlækage/s, hvilket forårsager native OOM. I dette tilfælde skal du rette denne trådpuljelækage for at løse native oom.
relaterede technotes:
fejlfinding native memory issues
potentiel native memory brug i applikationsserver thread pools
Resume:
sørg for at have nedenstående ulimit-indstillinger for at undgå “for mange åbne filer fejl” og “native ud af hukommelsen” problemer på grund af manglende oprettelse af en tråd.
Brugerbegrænsninger (i bytes undtagen NOFILE og NPROC)
soft_limit hard_limit
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072

12) er der andet at tjekke?
IBM-support anbefaler nedenstående værdier for alle ulimit-indstillinger for applikationsserver, der kører på , som inkluderer de indstillinger, vi har diskuteret indtil videre.
Brugergrænser (i bytes undtagen NOFILE og NPROC)
type blød grænse hård grænse
rlimit_as ubegrænset ubegrænset
rlimit_core ubegrænset ubegrænset
rlimit_cpu ubegrænset ubegrænset
rlimit_data ubegrænset ubegrænset
RLIMIT_FSTØRRELSE ubegrænset ubegrænset
RLIMIT_LOCKS ubegrænset ubegrænset
rlimit_memlock 65536 65536
rlimit_nofile 65536 65536
rlimit_nproc 131072 131072

13) Hvad er det næste?
sørg for at have de ovenfor diskuterede indstillinger på alle JVM ‘er som DMGr, NodeAgent og AppServers, og genstart JVM’ erne, hvis indstillingerne blev udført globalt, eller log af og log ind igen med samme bruger, hvis ændringerne blev udført i den aktuelle session (shell).

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.