Résoudre les problèmes « Erreur de trop de fichiers ouverts » et « Mémoire externe native due à l’échec de la création du thread » dans WebSphere Application Server fonctionnant sous Linux

Corps

image

Nous recevons pas mal d’enregistrements de problèmes (PMR) / demandes de service (SR) pour des problèmes de mémoire externe natifs dans WebSphere Application Server et l’un des problèmes OOM natifs les plus célèbres se produit en particulier sur le système d’exploitation Linux en raison d’une valeur ulimit-u (NPROC) insuffisante.
Nous recevons également un bon nombre de PMR pour l’erreur « Trop de fichiers ouverts » pour WebSphere Application Server fonctionnant sous Linux.
Avec un dépannage simple et un réglage de commande ulimit, vous pouvez facilement éviter d’ouvrir un PMR avec le support IBM pour ces problèmes.

1) Qu’est-ce que ulimit sous Linux ?
La commande ulimit vous permet de contrôler les limites de ressources utilisateur dans le système, telles que la taille des données de traitement, la mémoire virtuelle de traitement et la taille du fichier de traitement, le nombre de processus, etc.

2) Que se passe-t-il lorsque les paramètres de cette commande ne sont pas configurés correctement ?
Divers problèmes se produisent comme OutOfMemory natif, Trop d’erreurs de fichiers ouverts, les fichiers de vidage ne sont pas complètement générés, etc.

3) Comment pouvez-vous vérifier les paramètres ulimit actuels?
Il existe différentes façons de vérifier les paramètres actuels:

a) À partir de l’invite de commande, émettez
$ulimit-a
Nous pouvons voir une sortie similaire comme ci-dessous.
taille du fichier de base (blocs, -c) 0
taille de la segmentation des données (kbytes, -d) illimitée
priorité de planification (-e) 0
taille du fichier (blocs, -f) illimitée
signaux en attente (-i) 32767
mémoire verrouillée maximale (kbytes, -l) 32
taille de la mémoire maximale (kbytes, -m) illimitée
fichiers ouverts (kbytes, -m) -n) 1024
taille du tuyau (512 octets, -p) 8
files d’attente de messages POSIX (octets, -q) 819200
priorité en temps réel (-r) 0
taille de la pile (kbytes, -s) 10240
temps cpu (secondes, -t) illimité
processus utilisateur maximum (-u) 50
mémoire virtuelle (kbytes , -v) illimité
verrous de fichiers (-x) illimité
Cela s’affichera tous les paramètres actuels définis pour la session de connexion en cours et par défaut les limites logicielles seront affichés. Les limites peuvent être douces et dures.
Les limites strictes sont la limite maximale qui peut être configurée. Seul l’utilisateur root peut augmenter les limites strictes, bien que d’autres utilisateurs puissent les diminuer. Les limites souples peuvent être définies et modifiées par d’autres utilisateurs, mais elles ne peuvent pas dépasser les limites strictes.
Si vous souhaitez trouver des valeurs limites spécifiques, problème
ulimit-Sa
pour la valeur limite souple actuelle.
ulimit-Ha
pour la valeur limite dure actuelle.

