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 maximum size you ever will nee
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 Xm
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 he
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. Rece
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 s
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 comparative
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 unde
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 upgra
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 So
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
wrote:
> I migrate
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.
Regards,
Prateek Jain
-Original Message-
From: Max Bridgewater [mailto:
12 matches
Mail list logo