Internally, there is a scheduled refresh of the indices that might keep
those around (deleted files), and I not sure about the operating system
keeping some of them around and when it actually decides to deletes them.
There have been some tests run that shows that under load (both indexing and
searching) the number of opened files are not increased over time, but kept
at a steady number (+/- a delta). Usually, I recommend setting the max open
files to 16k or even 32k, as open files are also sockets and other.
If you do find in your tests that they keep increasing over time without
stopping, then I can have a look at it and fix it if there is a leak.
On Fri, Oct 15, 2010 at 6:54 PM, Tom May firstname.lastname@example.org wrote:
That makes sense, but there are no open search operations on that
index, or any of the indexes, at least not any searches that were
initiated from an api. That's from a fresh run where I stopped ES,
deleted /work, restarted ES, and used the http bulk index API to put
data into a couple hundred indexes. I haven't done any searches yet,
I'm just poking around to see what kind of ulimit I might need. The
fds have been showing up as (deleted) for over an hour, and I'm
wondering if the process is ever going to close them.
I re-indexed the data into the same indexes and the fds were closed, so
- The files were closed properly by the application at some point.
- There is a leak, and the files were closed when java gc'd them.
On Fri, Oct 15, 2010 at 9:28 AM, Shay Banon
Yes, those deleted files are needed to be kept around if there are open
search operations on going against them. Once they are done, those files
will be actually deleted (by the OS). Its really a file handle leak if
see an increase of it over time.
On Fri, Oct 15, 2010 at 6:14 PM, Tom May email@example.com wrote:
When I run lsof on the ElasticSearch java process it often shows that
some of the open files have been deleted. Does ElasticSearch and/or
Lucene really need to keep these deleted files open so it can continue
to use them, or is this just an oversight/bug?
$ lsof -p 6192 | egrep deleted | head -n 3
java 6192 gist 915r REG 202,2 103830 21147619
java 6192 gist 918r REG 202,2 47849 21147621
java 6192 gist 919r REG 202,2 24076 21147622