It depends on your usage. When you search, does your code also retrieve the docs (using Searcher.document(n), for instance). If your index is 8GB, part of that is the "indexed" part (searchable), and part is just "stored" document fields.
It may be as simple as adding more RAM (try 4, 6, and 8GB) -- but not for your java heap -- instead for the linux filesystem cache. I suggest first adding some simple timing output to your search. You want to see how much time you are spending in the call to search(), and then how much time you're spending pulling the Documents from the index (and how much time you're spending in other parts of your search application). The call to search() is typically CPU-intensive, while pulling Documents is I/O-bound. And RAM is about 5 or 6 orders of magnitude faster than disk I/O. -chris On 7/27/05, Michael Celona <[EMAIL PROTECTED]> wrote: > I am going over ways to increase overall search performance. > > > > Currently, I have a dual zeon with 2G of ram dedicated to java searching an > 8G index on one 7200 rpm drive. > > > > Which will give the greatest payoff? > > > > 1) Going to 64bit server and giving more memory to java with faster > drives > > > > Or > > > > 2) Staying with 32bit server but going with faster drives and > splitting the operating system from the index drive. > > > > > > Basically, what are the performance improvements from separating the > operation system form the index drive(s). > > > > > > Thanks, > > Michael > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
