@Evert We have 16 GB total RAM, out of which Heap is using 4 GB. Initially we use RAMDirectory, but later switched to MMapDirectory since RAMDirectory is not meant for production use.
@Adrien Might be you are right as we are running our system under load test so we are firing 200 requests with JMeter (loop forever). This may be the cause of 100% CPU usage with 4 vCPUs machine. In this case should we manually restrict our Lucene search threads in our application OR there is some other inbuild Lucene mechanism to restrict the threads to search Lucene index. Regards Rajnish On Tue, Jan 3, 2017 at 9:09 PM, Adrien Grand <jpou...@gmail.com> wrote: > Are you running search requests in a loop from more than 4 threads? If yes > then this situation is ideal like Trejkaz said. Otherwise please describe > your workload and explain why you think 100% CPU usage is not ideal. > > Le mar. 3 janv. 2017 à 12:52, Rajnish kamboj <rajnishk7.i...@gmail.com> a > écrit : > > > High CPU may be ideal, but 100% CPU utilization is not ideal. (We might > be > > missing very silly thing) > > > > More information on our environment: > > Machine details: 4 vCPUs and 4 GB RAM > > Search Load: ~200 simultaneous users searching requests. > > Data set : 3.5 Million records (~ 2 GB index size). > > > > We reduced our data set to 25000, still CPU usage was very high, but > > throughput increases. > > > > Please advice, if we are missing any Lucene recommendations? > > > > > > > > On Tue, Jan 3, 2017 at 1:04 AM, Trejkaz <trej...@trypticon.org> wrote: > > > > > On Tue, Jan 3, 2017 at 5:26 AM, Rajnish kamboj < > rajnishk7.i...@gmail.com > > > > > > wrote: > > > > > > > > Hi > > > > > > > > The CPU usage goes upto 100% during search. > > > > > > Isn't that ideal? Or would you prefer your searches to be slow, blocked > > by > > > I/O? > > > > > > TX > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > > > > > >
