Je travaille sur un serveur Debian avec Tomcat 7 et Java 1.7. Il s'agit d'une application qui reçoit plusieurs connexions TCP, chaque connexion TCP est un fichier ouvert par le processus Java.
En regardant /proc/pid of Java/fd
, j’ai trouvé que, parfois, le nombre de fichiers ouverts dépassait 1024, lorsque cela se produit, je trouve dans catalina.out
le journal stackstace _SocketException: Too many open files_
Tout ce que je trouve à propos de cette erreur, les gens se réfèrent à l'ulimit, j'ai déjà changé cette chose et l'erreur continue à se produire. Voici la config:
à /etc/security/limits.conf
root soft nofile 8192
root hard nofile 8192
à /etc/sysctl.conf
fs.file-max = 300000
la commande ulimit -a
renvoie:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 8192
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Mais, quand je vérifie les limites du processus Java, ce n'est que 1024
à /proc/pid of Java/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 32339 32339 processes
Max open files 1024 1024 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 32339 32339 signals
Max msgqueue size 819200 819200 bytes
Max Nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Comment puis-je augmenter le nombre de Max open files
pour le processus Java?
Je viens de mettre la ligne ulimit -n 8192
à l'intérieur de catalina.sh, donc lorsque je fais le catalina start
, Java s'exécute avec la limite spécifiée ci-dessus.
Les valeurs ulimit étant attribuées au démarrage de la session, la modification de /etc/security/limits.conf n'aura aucun effet sur les processus en cours d'exécution. Les processus qui ne se connectent pas hériteront des valeurs ulimit de leur père, un peu comme l'héritage des variables d'environnement.
Ainsi, après avoir modifié /etc/security/limits.conf, vous devrez vous déconnecter et vous connecter (pour que votre session ait les nouvelles limites), puis redémarrer l'application. Ce n’est qu’ainsi que votre application pourra utiliser les nouvelles limites.
Définir ulimit supérieur peut être totalement inutile en fonction de la charge de travail/du trafic traité par Tomcat/httpd. Linux crée un descripteur de fichier par connexion de socket. Par conséquent, si Tomcat est configuré pour utiliser le protocole mod_jk/ajp en tant que connecteur, vous souhaiterez peut-être savoir si le nombre maximal de connexions autorisées est trop élevé ou si connectionTimeout ou keepAliveTimeout est trop élevé. Ces paramètres jouent un rôle important dans la consommation de descripteurs de fichiers du système d'exploitation. Parfois, il est également possible de limiter le nombre de connexions Apache httpd/nginx si Tomcat est précédé d’un proxy inverse. Une fois, j’ai réduit la valeur serverLimit dans httpd pour limiter les demandes entrantes au cours du scénario gaterush. Globalement, ajuster ulimit peut ne pas être une option viable, car votre système risque de consommer peu importe le nombre de tentatives. Vous devrez élaborer un plan holistique pour résoudre ce problème.