Controllare il limite FD aperto per un determinato processo in Linux

Question

Recentemente ho avuto un processo Linux che ha "filtrato" i descrittori di file: li ha aperti e non ne ha chiusi correttamente alcuni.

Se l'avessi monitorato, potrei dire - in anticipo - che il processo stava raggiungendo il suo limite.

C'è un bel modo Bash \ Python per verificare il rapporto di utilizzo FD per un dato processo in un sistema Linux Ubuntu?

EDIT:

ora so come controllare il numero di descrittori di file aperti ci sono; Ho solo bisogno di sapere quanti descrittori di file sono consentiti per un processo. Alcuni sistemi (come Amazon EC2) non hanno il file /proc/pid/limits.

Grazie,

Udi

Answer 1

Contare le voci in /proc/<pid>/fd/. I limiti hard e soft applicabili al processo sono disponibili in /proc/<pid>/limits.

Answer 2

Si può provare a scrivere script che chiamano periodicamente lsof -p {PID} sul dato pid.

Answer 3

Hai chiesto i metodi bash/python. ulimit sarebbe il miglior approccio bash (a corto di munging attraverso /proc/$pid/fd e simili a mano). Per Python, potresti usare il modulo delle risorse.

import resource 

print(resource.getrlimit(resource.RLIMIT_NOFILE)) 

$ python test.py 

(1024, 65536) 

resource.getrlimit corrisponde alla getrlimit chiamata in un programma C. I risultati rappresentano i valori attuali e massimi per la risorsa richiesta. Nell'esempio precedente, il limite corrente (soft) è 1024. I valori sono valori predefiniti tipici sui sistemi Linux in questi giorni.

Answer 4

Le uniche interfacce fornite dal kernel Linux per ottenere i limiti delle risorse sono getrlimit() e /proc/pid/limits. getrlimit() può ottenere solo i limiti di risorse del processo chiamante. /proc/pid/limits consente di ottenere i limiti di risorse di qualsiasi processo con lo stesso ID utente ed è disponibile su RHEL 5.2, RHEL 4.7, Ubuntu 9.04 e qualsiasi distribuzione con un kernel 2.6.24 o successivo.

Se è necessario supportare i sistemi Linux precedenti, sarà necessario richiamare il processo stesso per chiamare getrlimit(). Naturalmente il modo più semplice per farlo è modificando il programma o una libreria che utilizza. Se si sta eseguendo il programma, è possibile utilizzare LD_PRELOAD per caricare il proprio codice nel programma. Se nessuno di questi è possibile, puoi allegare al processo con gdb e farlo eseguire la chiamata all'interno del processo. Puoi anche fare tu stesso la stessa cosa usando ptrace() da allegare al processo, inserire la chiamata nella sua memoria, ecc., Tuttavia questo è molto complicato per essere corretto e non è raccomandato.

Con i privilegi appropriati, gli altri modi per farlo consistono nell'osservare la memoria del kernel, caricare un modulo del kernel, o altrimenti modificare il kernel, ma presumo che questi siano fuori questione.

Answer 5

visualizzare i primi 20 di gestione del file utilizzando processi:

for x in `ps -eF| awk '{ print $2 }'`;do echo `ls /proc/$x/fd 2> /dev/null | wc -l` $x `cat /proc/$x/cmdline 2> /dev/null`;done | sort -n -r | head -n 20 

l'uscita è nel conteggio handle file di formato, pid, cmndline per processo

esempio uscita

701 1216 /sbin/rsyslogd-n-c5 
169 11835 postgres: spaceuser spaceschema [local] idle 
164 13621 postgres: spaceuser spaceschema [local] idle 
161 13622 postgres: spaceuser spaceschema [local] idle 
161 13618 postgres: spaceuser spaceschema [local] idle 

Answer 6

In CentOS 6 e versioni successive (qualsiasi cosa usi GCC 3), potresti scoprire che la regolazione dei limiti del kernel non risolve il problema. Questo perché esiste un valore FD_SETSIZE impostato in fase di compilazione in uso da GCC. Per questo, è necessario aumentare il valore e quindi ricompilare il processo.

Inoltre, è possibile che si stiano perdendo descrittori di file a causa di known issues in libpthread se si utilizza tale libreria. Questa chiamata è stata integrata in GCC in GCC 4/CentOS7/RHEL 7 e questo sembra aver risolto i problemi di threading.