@oligofren
J'ai également effectué des tests afin de déterminer comment "ulimits -Sn"pour "open files"a été appliquée.
Comme l'affiche Chosen mentionnée dans le lien , l'ulimit pour "open files"est en effet appliqué par processus. Pour voir quelles sont les limites actuelles du processus:
cat /proc/__process_id__/limits
Pour déterminer le nombre de fichiers ouverts par un processus, vous devez utiliser la commande suivante:
lsof -P -M -l -n -d '^cwd,^err,^ltx,^mem,^mmap,^pd,^rtd,^txt' -p __process_id__ -a | awk '{if (NR>1) print}' | wc -l
Explication de ce qui précède et de ma méthode / résultats de test
Les "-P -M -l -n"arguments de lsof sont simplement là pour faire fonctionner lsof le plus rapidement possible. N'hésitez pas à les retirer.
-P - inhibits the conversion of port numbers to port names for network files
-M - disable reporting of portmapper registrations for local TCP, UDP and UDPLITE ports
-l - inhibits the conversion of user ID numbers to login names
-n - inhibits the conversion of network numbers to host names for network files
L' "-d '^cwd,^err,^ltx,^mem,^mmap,^pd,^rtd,^txt'"argument indique lsofd'exclure les descripteurs de fichiers de type: cwd / err / ltx / mem / mmap / pd / rtd / txt.
Depuis la page de manuel lsof:
FD is the File Descriptor number of the file or:
cwd current working directory;
Lnn library references (AIX);
err FD information error (see NAME column);
jld jail directory (FreeBSD);
ltx shared library text (code and data);
Mxx hex memory-mapped type number xx.
m86 DOS Merge mapped file;
mem memory-mapped file;
mmap memory-mapped device;
pd parent directory;
rtd root directory;
tr kernel trace file (OpenBSD);
txt program text (code and data);
v86 VP/ix mapped file;
J'ai considéré "Lnn,jld,m86,tr,v86"comme non applicable à Linux et je n'ai donc pas pris la peine de les ajouter à la liste d'exclusion. Je n'en suis pas sûr "Mxx".
Si votre application utilise des fichiers / périphériques mappés en mémoire, vous souhaiterez peut-être les supprimer "^mem"et "^mmap"les exclure de la liste.
MODIFIER --- commencer le snip ---
Edit: j'ai trouvé le lien suivant qui indique que:
Les fichiers .so mappés en mémoire ne sont pas techniquement les mêmes que les descripteurs de fichiers sur lesquels l'application a le contrôle. / proc // fd est le point de mesure des descripteurs de fichiers ouverts
Donc, si votre processus utilise des fichiers mappés en mémoire, vous devrez filtrer les fichiers * .so.
De plus, la JVM de Sun va mapper en mémoire les fichiers jar
Un fichier JAR mappé en mémoire, dans ce cas le fichier qui contient les "classes JDK". Lorsque vous mappez en mémoire un fichier JAR, vous pouvez accéder aux fichiers qu'il contient de manière très efficace (au lieu de le lire chaque fois depuis le début). La JVM Sun mappe en mémoire tous les fichiers JAR du chemin de classe; si votre code d'application doit accéder à un fichier JAR, vous pouvez également le mapper en mémoire.
Ainsi, des choses comme tomcat / glassfish afficheront également des fichiers jar mappés en mémoire. Je n'ai pas testé si ceux-ci comptent pour la "ulimit -Sn"limite.
EDIT --- fin de capture ---
Empiriquement, j'ai trouvé que "cwd,rtd,txt"sont pas pris en compte en ce qui concerne la limite par fichier de processus (ulimit -Sn).
Je ne sais pas s'ils "err,ltx,pd"sont pris en compte dans la limite de fichiers car je ne sais pas comment créer des descripteurs de fichiers de ces types de descripteurs.
L' "-p __process_id__"argument se limite lsofà renvoyer uniquement des informations pour le __process_id__spécifié. Supprimez-le si vous souhaitez obtenir un compte pour tous les processus.
L' "-a"argument est utilisé pour ET les sélections (c'est-à-dire les arguments "-p" et "-d").
L' "awk '{if (NR>1) print}'"instruction est utilisée pour ignorer l'en-tête qui lsofs'imprime dans sa sortie.
J'ai testé en utilisant le script perl suivant:
File: test.pl
---snip---
#!/usr/bin/perl -w
foreach $i (1..1100) {
$FH="FH${i}";
open ($FH,'>',"/tmp/Test${i}.log") || die "$!";
print $FH "$i\n";
}
---snip---
J'ai dû exécuter le script dans le débogueur perl pour m'assurer que le script ne se termine pas et libérer les descripteurs de fichiers.
Éxécuter: perl -d test.pl
Dans le débogueur de Perl, vous pouvez exécuter le programme en entrant cet en appuyant sur Entrée et si votre ulimit -Snvaleur était 1024 , vous constaterez que le programme s'arrête après la création du Test1017.logfichier dans /tmp.
Si vous identifiez maintenant le pid du processus perl et utilisez la lsofcommande ci-dessus, vous verrez qu'il génère également 1024 .
Supprimez le "wc -l"et remplacez-le par un "less"pour voir la liste des fichiers comptés pour la limite de 1024 . Supprimez également l' "-d ^....."argument pour voir que les descripteurs cwd,txtet ne comptent pas dans la limite.rtd
Si vous exécutez maintenant "ls -l /proc/__process_id__/fd/ | wc -l", vous verrez une valeur de 1025 retournée. En effet, lsun en- "total 0"tête a été ajouté à sa sortie qui a été compté.
Remarque:
Pour vérifier si le système d'exploitation manque de descripteurs de fichiers, il est préférable de comparer la valeur de:
cat /proc/sys/fs/file-nr | awk '{print $1}'
avec
cat /proc/sys/fs/file-max
https://www.kernel.org/doc/Documentation/sysctl/fs.txt documente ce file-nrque file-maxsignifie et signifie.