Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
Sender: sbower@alcyon.net
Date: Tue, 7 Jan 2014 09:48:19 -0500
Message-ID: 
 <CAOfkKh=86VPbBOKE2e8hG0MU5Dr0oGn73qmvnv1h7oArdOddrw@mail.gmail.com>
Subject: Index Sizes
From: Steven Bower <smb-apache@alcyon.net>
To: solr-user <solr-user@lucene.apache.org>
Content-Type: multipart/alternative; boundary=001a1132f1ba977b6604ef62771c

--001a1132f1ba977b6604ef62771c
Content-Type: text/plain; charset=ISO-8859-1

I was looking at the code for getIndexSize() on the ReplicationHandler to
get at the size of the index on disk. From what I can tell, because this
does directory.listAll() to get all the files in the directory, the size on
disk includes not only what is searchable at the moment but potentially
also files that are being created by background merges/etc.. I am wondering
if there is an API that would give me the size of the "currently
searchable" index files (doubt this exists, but maybe)..

If not what is the most appropriate way to get a list of the segments/files
that are currently in use by the active searcher such that I could then ask
the directory implementation for the size of all those files?

For a more complete picture of what I'm trying to accomplish, I am looking
at building a quota/monitoring component that will trigger when index size
on disk gets above a certain size. I don't want to trigger if index is
doing a merge and ephemerally uses disk for that process. If anyone has any
suggestions/recommendations here too I'd be interested..

Thanks,

steve

--001a1132f1ba977b6604ef62771c--