Body
we ontvangen nogal wat probleemrecords ( PMRs) / service requests (SRs) voor native OutOfMemory problemen in WebSphere Application Server en een van de meest bekende native OOM problemen gebeurt vooral op Linux OS als gevolg van onvoldoende ulimit-u(NPROC) waarde.
we ontvangen ook een groot aantal PMRs voor” te veel Open bestanden ” fout voor WebSphere Application Server die draait op Linux.
met eenvoudige troubleshooting en ulimit Commando tuning, kunt u gemakkelijk voorkomen dat u een PMR opent met IBM-ondersteuning voor deze problemen.
1) Wat is ulimit in Linux?
met het ulimit Commando kunt u de gebruikersbronlimieten in het systeem beheren, zoals de grootte van de procesgegevens, het virtuele geheugen van het proces, en de bestandsgrootte van het proces, het aantal processen, enz.
2) Wat gebeurt er als de instellingen in dit commando niet goed zijn ingesteld?
er gebeuren verschillende problemen zoals native OutOfMemory, te veel Open bestanden fout, dump bestanden worden niet volledig gegenereerd etc.
3) Hoe kunt u de huidige ulimit-instellingen controleren?
er zijn verschillende manieren om de huidige instellingen te controleren:
a) vanaf de opdrachtprompt, geef
$ ulimit-a
we kunnen vergelijkbare uitvoer zien zoals hieronder.
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32767
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -Q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconden, -t) onbeperkt
max. gebruikersprocessen (-u) 50
virtueel geheugen (kbytes, -V) onbeperkt
file locks (-x) onbeperkt
dit wordt weergegeven alle huidige instellingen die zijn ingesteld voor de huidige aanmeldsessie en standaard zachte limieten worden weergegeven. Limieten kunnen zacht en Hard zijn.
harde limieten zijn de maximale limiet die geconfigureerd kan worden. Alleen de root gebruiker kan harde limieten verhogen, hoewel andere gebruikers ze kunnen verlagen. Zachte limieten kunnen door andere gebruikers worden ingesteld en gewijzigd, maar ze mogen de harde limieten niet overschrijden.
als u specifieke grenswaarden wilt vinden, geef dan
ulimit-Sa
op voor de huidige zachte grenswaarde.
ulimit-Ha
voor de huidige harde grenswaarde.
b) Als u de Process ID (PID) van de WebSphere Application Server kent die moet worden onderzocht, kunt u ook het volgende bestand inspecteren.
locatie: / proc / <PID>
bestand:limieten
de inhoud van dit bestand is vergelijkbaar met de uitvoer van het commando “ulimit-a”.
dit bestand bevat een lijst met ulimit parameters en de bijbehorende waarden voor de opgegeven PID.
C) als u het proces-ID weet van de server die u de huidige ulimit-instellingen wilt controleren, kunt u een Javacore nemen door
kill -3 <PID>
uit te geven.u kunt deze Javacore openen in elke teksteditor (zoals NotePad++, Ultra Edit etc.)
en zoek naar ulimit en het zal u de ulimit sectie.
voorbeeld van ulimit instellingen zoals het gezien wordt vanuit een Javacore.
Gebruiker Limieten (in bytes, behalve voor NOFILE en NPROC)
————————————————————–
type zachte limiet limiet
RLIMIT_AS 11788779520 onbeperkt
RLIMIT_CORE 1024 onbeperkt
RLIMIT_CPU onbeperkt onbeperkt
RLIMIT_DATA onbeperkt onbeperkt
RLIMIT_FSIZE onbeperkt onbeperkt
RLIMIT_LOCKS onbeperkt onbeperkt
RLIMIT_MEMLOCK onbeperkt onbeperkt
RLIMIT_NOFILE 18192 18192
RLIMIT_NPROC 79563 79563
RLIMIT_RSS 8874856448 onbeperkt
RLIMIT_STACK 33554432 onbeperkt
Als u wilt zoeken naar de globale instellingen, inspecteer het onderstaande bestand in linux.
/etc / security / limits.conf.
alle wijzigingen in deze globale configuratielimieten bestanden moeten worden uitgevoerd door uw systeembeheerder.
voor meer informatie over elke instelling in ulimit commando en ook over ulimit commando op verschillende OS, zie deze technote: Guidelines for setting ulimits (WebSphere Application Server)
4) wat voor soort native OOM wordt verwacht als gevolg van onvoldoende ulimit instellingen?
er zal een Dump-gebeurtenis met een “fout bij het aanmaken van een thread” plaatsvinden.
voorbeeld: Onderstaand bericht verschijnt in Javacore.
” systhrow “(00040000) Detail”java/lang/OutOfMemoryError”
” kon geen thread aanmaken: retVal -1073741830, errno 12 ” received
errno 12 is een echte native OOM op een start thread.
soms wordt het niet aanmaken van een thread ook gezien in serverlogboeken zoals SystemOut.log, SystemErr.log enz., en ook in FFDC logs en deze fout geeft een native OutOfMemory gebeurde tijdens het maken van nieuwe thread.
5) Wat is de reden voor deze fout?
de reden is dat de huidige ulimit-u (NPROC) waarde te laag is.
de nproc-limiet telt meestal alleen processen op een server om dit getal te bepalen. Linux systemen die WebSphere Application Server draaien zijn een bijzonder geval. De nproc limiet op Linux telt het aantal threads binnen alle processen die kunnen bestaan voor een bepaalde gebruiker. Voor de meeste gevallen van oudere versies van Linux zal deze waarde worden standaard tot rond 2048. Voor out of the box Red Hat Enterprise Linux (RHEL) 6 wordt de standaardwaarde voor nproc ingesteld op 1024.
deze lage standaardinstelling voor grotere systemen laat niet genoeg threads toe in alle processen.
6) Hoe dit probleem op te lossen?
WebSphere Application Server Support raadt aan om de ulimit-u of nproc in te stellen op een waarde van 131072 bij het draaien onder Linux om veilig rekening te houden met alle gevorkte threads binnen processen die kunnen worden aangemaakt.
het kan tijdelijk worden verhoogd voor de huidige sessie Door het instellen van
ulimit-u 131072
die de waarde voor zachte limiet.
om zowel zachte als harde limieten in te stellen, geef
ulimit-Su 131072 voor zachte limieten.
ulimit-Hu 131072 voor harde limiet.
om het globaal in te stellen, moet de Linux systeembeheerder
/etc/security/limits bewerken.conf
we hebben deze technote die dit verklaart: onvoldoende ulimit-u (NPROC) waarde draagt bij aan Native OutOfMemory
7) Hoe zit het met “te veel Open bestanden” fout?
deze fout geeft aan dat alle beschikbare bestandshandvatten voor het proces zijn gebruikt (Dit omvat ook sockets).
voorbeeld: fouten vergelijkbaar met hieronder zullen worden gezien Server logs.
java. io. Ioeexception: te veel geopende bestanden
prefs W kon geen gebruiker prefs vergrendelen. UNIX-foutcode 24.
8) Waarom gebeurt deze fout?
het kan gebeuren als het huidige aantal geopende bestanden te laag is of als dit het resultaat is van het lekken van bestandshandvatten door een deel van de toepassing.
9) Hoe dit te verhelpen?
IBM support raadt het aantal open bestanden aan om ulimit-n waarde in te stellen voor WebSphere Application Server die draait op Linux als 65536 voor zowel zachte als harde limieten.
ulimit-Sn 65536
ulimit-Hn 65536
10) Wat als er een lek is in de toepassing?
op Linux kunnen we vinden of bepaalde open bestanden groeien over een periode van tijd door het nemen van onderstaande gegevens met lsof commando tegen he problematische JVM proces ID op een periodieke basis.
lsof-p-r > lsof.out
de uitvoer zal u voorzien van alle geopende bestanden voor de opgegeven PID. U zult in staat zijn om te bepalen welke bestanden worden geopend en welke bestanden groeien in de tijd.
afwisselend kunt u de inhoud van de bestandsdescriptoren weergeven als een lijst van symbolische links in de volgende map, waar u PID vervangt door
het proces-ID. Dit is vooral handig als je geen toegang hebt tot het lsof Commando:
ls-al/proc/PID / fd
gerelateerde technote: te veel Open bestanden foutmelding
11) is er nog iets anders om af te stemmen?
we hebben nog een instelling die we op Linux kunnen afstemmen met pid_max, wat zeldzaam is en alleen in grote omgevingen voorkomt. Als u geen grote omgeving gebruikt, kunt u deze stap overslaan.
de pid_max-instelling is voor interne limiet voor maximaal aantal unieke proces-id ‘ s die uw systeem ondersteunt.
de standaardwaarde is 32.768 en dit is voldoende voor de meeste klanten.
op grote omgevingen met een groot aantal processen is er een mogelijkheid dat deze limiet kan worden bereikt en
native OutOfMemory zal gebeuren met een soortgelijk bericht in
Javacore met een fout in het aanmaken van thread errno 11.
voorbeeld:
Dump Event ” systhrow “(00040000) Detail”java/lang/OutOfMemoryError”
” kon geen thread aanmaken: retVal -106040066, errno 11 ” received
To find the current pid_max value on Linux.
cat / proc/sys/kernel / pid_max
om het te verhogen,geef
sysctl-w kernel uit.Pid_max = <waarde>
soms kan de standaard 32,768 worden bereikt vanwege een aantal thread leak / s,waardoor native OOM wordt veroorzaakt. In dit geval moet u deze draadpool Lek repareren om native OOM op te lossen.
gerelateerde technotes:
problemen met native memory oplossen
potentieel native memory gebruik in WebSphere Application Server thread pools
samenvatting:
zorg ervoor dat u de onderstaande ulimit instellingen op Linux hebt om “te veel open files error” en “native out of memory” problemen te voorkomen omdat het aanmaken van een thread mislukt.
Gebruikerslimieten (in bytes behalve voor NOFILE en NPROCES)
soft_limit hard_limit
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROCES 131072 131072
12) is er nog iets te controleren?
IBM support raadt de onderstaande waarden aan voor alle ulimit instellingen voor WebSphere Application Server die draait op Linux, inclusief de instellingen die we tot nu toe besproken hebben.
Gebruiker Limieten (in bytes, behalve voor NOFILE en NPROC)
type zachte limiet limiet
RLIMIT_AS onbeperkt onbeperkt
RLIMIT_CORE onbeperkt onbeperkt
RLIMIT_CPU onbeperkt onbeperkt
RLIMIT_DATA onbeperkt onbeperkt
RLIMIT_FSIZE onbeperkt onbeperkt
RLIMIT_LOCKS onbeperkt onbeperkt
RLIMIT_MEMLOCK 65536 65536
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072
13) Wat is het volgende?
zorg ervoor dat de hierboven besproken instellingen op alle WebSphere Application Server JVM ’s zoals DMGr, NodeAgent en AppServers en herstart de JVM’ s als de Instellingen globaal werden gedaan of uitloggen en opnieuw inloggen met dezelfde gebruiker als de wijzigingen werden gedaan in de huidige sessie (shell).