test
kapunk jó néhány probléma records ( PMRs) / service requests (SRs) natív OutOfMemory kérdések WebSphere Application Server és az egyik leghíresebb natív OOM problémák történik, különösen a Linux operációs rendszer miatt elégtelen ulimit-u(NPROC) értéket.
jó számú PMR-t is kapunk a “túl sok nyitott fájl” hiba miatt a Linuxon futó WebSphere Application Server számára.
egyszerű hibaelhárítással és ulimit parancshangolással könnyen elkerülheti a PMR megnyitását az IBM Támogatással ezekre a problémákra.
1) Mi az ulimit Linuxban?
az ulimit parancs lehetővé teszi a rendszer felhasználói erőforrásainak korlátozását, például A folyamatadatok méretét, a virtuális memória feldolgozását, a folyamat fájlméretét, a folyamat számát stb.
2) Mi történik, ha a parancs beállításai nincsenek megfelelően beállítva?
különböző problémák történnek, mint a natív OutOfMemory, túl sok nyitott fájl hiba, a dump fájlok nem generálódnak teljesen stb.
3) Hogyan ellenőrizheti az aktuális ulimit beállításokat?
az aktuális beállítások ellenőrzésének különféle módjai vannak:
a) a parancssorból kiadja a
$ ulimit-a
hasonló kimenetet láthatunk, mint az alábbiakban.
mag fájlméret (blokkok, -c) 0
adat seg méret (KByte, -d) korlátlan
ütemezési prioritás (-e) 0
fájlméret (blokkok, -f) korlátlan
függőben lévő jelek (-i) 32767
maximális zárolt memória (KByte, -l) 32
maximális memória méret (KByte, -m) korlátlan
fájlok megnyitása (KByte,- m)- n) 1024
csőméret (512 bájt, -P) 8
POSIX üzenetsorok (bájt,-Q) 819200
valós idejű prioritás (-r) 0
veremméret (KByte,- s) 10240
CPU idő (másodperc,- t) korlátlan
maximális felhasználói folyamatok (-U) 50
virtuális memória (- u) kbytes,- v) korlátlan
fájlzárak (- x) korlátlan
ez jelenik meg megjelenik az aktuális bejelentkezési munkamenethez beállított összes aktuális beállítás, valamint alapértelmezés szerint a soft limits. A határok lágyak és kemények lehetnek.
a kemény határértékek a beállítható maximális határértékek. Csak a root felhasználó növelheti a kemény korlátokat, bár más felhasználók csökkenthetik azokat. A lágy korlátokat más felhasználók is beállíthatják és megváltoztathatják, de nem léphetik túl a kemény korlátokat.
ha meg szeretné találni konkrét határértékek kérdés
ulimit-Sa
az aktuális lágy határérték.
ulimit-Ha
az aktuális kemény határérték esetében.
b) ha ismeri a vizsgálandó WebSphere alkalmazáskiszolgáló Folyamatazonosítóját (PID), akkor a következő fájlt is megvizsgálhatja.
Location: / proc / <PID>
File:limits
a fájl tartalma hasonló az “ulimit-a” parancs kimenetéhez.
ez a fájl tartalmazza az ulimit paraméterek listáját és a hozzájuk tartozó értékeket a megadott PID-hez.
c) ha ismeri annak a szervernek a folyamatazonosítóját, amelynek ellenőrizni szeretné az aktuális ulimit beállításokat, akkor Javacore-t készíthet a kiadással
kill -3 <PID>
ezt a Javacore-t bármilyen szövegszerkesztőben megnyithatja (például NotePad++, Ultra Edit stb.)
és keresse meg az ulimit-et, és elviszi az ulimit részt.
példa az ulimit beállításokra, amint az egy Javacore-ból látható.
felhasználói korlátok (byte-ban, kivéve a NOFILE és az NPROC)
————————————————————–
típus soft limit hard limit
RLIMIT_AS 11788779520 korlátlan
RLIMIT_CORE 1024 korlátlan
RLIMIT_CPU korlátlan korlátlan
RLIMIT_DATA korlátlan korlátlan
RLIMIT_FSIZE korlátlan korlátlan
RLIMIT_LOCKS korlátlan korlátlan
RLIMIT_MEMLOCK korlátlan korlátlan
rlimit_nofile 18192 18192
rlimit_nproc 79563 79563
rlimit_rss 8874856448 korlátlan
RLIMIT_STACK 33554432 korlátlan
ha meg akarja találni a globális beállításokat, vizsgálja meg az alábbi fájlt linux alatt.
/etc/security / limits.conf.
a globális konfigurációs korlátozások fájljainak bármilyen módosítását a rendszergazdának kell elvégeznie.
ha többet szeretne megtudni az ulimit parancs egyes beállításairól, valamint az ulimit parancsról a különféle operációs rendszereken, olvassa el ezt a technote-ot: irányelvek az ulimits (WebSphere Application Server) beállításához
4) Milyen natív OOM várható az elégtelen ulimit beállítások miatt?
egy “nem sikerült létrehozni egy szálat” memória kiíratási esemény fog történni.
példa: Az alábbi üzenet jelenik meg a Javacore – ban.
” systhrow “(00040000) részlet”java/lang/OutOfMemoryError”
” nem sikerült létrehozni egy szálat: retVal -1073741830, errno 12 ” kapott
errno 12 egy tényleges natív OOM egy kezdő szálon.
néha, nem sikerült létrehozni egy szálat is látható szerver naplók, mint SystemOut.napló, SystemErr.napló stb., valamint az FFDC naplókban ez a hiba azt jelzi, hogy egy natív OutOfMemory történt az Új szál létrehozása során.
5) Mi az oka ennek a hibának?
ennek oka, hogy a jelenlegi ulimit-u(NPROC) érték túl alacsony.
az nproc-korlát általában csak a kiszolgálón lévő folyamatokat számolja ennek a számnak a meghatározásához. A WebSphere Application Server rendszert futtató Linux rendszerek egy adott eset. A Linux nproc korlátja megszámolja az összes folyamatban lévő szálak számát, amelyek létezhetnek egy adott felhasználó számára. A Linux régebbi verzióinak legtöbb esetben ez az érték alapértelmezés szerint 2048 körül lesz. A dobozon kívül Red Hat Enterprise Linux (RHEL) 6 az nproc alapértelmezett értéke 1024 lesz.
ez az alacsony alapértelmezett beállítás nagyobb rendszereknél nem tesz lehetővé elegendő szálat az összes folyamatban.
6) Hogyan lehet kijavítani ezt a problémát?
a WebSphere Application Server Support azt javasolja, hogy az ulimit-u vagy az nproc értékét 131072 értékre állítsa Linuxon futtatva, hogy biztonságosan figyelembe vegye a létrehozható folyamatok összes villás szálát.
ideiglenesen növelhető az aktuális munkamenethez a
ulimit-u 131072
beállításával, amely beállítja a soft limit értékét.
a lágy és a kemény határértékek beállításához adja ki a
ulimit-Su 131072 értéket a lágy határértékhez.
ulimit-Hu 131072 a kemény határérték esetében.
globális beállításához a Linux rendszergazdájának szerkesztenie kell a
/etc/security/limits fájlt.conf
ez a technote elmagyarázza ezt: elégtelen ulimit-u (NPROC) érték hozzájárul a natív OutOfMemory
7) mi a helyzet a “túl sok nyitott fájl” hibával?
ez a hiba azt jelzi, hogy a folyamat összes elérhető fájlkezelőjét felhasználták (ez magában foglalja az aljzatokat is).
példa: az alábbihoz hasonló hibák láthatók a Szervernaplókban.
java.io.IOException: túl sok megnyitott fájl
prefs W nem tudta lezárni a felhasználói prefeket. UNIX hibakód 24.
8) miért történik ez a hiba?
ez akkor fordulhat elő, ha a megnyitott fájlok jelenlegi száma túl alacsony, vagy ha ez az alkalmazás egy része által kiszivárgott fájlkezelők eredménye.
9) Hogyan lehet ezt kijavítani?
az IBM support a Linuxon futó WebSphere Application Server esetében az ulimit-n értéket 65536-ként beállító megnyitott fájlok számát javasolja mind a puha, mind a kemény határértékekhez.
ulimit-Sn 65536
ulimit-Hn 65536
10) Mi van, ha van egy fájl leíró szivárgás az alkalmazásban?
Linuxon megtalálhatjuk, hogy egy adott nyitott fájl növekszik-e egy bizonyos idő alatt, ha az lsof paranccsal az alábbi adatokat vesszük figyelembe a problémás JVM folyamatazonosítóval szemben.
lsof-p-r > lsof.out
a kimenet megadja az összes megnyitott fájlt a megadott PID-hez. Ön képes lesz arra, hogy meghatározza, mely fájlok vannak megnyitva, és mely fájlok nőnek az idő múlásával.
alternatívaként felsorolhatja a fájlleírók tartalmát szimbolikus hivatkozások listájaként a következő könyvtárban, ahol a PID-t
folyamatazonosítóval helyettesíti. Ez különösen akkor hasznos, ha nincs hozzáférése az lsof parancshoz:
ls-al /proc/PID/fd
kapcsolódó technote: túl sok nyitott fájl hibaüzenet
11) van még valami, amit be kell hangolni?
van még egy beállításunk, amelyet Linuxon a pid_max használatával hangolhatunk, ami ritka, és csak nagy környezetben fordul elő. Ha nem nagy környezetet használ, kihagyhatja ezt a lépést.
a pid_max beállítás a rendszer által támogatott egyedi folyamatazonosítók maximális számának belső korlátjára vonatkozik.
az alapértelmezett érték 32 768, és ez a legtöbb ügyfél számára elegendő.
nagy környezetekben, ahol rengeteg folyamat van, lehetséges, hogy ezt a korlátot el lehet érni, és
natív OutOfMemory hasonló üzenettel fog történni
Javacore with failed to create thread errno 11.
példa:
Dump Esemény “systhrow” (00040000) részlet “java/lang/OutOfMemoryError”
“nem sikerült létrehozni egy szálat: retVal -106040066, errno 11” kapott
hogy megtalálja az aktuális pid_max értéket Linuxon.
cat /proc/sys/kernel/pid_max
növeléséhez adja ki a
sysctl-w kernelt.pid_max=< érték>
néha az alapértelmezett 32 768 érhető el valamilyen szálszivárgás/s miatt, ami natív OOM-ot okoz. Ebben az esetben meg kell javítania ezt a szálkészlet-szivárgást a natív OOM megoldásához.
kapcsolódó technotes:
hibaelhárítás natív memória problémák
potenciális natív memória használat WebSphere Application Server thread pools
Összegzés:
győződjön meg arról, hogy az alábbi ulimit beállítások Linux, hogy elkerüljék a “túl sok megnyitott fájlok hiba” és “natív out of memory” problémák miatt nem sikerült létrehozni egy szál.
felhasználói korlátok (bájtban a NOFILE és az NPROC kivételével)
soft_limit hard_limit
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072
12) van még valami, amit ellenőrizni kell?
az IBM support az alábbi értékeket ajánlja a Linuxon futó WebSphere Application Server összes ulimit beállításához, amely tartalmazza az eddig tárgyalt beállításokat.
felhasználói korlátok (byte-ban, kivéve a NOFILE-t és az NPROC-ot)
típus lágy limit kemény limit
RLIMIT_AS korlátlan korlátlan
RLIMIT_CORE korlátlan korlátlan
RLIMIT_CPU korlátlan korlátlan
RLIMIT_DATA korlátlan korlátlan
RLIMIT_FSIZE korlátlan korlátlan
RLIMIT_LOCKS korlátlan korlátlan
rlimit_memlock 65536 65536
rlimit_nofile 65536 65536
rlimit_nproc 131072 131072
13) mi a következő lépés?
győződjön meg arról, hogy a fent tárgyalt beállítások minden WebSphere Application Server JVM-en, például a DMGr-en, a Nodeagent-en és az AppServers-en vannak, és indítsa újra a JVMs-t, ha a beállításokat globálisan végezte el, vagy jelentkezzen ki, és jelentkezzen be újra ugyanazzal a felhasználóval, ha a módosításokat az aktuális munkamenetben (shell) végezte.