We had some serious slowness at startup before I set Xms to be the same as Xmx.
We run with an 8G heap. We have multiple collections but don’t use faceting.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Nov 28, 2016, at 8:40 AM, Max Bridgewater
Thanks again Folks. I tried each suggestion and none made any difference. I
am setting up a lab for performance monitoring using App Dynamics.
Hopefully I am able to figure out something.
On Mon, Nov 28, 2016 at 11:20 AM, Erick Erickson
wrote:
> bq: If you know the
bq: If you know the maximum size you ever will need, setting Xmx is good.
Not quite sure what you're getting at here. I pretty much guarantee that a
production system will eat up the default heap size, so not setting Xmx will
cause OOM errors pretty soon. Or did you mean Xms?
As far as setting
Am 28.11.2016 um 00:00 schrieb Shawn Heisey:
On 11/27/2016 12:51 PM, Florian Gleixner wrote:
On 22.11.2016 14:54, Max Bridgewater wrote:
test cases were exactly the same, the machines where exactly the same
and heap settings exactly the same (Xms24g, Xmx24g). Requests were
sent with
Setting
On 11/27/2016 12:51 PM, Florian Gleixner wrote:
> On 22.11.2016 14:54, Max Bridgewater wrote:
>> test cases were exactly the same, the machines where exactly the same
>> and heap settings exactly the same (Xms24g, Xmx24g). Requests were
>> sent with
> Setting heap too large is a common error.
On 22.11.2016 14:54, Max Bridgewater wrote:
> test cases were exactly the same, the machines where exactly the same and
> heap settings exactly the same (Xms24g, Xmx24g). Requests were sent with
Setting heap too large is a common error. Recent Solr use the filesystem
cache, so you don't have to
Thanks folks. It looks like the sweet spot where I get comparable results
is at 30 concurrent threads. It progressively degrades from there as I
increases the number of concurrent threads in the test script.
This made me think that something is configured in Tomcat ((Solr4) that is
not
I recently ran benchmarks on 4.10.4 and 6.2.1 and found very little difference
in query performance.
This was with 8 million documents (homework problems) from production. I used
query logs from
production. The load is a constant number of requests per minute from 100
threads. CPU usage
is
On 22/11/16 15:34, Prateek Jain J wrote:
> I am not sure but I heard this in one of discussions, that you cant migrate
> directly from solr 4 to solr 6. It has to be incremental like solr 4 to solr
> 5 and then to solr 6. I might be wrong but is worth trying.
Ideally the index needs to be
Have you run IndexUpgrader?
Index Format Changes
Solr 6 has no support for reading Lucene/Solr 4.x and earlier indexes. Be
sure to run the Lucene IndexUpgrader included with Solr 5.5 if you might
still have old 4x formatted segments in your index. Alternatively: fully
optimize your index with
It depends highly on what your requests look like, and which ones are slower.
If you're request mix is heterogeneous, find the types of requests
that seem to have the largest slowdown and let us know what they look
like.
-Yonik
On Tue, Nov 22, 2016 at 8:54 AM, Max Bridgewater
[mailto:max.bridgewa...@gmail.com]
Sent: 22 November 2016 01:54 PM
To: solr-user@lucene.apache.org
Subject: Solr 6 Performance Suggestions
I migrated an application from Solr 4 to Solr 6. solrconfig.xml and
schema.xml are sensibly the same. The JVM params are also pretty much similar.
The indicces
I migrated an application from Solr 4 to Solr 6. solrconfig.xml and
schema.xml are sensibly the same. The JVM params are also pretty much
similar. The indicces have each about 2 million documents. No particular
tuning was done to Solr 6 beyond the default settings. Solr 4 is running in
Tomcat
13 matches
Mail list logo