Thanks Michail.
I am unable to locate bottleneck so far. Will try jstack and other tools.
On 8/25/16 11:40 PM, Mikhail Khludnev wrote:
Rough sampling under load makes sense as usual. JMC is one of the suitable
tools for this.
Sometimes even just jstack or looking at SolrAdmin/Threads is enough
Rough sampling under load makes sense as usual. JMC is one of the suitable
tools for this.
Sometimes even just jstack or looking at SolrAdmin/Threads is enough.
If the only small ratio of documents is updated and a bottleneck is
filterCache you can experiment with segmened filters which suite more
Follow up update ...
Set autowarm count to zero for caches for NRT and I could negotiate
latency from 2 min to 5 min :)
However, still seeing high QTimes and wondering where else can I look?
Should I debug the code or run some tools to isolate bottlenecks (disk
I/O, CPU or Query itself). Loo
And, I might add, you should look through your old logs
and see how long it takes to open a searcher. Let's
say Shawn's lower bound is what you see, i.e.
it takes a minute each to execute all the autowarming
in filterCache and queryResultCache... So you're current
latency is _at least_ 2 minutes be
On 7/26/16 5:46 AM, Shawn Heisey wrote:
On 7/22/2016 10:15 AM, Rallavagu wrote:
As Erick indicated, these settings are incompatible with Near Real Time
updates.
With those settings, every time you commit and create a new searcher,
Solr will execute up to 1000 queries (potentia
On 7/22/2016 10:15 AM, Rallavagu wrote:
> size="5000"
> initialSize="5000"
> autowarmCount="500"/>
>
> size="2"
> initialSize="2"
> autowarmCount="500"/>
As Erick in
On 7/22/16 9:56 AM, Erick Erickson wrote:
OK, scratch autowarming. In fact your autowarm counts
are quite high, I suspect far past "diminishing returns".
I usually see autowarm counts < 64, but YMMV.
Are you seeing actual hit ratios that are decent on
those caches (admin UI>>plugins/stats>>cac
Also, here is the link to screenshot.
https://dl.dropboxusercontent.com/u/39813705/Screen%20Shot%202016-07-22%20at%2010.40.21%20AM.png
Thanks
On 7/21/16 11:22 PM, Shawn Heisey wrote:
On 7/21/2016 11:25 PM, Rallavagu wrote:
There is no other software running on the system and it is completely
Here is the snapshot of memory usage from "top" as you mentioned. First
row is "solr" process. Thanks.
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+
COMMAND
29468 solr 20 0 27.536g 0.013t 3.297g S 45.7 27.6 4251:45 java
21366 root 20 0 14.499g 217824
OK, scratch autowarming. In fact your autowarm counts
are quite high, I suspect far past "diminishing returns".
I usually see autowarm counts < 64, but YMMV.
Are you seeing actual hit ratios that are decent on
those caches (admin UI>>plugins/stats>>cache>>...)
And your cache sizes are also quite h
On 7/22/16 8:34 AM, Erick Erickson wrote:
Mostly this sounds like a problem that could be cured with
autowarming. But two things are conflicting here:
1> you say "We have a requirement to have updates available immediately (NRT)"
2> your docs aren't available for 120 seconds given your autoSoft
Mostly this sounds like a problem that could be cured with
autowarming. But two things are conflicting here:
1> you say "We have a requirement to have updates available immediately (NRT)"
2> your docs aren't available for 120 seconds given your autoSoftCommit
settings unless you're specifying
-Dsol
On 7/21/2016 11:25 PM, Rallavagu wrote:
> There is no other software running on the system and it is completely
> dedicated to Solr. It is running on Linux. Here is the full version.
>
> Linux version 3.8.13-55.1.6.el7uek.x86_64
> (mockbu...@ca-build56.us.oracle.com) (gcc version 4.8.3 20140911 (Re
On 7/21/16 9:16 PM, Shawn Heisey wrote:
On 7/21/2016 9:37 AM, Rallavagu wrote:
I suspect swapping as well. But, for my understanding - are the index
files from disk memory mapped automatically at the startup time?
They are *mapped* at startup time, but they are not *read* at startup.
The map
On 7/21/2016 9:37 AM, Rallavagu wrote:
> I suspect swapping as well. But, for my understanding - are the index
> files from disk memory mapped automatically at the startup time?
They are *mapped* at startup time, but they are not *read* at startup.
The mapping just sets up a virtual address space
Thanks Erick.
On 7/21/16 8:25 AM, Erick Erickson wrote:
bq: map index files so "reading from disk" will be as simple and quick
as reading from memory hence would not incur any significant
performance degradation.
Well, if
1> the read has already been done. First time a page of the file is
acces
bq: map index files so "reading from disk" will be as simple and quick
as reading from memory hence would not incur any significant
performance degradation.
Well, if
1> the read has already been done. First time a page of the file is
accessed, it must be read from disk.
2> You have enough physical
17 matches
Mail list logo
