em.
> >
> > We’re collecting GC information and using a DynaTrace agent, so I’m not
> sure if / how much that contributes to the overhead.
> >
> > This cluster is used strictly for type-ahead/auto-complete
> functionality.
>
cache is less clear, the recommendation is (number of
simultaneous queries you expect) X (your average row parameter)
Best,
Erick
On Mon, Jan 7, 2019 at 12:43 PM Branham, Jeremy (Experis)
wrote:
>
> Thanks Erick/Chris for the information.
&
the defaults (512), except
I'd put the autowarm count at, say, 16 or so.
The document cache is less clear, the recommendation is (number of
simultaneous queries you expect) X (your average row parameter)
Best,
Erick
On Mon, Jan 7, 2019 at 12:43 PM Branham, Jeremy (Experis)
wrote:
>
Thanks Erick/Chris for the information.
The page faults are occurring on each node of the cluster.
These are VMs running SOLR v7.2.1 on RHEL 7. CPUx8, 64GB mem.
We’re collecting GC information and using a DynaTrace agent, so I’m not sure if
/ how much that contributes to the overhead.
This
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Erick,
On 1/7/19 11:52, Erick Erickson wrote:
> Images do not come through, so we don't see what you're seeing.
>
> That said, I'd expect page faults to happen:
>
> 1> when indexing. Besides what you'd
Images do not come through, so we don't see what you're seeing.
That said, I'd expect page faults to happen:
1> when indexing. Besides what you'd expect (new segments
written to disk), there's segment merging going on in
the background which has to read segm
Does anyone know if it is typical behavior for a SOLR cluster to have lots of
page faults (50-100 per second) under heavy load?
We are performing load testing on a cluster with 8 nodes, and my performance
engineer has brought this information to attention.
I don’t know enough about memory
