On 26/03/2012 09:56, Kurt Jaeger wrote:
>>> From knowing that you have too many files open you can increase the
>>> > > maxfile numbers - but if you want to know what uses them try this -
>>> > >
>>> > > lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort
> On my system, it shows interesting numbers for firefox-instances:
>
> 3895 4150 firefox-b
> 4160 72958 firefox-b
> 4240 3594 firefox-b
> 4320 4232 firefox-b
> 4431 89391 firefox-b
>
> This seems to come from threads, where lsof shows the same
> descriptor as open for multiple times, even if it comes from the
> same process memory.
>
> For example for pid 4232:
>
> lsof -n | grep icon-theme.cache | grep 4232 | wc -l
>
> firefox-b 4232 pi txt VREG 0,102
> 10784 924293 /usr/local/share/icons/hicolor/icon-theme.cache
>
> This happens on 8.1-REL-p5 amd64. So the method is not fail-safe
> for the real number of open files.
>
Does 'procstat -fa' give better results for you?
It seems to be one of those little hidden secrets that FreeBSD comes
with a bunch of native applications that provide pretty much equivalent
functionality to lsof(1). See: fstat(1), procstat(1), sockstat(1).
Which is odd, given that since these sort of applications have to read
and interpret kernel memory -- an action for which there isn't a nice
well defined ABI -- the application has to be kept rigorously in synch
with the kernel it is used against. Something that is intrinsically
easier to do when kernel and application are compiled at the same time
and from the same source tree.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