b) Si vous connaissez l’ID de processus (PID) du serveur d’applications WebSphere à examiner, vous pouvez également inspecter le fichier suivant.
Location: /proc/< PID >
File:limits
Le contenu de ce fichier est similaire à la sortie de la commande « ulimit-a ».
Ce fichier contient une liste des paramètres ulimit et leurs valeurs associées pour le PID spécifié.
c) Si vous connaissez l’ID de processus du serveur que vous souhaitez vérifier les paramètres ulimit actuels, vous pouvez prendre un Javacore en émettant
kill-3 < PID >
Vous pouvez ouvrir ce Javacore dans n’importe quel éditeur de texte (comme NotePad++, Ultra Edit, etc.)
et recherchez ulimit et il vous faudra la section ulimit.
Exemple de paramètres ulimit tel qu’il est vu à partir d’un Javacore.
Limites d’utilisateur (en octets à l’exception de NOFILE et NPROC)
————————————————————–
type limite souple limite dure
RLIMIT_AS 11788779520 illimité
RLIMIT_CORE 1024 illimité
RLIMIT_CPU illimité illimité
RLIMIT_DATA illimité illimité
RLIMIT_FSIZE illimité illimité
RLIMIT_LOCKS illimité illimité
RLIMIT_MEMLOCK illimité illimité
RLIMIT_NOFILE 18192 18192
RLIMIT_NPROC 79563 79563
RLIMIT_RSS 8874856448 illimité
RLIMIT_STACK 33554432 illimité
Si vous souhaitez trouver les paramètres globaux, inspectez le fichier ci-dessous sous linux.
/etc/security/limits.conf.
Toute modification de ces fichiers de limites de configuration globales doit être effectuée par votre administrateur système.
Pour en savoir plus sur chaque paramètre de la commande ulimit et pour en savoir plus sur la commande ulimit sur différents systèmes d’exploitation, consultez cette note technique: Directives pour la configuration d’ulimits (WebSphere Application Server)

4) Quel type de MOO native est attendu en raison de paramètres ulimit insuffisants ?
Un événement de vidage hors mémoire avec un « Échec de la création d’un thread » va se produire.
Exemple: Le message ci-dessous apparaîtra dans Javacore.
« systhrow »(00040000) Détail « java/lang/OutOfMemoryError »
 » Échec de la création d’un thread: retVal-1073741830, errno 12″ reçu
errno 12 est une MOO native réelle sur un thread de démarrage.
Parfois, l’échec de la création d’un thread est également visible dans les journaux du serveur comme SystemOut.log, SystemErr.log etc., et aussi dans les journaux FFDC et cette erreur indique qu’une mémoire externe native s’est produite lors de la création d’un nouveau thread.

5) Quelle est la raison de cette erreur?
La raison en est que la valeur ulimit-u (NPROC) actuelle est trop faible.
La limite nproc ne compte généralement que les processus sur un serveur pour déterminer ce nombre. Les systèmes Linux exécutant WebSphere Application Server sont un cas particulier. La limite nproc sous Linux compte le nombre de threads dans tous les processus pouvant exister pour un utilisateur donné. Pour la plupart des versions plus anciennes de Linux, cette valeur sera par défaut à environ 2048. Pour Red Hat Enterprise Linux (RHEL) 6 prêt à l’emploi, la valeur par défaut de nproc sera définie sur 1024.
Ce paramètre par défaut faible pour les systèmes plus grands ne permettra pas d’avoir suffisamment de threads dans tous les processus.

6) Comment résoudre ce problème?
WebSphere Application Server Support recommande de définir ulimit-u ou nproc sur une valeur de 131072 lors de l’exécution sous Linux pour tenir compte en toute sécurité de tous les threads fourchus dans les processus qui pourraient être créés.
Il peut être augmenté temporairement pour la session en cours en définissant
ulimit-u 131072
qui définit la valeur de limite souple.
Pour définir à la fois des limites souples et des limites dures, émettez
ulimit-Su 131072 pour limite souple.
ulimit-Hu 131072 pour limite dure.
pour le définir globalement, l’administrateur système Linux doit éditer
/etc/security/limits.conf
Nous avons cette note technique expliquant ceci: Une valeur ulimit-u (NPROC) insuffisante Contribue à la mémoire externe native

7) Qu’en est-il de l’erreur « Trop de fichiers ouverts »?
Cette erreur indique que tous les descripteurs de fichiers disponibles pour le processus ont été utilisés (cela inclut également les sockets).
Exemple : Des erreurs similaires à celles ci-dessous seront visibles dans les journaux du serveur.
java.io.IOException : Trop de fichiers ouverts
prefs W N’a pas pu verrouiller les prefs de l’utilisateur. Code d’erreur UNIX 24.

8) Pourquoi cette erreur se produit-elle?
Cela peut se produire si la limite actuelle du nombre de fichiers ouverts est trop faible ou si cela résulte de la fuite de poignées de fichiers par une partie de l’application.

