Thanks to you both. I've pinged the people who can reproduce this
problem, I suspect they'll try the patch out. I'm out next week, far
far away from internet connections so I'll be silent for a while. But
don't be surprised if new messages appear.
Thanks again
Erick
On Fri, May 10, 2013 at 3:46 A
Erick,
On Thu, May 9, 2013 at 10:28 PM, Erick Erickson wrote:
> Yeah, this is getting warmer. Some of the
> CompressingStoredFieldsReader objects are 240M. The documents aren't
> nearly that large I don't think (but I'll verify).
Wow, 240M is a lot! Would you be able to know which member of thes
Erick,
I would try to limit the number of threads to aleviate the problem, honestly,
gong much above #CPU cores rarely makes things better. Just let excessive
update commands wait in some queue. We impose hard limits intercepting update
chain and configure container thread pool to have smalle
Adrien:
Yeah, this is getting warmer. Some of the
CompressingStoredFieldsReader objects are 240M. The documents aren't
nearly that large I don't think (but I'll verify).
But still, over 700 of these objects live at once? I _think_ I'm
seeing the number go up significantly when the number of index
Maybe completely wrong here, but I would be ready to bet that you see high
thread churn
We were bitten by it many times at other places. We have some memory heavy
analyzers and once you experiance high thread-churn gc() cannot keep up
anymore.
This was the reason to move to tomcat from jetty
Hi Erick,
The stored fields reader reuses the buffer used for decompression across
calls in the same thread, so I'm thinking that this kind of behaviour could
happen if some documents are very large. Is it the case?
Adrien
Le 8 mai 2013 17:22, "Erick Erickson" a écrit :
> I'm seeing a case wher
Since what we're seeing is increasing heap usage, it doesn't quite
smell like SOLR-4802 or SOLR-4589, but it's possible
On Wed, May 8, 2013 at 11:21 AM, Erick Erickson wrote:
> I'm seeing a case where (reported to me, not on my personal machine)
> where Solr's heap is being exhausted appare
I'm seeing a case where (reported to me, not on my personal machine)
where Solr's heap is being exhausted apparently by compressed field
reader. Here's a sample line from a summary of a heap dump:
CompressingStoredFieldReader 735 instances
where the CompressingStoredFieldReader instances are taki