9) Comment résoudre ce problème?
Le support IBM recommande que le nombre de fichiers ouverts définisse la valeur ulimit-n pour WebSphere Application Server fonctionnant sous Linux comme 65536 pour les limites soft et hard.
ulimit-Sn 65536
ulimit-Hn 65536

10) Que se passe-t-il s’il y a une fuite de descripteur de fichier dans l’application?
Sous Linux, nous pouvons trouver si des fichiers ouverts particuliers se développent sur une période de temps en prenant les données ci-dessous avec la commande lsof contre l’ID de processus JVM problématique sur une base périodique.
lsof-p-r > lsof.out
La sortie vous fournira tous les fichiers ouverts pour le PID spécifié. Vous serez en mesure de déterminer quels fichiers sont ouverts et quels fichiers grandissent au fil du temps.
Alternativement, vous pouvez lister le contenu des descripteurs de fichier sous forme de liste de liens symboliques dans le répertoire suivant, où vous remplacez PID par
l’ID de processus. Ceci est particulièrement utile si vous n’avez pas accès à la commande lsof:
ls-al/proc/PID/fd
Technote connexe: Trop de fichiers ouverts message d’erreur

11) Y a-t-il autre chose à régler ?
Nous avons un paramètre de plus que nous pouvons régler sur Linux en utilisant pid_max, ce qui est rare et ne se produit que dans de grands environnements. Si vous n’utilisez pas un environnement volumineux, vous pouvez ignorer cette étape.
Le paramètre pid_max correspond à la limite interne du nombre maximal d’identifiants de processus uniques pris en charge par votre système.
La valeur par défaut est 32 768, ce qui est suffisant pour la plupart des clients.
Sur les grands environnements avec un grand nombre de processus, il est possible que cette limite soit atteinte et
OutOfMemory natif se produira avec un message similaire dans
Javacore avec échec de la création du thread errno 11.
Exemple :
Événement de vidage « systhrow »(00040000) Détail « java/lang/OutOfMemoryError »
 » Échec de la création d’un thread : retVal-106040066, errno 11″ reçu
Pour trouver la valeur pid_max actuelle sous Linux.
cat/proc/sys/kernel/pid_max
Pour l’augmenter, émettez le noyau sysctl-w
.pid_max = < Valeur >
Parfois, le 32 768 par défaut peut être atteint en raison de certaines fuites de threads, provoquant une OOM native. Dans ce cas, vous devez corriger cette fuite de pool de threads pour résoudre la MOO native.
Technotes connexes :
Dépannage des problèmes de mémoire native
Utilisation potentielle de la mémoire native dans les pools de threads WebSphere Application Server
Résumé:
Assurez-vous d’avoir les paramètres ulimit ci-dessous sur Linux pour éviter les problèmes de « trop d’erreurs de fichiers ouverts » et de « mémoire native insuffisante » dus à l’échec de la création d’un thread.
Limites d’utilisateur (en octets à l’exception de NOFILE et NPROC)
limite souple
Limite dure
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072

12) Y a-t-il autre chose à vérifier?
IBM support recommande les valeurs ci-dessous pour tous les paramètres ulimit pour WebSphere Application Server fonctionnant sous Linux, qui incluent les paramètres que nous avons discutés jusqu’à présent.
Limites de l’utilisateur (en octets à l’exception de NOFILE et NPROC)
type soft limit hard limit
RLIMIT_AS illimité illimité
RLIMIT_CORE illimité illimité
RLIMIT_CPU illimité illimité
RLIMIT_DATA illimité illimité
RLIMIT_FSIZE illimité illimité
RLIMIT_LOCKS illimité illimité
RLIMIT_MEMLOCK 65536 65536
RLIMIT_NOFILE 65536 65536
RLIMIT_NPROC 131072 131072

13) Quelle est la prochaine étape ?
Assurez-vous d’avoir les paramètres discutés ci-dessus sur toutes les JVM WebSphere Application Server telles que DMGr, NodeAgent et AppServers et redémarrez les JVM si les paramètres ont été effectués globalement ou déconnectez-vous et reconnectez-vous avec le même utilisateur si les modifications ont été effectuées dans la session en cours (shell).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.